Malformed AddBA Response prevents clients from associating?

Denton Gentry denton.gentry at gmail.com
Sun Aug 24 19:17:34 PDT 2014


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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Malformed_AddBAR.pcap
Type: application/octet-stream
Size: 4680 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20140824/005071b8/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Normal_AddBAR.pcap
Type: application/octet-stream
Size: 4687 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20140824/005071b8/attachment-0001.obj>


More information about the ath10k mailing list