[ 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 <[email protected]> wrote: > 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
