Which firmware build are you using?
-a On 24 August 2014 19:17, Denton Gentry <[email protected]> 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 > [email protected] > http://lists.infradead.org/mailman/listinfo/ath10k > _______________________________________________ ath10k mailing list [email protected] http://lists.infradead.org/mailman/listinfo/ath10k
