Search Linux Wireless

Re: Strange problem with ath9k and ASUS N66U AP.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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


[Linux Kernel]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]     [Free Dating]     [M2M Wireless]

Add to Google Powered by Linux