Malformed AddBA Response prevents clients from associating?

[Adrian Chadd]

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
>