Hello,
Since the beginning of openwrt there seems to be no development interest in wpa_supplicant on the wan side of the interfaces. This is too bad. There is a problem many users are facing with openwrt regarding wpa_supplicant. The problem is that the authentication always fails. Lately someone came by my house and pointed at a bug in the if.c code from freebsd. Now please stop shaking your head, I know openwrt is linux based and thus there is no correlation between BSD bugs and Linux. But I think this assumption is wrong. Clearly the effects of an unpatched freebsd wpa_supplicant session (the authentication fails) is EXACT the same as with linux. With the same I mean: The output of tcpdump and wpa_supplicant are 100% identical. The solution with freebsd is (according to the author of the 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."
Ok this means something like: Because the EAPOL packet is some sort of multicast packet which is not correctly parsed, it gets discarded. Thus rendering the wpa_supplicant authentication invalid.
There is a bug report of this: https://dev.openwrt.org/ticket/1862 which is copied here too:
This bug I am describing is more than strongly related to the bug solved in http://cvsup.pt.freebsd.org/cgi-bin/cvs … p;r2=1.266
This is the discription Jouke Witteveen (j.witteveen@gmail.com) 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
State: DISCONNECTED -> ASSOCIATED
Associated to a new BSS: BSSID=01:80:c2:00:00:03
..
EAPOL: SUPP_PAE entering state CONNECTING
EAPOL: SUPP_BE entering state IDLE
EAP: EAP entering state INITIALIZE
EAP: EAP entering state IDLE
Cancelling scan request
EAPOL: startWhen --> 0
EAPOL: SUPP_PAE entering state CONNECTING
EAPOL: txStart
TX EAPOL - hexdump(len=4): 02 01 00 00
EAPOL: startWhen --> 0
EAPOL: SUPP_PAE entering state CONNECTING
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.
These bug reports and/or forum discussions are related to this issue!
Ticket #1687 (reopened defect)
http://forum.openwrt.org/viewtopic.php?id=10366
http://forum.openwrt.org/viewtopic.php?id=6631
Ticket #84 (closed defect: invalid)