Opened 11 years ago

Closed 9 years ago

Last modified 9 years ago

#1862 closed defect (fixed)

problem: EAPOL packet are sended but never received.

Reported by: robert@… Owned by: developers
Priority: normal Milestone:
Component: kernel Version:
Keywords: Cc:



This bug I am describing is more than strongly related to the bug solved in

This is the discription Jouke Witteveen (j.witteveen@…) made about his freebsd patch:

Fix a bug in if_findmulti(), whereby it would not find (and thus delete) a link-layer multicast group membership. Such memberships are needed in order 
to support protocols such as IS-IS without putting the interface into PROMISC or ALLMULTI modes. sa_equal() is not OK for comparing sockaddr_dl as 
it has deeper structure than a simple byte array, so add sa_dl_equal() and use that instead.

The result of the above statement is that EAPOL packets, which are sended during a wpa_supplicant authentication session, are sended by the client. These packets are succesfully received by the AP and replied. But the reply gets eaten by the handeling of multicasts. Jouke Witteveen discovered this bug at freebsd and solved it. Because the output of tcpdump and wpa_supplicant are the same on OpenWrt whiterussian/kamikaze and freebsd, I expect the problem would be more or less the same. Hopefully anyone out there is willing to solve this. (I have no idea how to solve this)

Thus the problem in short:

problem: EAPOL packet are sended but never received.
platform: wrt54gl v1.1 (although I don't think it's platform dependend)
my network card: eth0.1 Link encap:Ethernet HWaddr 00:16:B6:D9:53:6E

"tcpdump -ni eth0.1 -ex ether proto 0x888e" shows:

02:17:18.960735 00:16:b6:d9:53:6e > 01:80:c2:00:00:03, ethertype EAPOL (0x888e), length 18: 
        0x0000:  0201 0000
02:17:49.110779 00:16:b6:d9:53:6e > 01:80:c2:00:00:03, ethertype EAPOL (0x888e), length 18: 
        0x0000:  0201 0000

Note the 02 01 00 00 in the above and following wpa_supplicant output !!!

root@kamikaze:~# wpa_supplicant -Dwired -ieth0.1 -c/etc/wpa_supplicant.conf -dd

Own MAC address: 00:16:b6:d9:53:6e
Associated to a new BSS: BSSID=01:80:c2:00:00:03
EAPOL: SUPP_BE entering state IDLE
EAP: EAP entering state INITIALIZE
EAP: EAP entering state IDLE
Cancelling scan request
EAPOL: startWhen --> 0
EAPOL: txStart
TX EAPOL - hexdump(len=4): 02 01 00 00
EAPOL: startWhen --> 0
EAPOL: txStart
TX EAPOL - hexdump(len=4): 02 01 00 00

As you can see the EAPOL packet is send but the reply gets never received.

Hopefully anyone out there might take a look at it.


Robert Nagtegaal.

Attachments (0)

Change History (30)

comment:1 Changed 11 years ago by robert@…

These bug reports and/or forum discussions are related to this issue!

Ticket #1687 (reopened defect)

Ticket #84 (closed defect: invalid)

comment:2 Changed 11 years ago by anonymous

It seems the robo.c file is incomplete. It only handels vlan traffic where it should also support 802.1x headers (from the ethernet packets offcource). This is a BUG.

comment:3 follow-up: Changed 11 years ago by anonymous

UP!!! Please resolve this problem immediatly!!!

comment:4 in reply to: ↑ 3 Changed 11 years ago by anonymous

Replying to anonymous:

UP!!! Please resolve this problem immediatly!!!

Judging the fact that this bug is now lingering on for more than a year (since I first pointed it out) and the zero respons from the openwrt team, I came to the understanding that the openwrt team is more interested in fancy apps than a good working tcp stack. Shame shame shame.

comment:5 Changed 11 years ago by oyvind

Any progress on this? I have been waiting for this bug to get resolved for over 1 year!

comment:6 Changed 11 years ago by oyvind

This bug is related to /ticket/1687.html and also /ticket/84.html which means that this problem is over 2 years old.

comment:7 Changed 11 years ago by anonymous

I think the problem is here:


