Malformed AddBA Response prevents clients from associating?

* Malformed AddBA Response prevents clients from associating?
@ 2014-08-25  2:17 Denton Gentry
  2014-08-25  2:22 ` Adrian Chadd
  0 siblings, 1 reply; 6+ messages in thread
From: Denton Gentry @ 2014-08-25  2:17 UTC (permalink / raw)
  To: ath10k

[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]

I have an AP using ath10k as a 5 GHz 802.11ac interface. Very
occasionally it gets into a mode where stations are unable to
associate. I don’t know how it gets into this mode, but once there the
sequence of events when a client tries to associate is:

1. Client and AP exchange Authentication, Association Request, and
Association Response frames.

2. AP sends the first packet in the EAPOL exchange.

3. Client sends an AddBA request.

4. AP sends back a malformed AddBA Response. The corruption takes the
form of a recognizable AddBA Response appended with 10 bytes of
additional stuff, and carrying a bad FCS.
Once in this state, every AddBA Response I’ve captured has this extra
10 bytes of stuff appended to the end, and carries a bad FCS.

5. The client discards the AddBA Response because the FCS is wrong.
Gathering pcaps on the client shows that it does try to send its EAPOL
response, but that packet never makes it onto the air (presumably
because the AddBA is pending).

Rebooting the client does not resolve the problem, after reboot it
still cannot associate. Rebooting the AP resolves the problem.

I don’t know a lot about what causes the AP to get into this state. I
wrote a script to make clients sit in a loop disassociating and
associating every few seconds. A single client running this loop
worked for many hours; it never failed. Starting the loop on two
clients made the problem happen in about two hours. I have not yet
tried it with more clients yet.

Because the AddBA Response is generated by the firmware, I believe the
problem must be in the firmware. For some reason, it starts sending
malformed AddBA Responses.

I’ve attached two pcaps, which I’ve trimmed down to manageable size by
removing lots of beacons. The Malformed_AddBAR.pcap is from a system
in the state where clients cannot associate. The Normal_AddBAR.pcap is
captured using the same AP and client, but with everything working
normally (the EAPOL exchange completes, and the client begins sending
QoS Data frames).

[-- Attachment #2: Malformed_AddBAR.pcap --]
[-- Type: application/octet-stream, Size: 4680 bytes --]

[-- Attachment #3: Normal_AddBAR.pcap --]
[-- Type: application/octet-stream, Size: 4687 bytes --]

[-- Attachment #4: Type: text/plain, Size: 146 bytes --]

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 6+ messages in thread