On 08/26/2013 01:12 PM, Mark Cave-Ayland wrote:
On 23/08/13 19:55, Mark Cave-Ayland wrote:
Can anyone provide any hints to debugging the issue? I've just updated
to Linus' latest git master from earlier today and the issue still
appears :(
I spent some more time today trying to debug what was happening, and ended up
setting up a temporary hostapd access point so that I could get logs from both
the AP and my laptop workstation.
The bug I'm chasing seems to be related to the EAPOL handshake between my laptop
and the AP. A session with Wireshark shows something like this:
AP -> Laptop : EAPOL 1/4
Laptop -> AP : EAPOL 2/4
(pause - EAPOL timeout of several seconds)
AP -> Laptop : EAPOL 1/4
Laptop -> AP : EAPOL 2/4
This pattern is repeated throughout the connection attempts. Comparing
wpa_supplicant logs from a workstation with an Intel iwlwifi card shows that the
AP never sends the EAPOL 3/4 packet, suggesting that something in the EAPOL 2/4
packet was invalid causing the authentication attempt to be dropped.
Interestingly enough if I leave the wpa_supplicant running for a minute or two,
then sometimes the laptop will authenticate successfully with the AP - this
suggests that perhaps it may be an initialisation bug of some description?
Can anyone suggest any reasons why the AP never responds with the EAPOL 3/4
packet as part of the 4-way handshake? To get more information, I set up a fake
AP using hostapd with logging enabled and recorded the authentication attempts
on both the AP and the laptop (note that remarkably the laptop managed to
associate to the AP on the second attempt in this particular session):
AP hostapd log:
http://www.ilande.co.uk/tmp/hostapd-rtl8192cu-connect.txt
Laptop workstation log:
http://www.ilande.co.uk/tmp/wpasupplicant-rtl8192cu-connect.txt
Also just to confirm that all testing was done against commit
6a7492a4b2e05051a44458d7187023e22d580666 and therefore should contain the WPA
association fix "rtlwifi: rtl8192cu: Fix problem in connecting to WEP or WPA(1)
networks" from commit 5b8df24e22e0b00b599cb9ae63dbb96e1959be30.
I just retested and this message was posted from what lsusb says is a "Bus 001
Device 007: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless
Adapter [Realtek RTL8188CUS]" connected to an AP using WPA(1).
My kernel is 3.11.0-rc6-wl+ from the wireless-testing tree. I have built
3.11-rc7-wl+, but not yet rebooted. Before I boot into that kernel, I will build
and test the mainline kernel, but it should not make a difference as the only
code differences between wireless-testing and the mainline trees deal with
cleaning up some sparse endian issues.
What is the make/model of the AP that fails? Is its firmware the latest
available? Just to confirm, you are running WPA1 encryption.
Do you still have the wireshark file from the failed attempt? If so, could you
filter out the traffic from APs and stations other than the units trying to make
the connection, and send me (privately) the trimmed file?
For completeness, I have tested WPA2 with Netgear WNDR3300 and WNDR3400 running
standard firmware, WPA1 with a Linksys WRT54GL running openWRT Kamikaze fw, and
WEP with a Linksys WRT54G V5 running standard fw.
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
