On Mon, Feb 23, 2015 at 12:06:09PM -0800, Linus Torvalds wrote: > On Mon, Feb 23, 2015 at 9:17 AM, Jouni Malinen <j@xxxxx> wrote: > > mac80211: Do not encrypt EAPOL frames before peer has used the key > > Hmm. This patch does not seem to make a difference. I thought it did > at first, but then removed the wpa_supplicant debugging, and got the > same failures. Interesting. That would seem to imply that this AP does not like something about the EAPOL-Key msg 4/4 from the station during the faster timing (no wpa_supplicant debug) and would even be unable to accept the responses during retransmissions.. I'm not sure what could cause that. Is there anything that the AP could provide as far as logging is concerned? How far is the station from the AP? Would it be possible to see whether the behavior changes if you were within, say, five meters or so? This should allow the higher transmit rate proposed by minstrel_ht to work pretty reliably and that could confirm if this is indeed related to too high a rate being used here and then for some reason being unable to fall back to a sufficiently low rate to work at higher distance. It would be useful if you can capture the 802.11 frame exchange from a failed connection case with an external wireless sniffer. It sounds like this should be doable with iwlwifi and while I haven't tested this myself, I'd assume something like this would do the trick (this is assuming that the interface is not being used at the time, e.g., with wpa_supplicant): sudo iw dev wlan0 set type monitor sudo ip link set wlan0 up sudo iw dev wlan0 set freq 2462 HT20 sudo dumpcap -i wlan0 -w /tmp/wlan0.pcap # test connection and stop dumpcap after the failure # and "sudo ip link set wlan0 down; sudo iw dev wlan0 set type station" # to restore normal station mode -- Jouni Malinen PGP id EFC895FA -- 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
