On 04/25/2012 01:18 AM, Nicolas Cavallari wrote:
On 25/04/2012 08:23, Ben Greear wrote:On 04/24/2012 11:08 PM, Jouni Malinen wrote:Either the AP did not receive the first EAPOL-Key 4/4 or processed it only after retransmitting 3/4. Supplicant side will need to to reply to retransmitted 3/4 to complete the 4-way handshake. If the AP received either of these 4/4 messages, it should be fine with the result. If it didn't receive either, it should disconnect the station. It does not look like either of those happened.Ok, it seems strange they would have such a lame bug, but maybe they never tried associating several stations at once. (I see around 30% failure rate when using just 15 stations). We have several off-the-shelf APs and home-grown ones (using ath9k) that work fine, even when associating 100+ stations, so at the least the N66U is weird... That said, I'll probably need to attempt a work-around for this. The only obvious thing I see is the extra RX EAPOL (in all error cases I looked at, and none where it associated properly), and the fact that DHCP just fails to acquire a lease. I'll try adding a hack to detect the duplicate RX EAPOL and bounce the connection if that hits, and see if that helps any...It could look like the old bug i had, where the station would send EAPOL-Key 4/4 encrypted when associating. Normally, the AP should disconnect the station, it would retry and hopefully succeed next time, and no one would have noticed anything, except this AP doesn't disconnect the station and it doesn't recover. Basically, wpa_supplicant sends the EAPOL-Key 4/4, then adds the PTK/GTK in the kernel, but due to scheduling/queuing/buffering of the EAPOL packet, it would be sent encrypted with the PTK ...
Maybe it sets the key after the first 4/4 response, and then the key is already in place when the second 4/4 response is sent? Should wpa_supplicant remove the key from the kernel before sending the second 4/4 response?
If when monitoring, you don't see any plaintext EAPOL-Key 4/4 coming from the failed stations, then it could be the same problem.
Maybe that is the case. I do not see an obvious plain-text response to the second EAPOL 3/4 message, but there *is* a packet that goes out in the right time-frame...maybe it's an encrypted 4/4 response packet? I'm attaching a filtered capture (full capture is here: http://www.candelatech.com/~greearb/misc/13-stas-n66.pcap.gz) Here are the corresponding logs from supplicant: 1335371251.170525: RTM_NEWLINK, IFLA_IFNAME: Interface 'sta10' added 1335371251.170547: RTM_NEWLINK, IFLA_IFNAME: Interface 'sta10' added 1335371251.280369: sta10: RX EAPOL from c8:60:00:e8:88:b0 1335371251.280445: sta10: Setting authentication timeout: 10 sec 0 usec 1335371251.280458: sta10: IEEE 802.1X RX: version=2 type=3 length=117 1335371251.280463: sta10: EAPOL-Key type=2 1335371251.280469: sta10: key_info 0x8a (ver=2 keyidx=0 rsvd=0 Pairwise Ack) 1335371251.280473: sta10: key_length=16 key_data_length=22 1335371251.280541: sta10: State: ASSOCIATED -> 4WAY_HANDSHAKE 1335371251.280547: sta10: WPA: RX message 1 of 4-Way Handshake from c8:60:00:e8:88:b0 (ver=2) 1335371251.280571: sta10: RSN: no matching PMKID found 1335371251.281073: sta10: WPA: Sending EAPOL-Key 2/4 1335371252.803896: sta10: RX EAPOL from c8:60:00:e8:88:b0 1335371252.803975: sta10: IEEE 802.1X RX: version=2 type=3 length=175 1335371252.803983: sta10: EAPOL-Key type=2 1335371252.803989: sta10: key_info 0x13ca (ver=2 keyidx=0 rsvd=0 Pairwise Install Ack MIC Secure Encr) 1335371252.803993: sta10: key_length=16 key_data_length=80 1335371252.804149: sta10: State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE 1335371252.804155: sta10: WPA: RX message 3 of 4-Way Handshake from c8:60:00:e8:88:b0 (ver=2) 1335371252.804186: sta10: WPA: Sending EAPOL-Key 4/4 1335371252.804253: sta10: WPA: Installing PTK to the driver 1335371252.804529: sta10: State: 4WAY_HANDSHAKE -> GROUP_HANDSHAKE 1335371252.804547: sta10: WPA: Installing GTK to the driver (keyidx=1 tx=0 len=32) 1335371252.804626: sta10: WPA: Key negotiation completed with c8:60:00:e8:88:b0 [PTK=CCMP GTK=TKIP secure=512 dbg=pairwise-gtk] 1335371252.804633: sta10: Cancelling authentication timeout 1335371252.804639: sta10: State: GROUP_HANDSHAKE -> COMPLETED 1335371252.804645: sta10: CTRL-EVENT-CONNECTED - Connection to c8:60:00:e8:88:b0 completed (auth) [id=0 id_str=] 1335371252.805696: RTM_NEWLINK, IFLA_IFNAME: Interface 'sta10' added 1335371252.830295: sta10: RX EAPOL from c8:60:00:e8:88:b0 1335371252.830330: sta10: IEEE 802.1X RX: version=2 type=3 length=175 1335371252.830335: sta10: EAPOL-Key type=2 1335371252.830340: sta10: key_info 0x13ca (ver=2 keyidx=0 rsvd=0 Pairwise Install Ack MIC Secure Encr) 1335371252.830344: sta10: key_length=16 key_data_length=80 1335371252.830445: sta10: State: COMPLETED -> 4WAY_HANDSHAKE 1335371252.830452: sta10: WPA: RX message 3 of 4-Way Handshake from c8:60:00:e8:88:b0 (ver=2) 1335371252.830487: sta10: WPA: Sending EAPOL-Key 4/4 1335371252.830541: sta10: WPA: Installing PTK to the driver 1335371252.839240: sta10: State: 4WAY_HANDSHAKE -> GROUP_HANDSHAKE 1335371252.839256: sta10: WPA: Installing GTK to the driver (keyidx=1 tx=0 len=32) 1335371252.847235: sta10: WPA: Key negotiation completed with c8:60:00:e8:88:b0 [PTK=CCMP GTK=TKIP secure=512 dbg=pairwise-gtk] 1335371252.847250: sta10: Cancelling authentication timeout 1335371252.847259: sta10: State: GROUP_HANDSHAKE -> COMPLETED 1335371440.843881: sta10: BSS: Expire BSS 1 due to age 1335371440.843888: sta10: BSS: Remove id 1 BSSID c0:c1:c0:38:e1:cb SSID 'e3k-2g-1' Thanks, Ben -- Ben Greear <greearb@xxxxxxxxxxxxxxx> Candela Technologies Inc http://www.candelatech.com
Attachment:
sta10.pcap.gz
Description: GNU Zip compressed data
