Malformed AddBA Response prevents clients from associating?

Denton Gentry denton.gentry at gmail.com
Sun Aug 24 19:28:52 PDT 2014


[   18.047597] ath10k: qca988x hw2.0 (0x4100016c, 0x043202ff) fw
10.1.467.2-1 api 2 htt 2.1

On Sun, Aug 24, 2014 at 7:22 PM, Adrian Chadd <adrian at freebsd.org> wrote:
> Which firmware build are you using?
>
>
>
> -a
>
>
> On 24 August 2014 19:17, Denton Gentry <denton.gentry at gmail.com> wrote:
>> 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).
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>>



More information about the ath10k mailing list