This whole file (actualy files offcourse) is really weird btw. The half of its content is about making integers and structures bla bla bla but never used! Which comes to me as a piece of source that has been taken and modified but badly! You can check for you selve and you should! This whole robo driver code is messy and it's a God wonder that is works at all! BUT let this not be mistaken!, I am really glad you guys did it in the first place. Unfortunaly it still doesn't work with wpa_supplicant. This is not the error of wpa_supplicant but merely the faulty implementation of vlans. This piece of code (in my understanding) is resposible for the handeling of level 2 traffic (aka vlan, 802.1x, etc...). Unfortunally this code (still in my understanding) is only capible of handeling vlan traffic. Any other traffic (like multicast needed for eapol auth...) is processed faulty!

This is the function I am talking about :->

static int handle_enable_vlan_write(void *driver, char *buf, int nr)

int disable = ((buf[0] != '1') ? 1 : 0);

robo_write16(ROBO_VLAN_PAGE, ROBO_VLAN_CTRL0, disable ? 0 :

(1 << 7) /* 802.1Q VLAN */ | (3 << 5) /* mac check and hash */);

robo_write16(ROBO_VLAN_PAGE, ROBO_VLAN_CTRL1, disable ? 0 :

(1 << 1) | (1 << 2) | (1 << 3) /* RSV multicast */);

robo_write16(ROBO_VLAN_PAGE, ROBO_VLAN_CTRL4, disable ? 0 :

(1 << 6) /* drop invalid VID frames */);

robo_write16(ROBO_VLAN_PAGE, ROBO_VLAN_CTRL5, disable ? 0 :

(1 << 3) /* drop miss V table frames */);

return 0;


comment:8 Changed 11 years ago by anonymous

I ment switch-robo.c btw

comment:9 Changed 11 years ago by anonymous

Also, very important btw, this code is the center piece of the whole robo switch driver. That's the thing that wheels all the network ports and stuff.

comment:10 Changed 11 years ago by nbd

I think the switch-robo.c comment is invalid. see #1687

comment:11 Changed 11 years ago by anonymous

I think not. (sorry) See also /ticket/1687.html

comment:12 Changed 11 years ago by anonymous

Maybe a port of dbus and (it thought it was) nbus and wpa_supplicant compiled against these network libraries might solve the problem? It might be that the 802.1x traffic is injected at the wrong place in the packet stream. Anyone out there willing to do this. I am just a noob in russian/kamikaze and have no clue. I do know networking though!

comment:13 Changed 10 years ago by mmitar@…

I have the same problem with OpenWrt Kamikaze 7.09 on Linksys WRT54GL 1.1.

I have been tcpdumping on a router and noticed the same packets being send as reported in the initial report. But the thing I noticed is that they do not get onto a cable. I attached a computer running tcpdump to other side of a cable and no packages were coming from a router. While tcpdump running on a router were showing them. So packet disappear somewhere after they have been processed by the kernel (and tcpdump). Maybe in a device driver of an ethernet device?

(This was true even if I removed all vlan interfaces and used directly eth0 device.)

comment:14 Changed 10 years ago by anonymous

It does work on soekris hardware. This does NOT contradict above statement.

comment:15 Changed 10 years ago by mmitar@…

It has also worked for me on WRT54G 1.0-2.0. On WRT54G 4.0 it does not work. I suppose that maybe it is a switch driver after all. Maybe a driver for an "in CPU" switch?

comment:16 Changed 10 years ago by anonymous

WRT54G >=v2.2 uses BCM5325E switch chip, which is the problem, I think.

The EAPOL packets never really get through the switch onto the wire. But if it's sent with a destination MAC address of 01-80-C2-00-00-00 (the proper MAC address of 802.1x packet should be 01-80-C2-00-00-03), the packet get through the wire without any problem. (I tried it!)

From BCM5325E Product Brief (, the switch chip supports "802.1x filtering". I suppose that the switch chip is faulty configured so that it blocked those EAPOL packets.

Any one has the full datasheet of BCM5325E?

comment:17 Changed 10 years ago by Sliser

I think that main problem is here:
A standard 802.1D or 802.1Q Bridge filters (does not bridge) anyframe whose destination MAC address is in the range 01-80-C2-00-00-00 through ...-0F.
This filter is applicable to frames received on a user port in the upstream direction.

In our case:
MAC address: 01-80-C2-00-00-03.
Application: EAPOL.
Default behaviour: Block.
Optional configurable behaviour: Peer.
Reference: IEEE 802.1X, Table 7-2.

There some hope that such behaviour can be overriden. I don't know who handles packets with such destination MAC address, but i'll try to find it out. If somebody have any ideas write me at sliser [at]

comment:18 Changed 10 years ago by andrews@…

from 5325E datasheet:
If the DA matches one of the globally assigned reserved addresses between 01-80-C2-00-00-00 and 01-80-C2-00-00-
2F, the packet is handled as described in Table 19 on page 26.
from table 19 according 01-80-C2-00-00-03:
Function: IEEE 802.1x Port-Based Network Access Control
IEEE 802.1 Specified Action: Drop Frame
Default Mode Action (Note 1): Drop Frame
Frame-Managed Mode Action: Forward Frame to Frame Management Port Only.
Note: Default Mode disables the frame management port option. The IMP (when the MII is used as the interface to the external management subsystem, the port is referred to as the In-band Management Port) does not receive frame data when in this mode. The MII port is treated as a normal network port and have frames forwarded to it in accordance with the entries in the address table.

comment:19 Changed 10 years ago by Jouke Witteveen

Where can I find this 5325E datasheet?
As far as I can see the 5325E differs enough from the 5325M to make the desired behaviour impossible with the current drivers.
I am more than willing to investigate in this matter. Any ideas on getting more specific register addresses for the 5325E? The /trunk/package/robocfg/src/etc53xx.h seems to be mainly 5325M. Is mailing Broadcom perhaps a good idea?

comment:20 Changed 9 years ago by Scott Liu

The detailed bcm5325E chip datasheet is not available publicly. Only if you buy some chips from a Broadcom agent, you can then get the datasheet from him after signing a secret argeement. I'm sorry I don't have the datasheet either.

However, after reading the post by andrews and the source code of robocfg utility, I think this problem may be solved using the same mechanism which robocfg used. That's because the BCM5325E Product Brief has mentioned that 5325E is the feature-enhanced and pin-compatible version to the BCM5325M swith chip.

Now the core problem is how to set the corresponding register of the chip correctly to make it stop filtering 802.1x packets. The detailed datasheet would help much. Hopefully some one who owned the datasheet could solve this problem, or at least share the information about BCM5325E 802.1x register settings.

comment:21 Changed 9 years ago by lxevolution@…

I was looking over this issue for a few days now and I found this:

I don't understand much of this, but I think it has something to do with the way eth0.1 or vlan1 is bridged.

comment:22 Changed 9 years ago by Jouke Witteveen

I believe I have found a solution. I did not implement the official Broadcom specification as stated by andrews but it is quite decent and straight-forward.

To implement it I am writing a new wpa_supplicant driver: roboswitch. If you think you need to help me, you can contact me by gmail; my username is j.witteveen.

PLEASE NOTE: This means the bug will probably be fixed sometime soon. Puting any more effort in this bug without contacting me first is probably a waste of time.

comment:23 Changed 9 years ago by nieqingrong

I got a same problem in multicast packet. I use a BCM5325E chip in my board, connect port 0 to my network, connect port 1 to my PC. In my network, there has a bridge device and send out BPDU frames per 2 seconds. I use Ethereal or tcpdump on my PC, and I can capture BPDU packets. There means that Port 0 can receive BPDU frames and forward to Port 1 and other ports. But I can't capture any BPDU packets from MII port, I can capture ARP and other IP packets on MII port. When I set Frame_Manage_Mode to 1 and set Global Management Configuration Register to 0x82( MANAGE_PORT = 10,MII port, RX_BPDU_EN=1) and set MII Port Control Register to 0xAC,I can't receive any BPDU frames in MII port. There means that these BPDU frames doesn't forward to MII port in manage mode or unmanage mode.
Because I must receive BPDU frames in MII port and decide the port 0 and port 1 STP state, Who can help me How can I receive BPDU frames in MII port?
Please send information to my email: nieqingrong@…, thanks.

comment:24 Changed 9 years ago by Jouke Witteveen

FIXED: I have sent in my patch for includion in wpa_supplicant:

To compile this driver for a 2.4-series kernel you need to patch staging_dir/toolchain-mipsel_gcc3.4.6/include/linux/mii.h with the following:

--- include-linux-mii.h.orig	2008-11-04 16:50:46.000000000 +0100
+++ include-linux-mii.h	2008-11-04 16:57:32.000000000 +0100
@@ -9,7 +9,6 @@
 #define __LINUX_MII_H__
 #include <linux/types.h>
-#include <linux/if.h>
 /* Generic MII registers. */
@@ -104,6 +103,19 @@
 #define NWAYTEST_LOOPBACK       0x0100  /* Enable loopback for N-way   */
 #define NWAYTEST_RESV2          0xfe00  /* Unused...                   */
+/* This structure is used in all SIOCxMIIxxx ioctl calls */
+struct mii_ioctl_data {
+	__u16		phy_id;
+	__u16		reg_num;
+	__u16		val_in;
+	__u16		val_out;
+#ifdef __KERNEL__
+#include <linux/if.h>
+struct ethtool_cmd;
 struct mii_if_info {
 	int phy_id;
@@ -119,9 +131,6 @@
 	void (*mdio_write) (struct net_device *dev, int phy_id, int location, int val);
-struct ethtool_cmd;
-struct mii_ioctl_data;
 extern int mii_link_ok (struct mii_if_info *mii);
 extern int mii_nway_restart (struct mii_if_info *mii);
 extern int mii_ethtool_gset(struct mii_if_info *mii, struct ethtool_cmd *ecmd);
@@ -135,16 +144,6 @@
 			     unsigned int *duplex_changed);
-/* This structure is used in all SIOCxMIIxxx ioctl calls */
-struct mii_ioctl_data {
-	u16		phy_id;
-	u16		reg_num;
-	u16		val_in;
-	u16		val_out;
 static inline struct mii_ioctl_data *if_mii(struct ifreq *rq)
 	return (struct mii_ioctl_data *) &rq->ifr_ifru;
@@ -202,5 +201,5 @@
 	return 0;
+#endif /* __KERNEL__ */
 #endif /* __LINUX_MII_H__ */

I have already submitted this patch to a kernel maintainer and it will probably be included in a near-future version of the 2.4 series.

This bug can thus be closed since some future version of OpenWRT will include some furure version of wpa_supplicant and incorporate some future version of the linux kernel.

comment:25 Changed 9 years ago by Jouke Witteveen

Additional information to the fix:

  • The 2.4 series of the kernel include the patch from version 2.4.37 on.
  • The new wpa_supplicant driver (roboswitch) is present from version 0.6.6.

comment:26 Changed 9 years ago by florian

  • Resolution set to fixed
  • Status changed from new to closed

kernel patch applied in [14891], thanks !

comment:27 Changed 9 years ago by Jouke Witteveen

To include the RoboSwitch driver in your wpa_supplicant build, you have to uncomment the line reading


in package/wpa_supplicant/config.

Note that the driver is not mature yet. Feedback is welcome.

comment:28 Changed 9 years ago by florian

Fixed with [15045].

comment:29 Changed 9 years ago by Jouke Witteveen

In case the driver currently in OpenWRT's trunk doesn't work for you, please try the new version in wpa_supplicant's own trunk before sending feedback.

When doing so, you should read

Concerning [15045]: This changeset makes note of the wrong bug in its related message.
Concerning [15046]: This changeset makes the uncommenting mentioned above unnecessary for brcm-2.4 targets.

comment:30 Changed 9 years ago by anonymous

I've a similar issue today with BPDU frames, between my openwrt wifi bridge and my laptos.

Both side seems to be bogus: My openwrt bridge and my laptos use madwfifi chips, wpa_supplicant-0.6.9, madwifi-20090712-r4079 for my laptos, and a little older config for the openwrt side. the wifi is setup in WPA mode.

BDPU frames seems to be ignored by the linux kernel bridge code with the last wpa_supplicant-0.6.9 available as stable today when configured using -Dmadwifi or -Dwext

So when I use the ethernet cable, and so add a redundant link, (the bridge is setup between my ethernet card and the wifi), the wifi link is never blocked by the STP bridge, but the BPDU frames are generated, and the brctl stats show a message timer stuck to zero, even when the frame just came at the laptop side as seen with tcpdump...

Dump from the lpatop side:
18:16:06.929481 STP 802.1d, Config, Flags [none], bridge-id 0014.06:xx:xx:xx:xx:2e.8002, length 35

message-age 0.01s, max-age 4.00s, hello-time 2.00s, forwarding-delay 0.00s
root-id 000a.00:xx:xx:xx:xx:69, root-pathcost 200

18:16:06.930660 STP 802.1d, Config, Flags [none], bridge-id 000a.00:xx:xx:xx:xx:69.8001, length 35

message-age 0.00s, max-age 4.00s, hello-time 2.00s, forwarding-delay 0.00s
root-id 000a.00:xx:xx:xx:xx:69, root-pathcost 0

Add Comment

Modify Ticket

as closed .
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.