Hi all, We're chasing a problem where, with an ath10k device running as access point and a Macbook Air as a client, responses to probe requests are sometimes missed by the Macbook Air because they are delayed for a long time, and the Macbook has changed channels by the time they come through.
ath10k driver version: from backports as of kvalo/ath-next on 2014-03-08 (v3.15-rc1-237-gd9bc4b9) Firmware version: 10.1.467.3 Steps: - start capturing packets, either on the ath10k AP itself or a secondary monitor system - on the Macbook Air (which has joined your SSID at least once before), open and close the wifi dropdown menu a few times. (May also happen with clients other than Macbook Air; not heavily tested.) Expected: - Probe requests are sent by the station and answered by the AP within a millisecond or two. Actual: - Probe requests are often answered within a millisecond or two, but very frequently they are delayed by 200ms. They are therefore not seen by the Macbook, and thus not acknowledged, so you can see them retransmitted several times by the AP. I suspect this has something to do with the AP thinking the Macbook is in power saving mode. In the attached capture, the last packet (a wifi ack) received from the Macbook before the probe request does indeed say it's going to sleep. But then it sends a new probe request a few ms later. The AP doesn't respond until its original wakeup time. I think it should consider the station to have woken up immediately, since it just sent a packet. This is especially true since the powersaving flag in the Probe Request packet is set to zero (station will stay up). See attached pcap. I trimmed out some beacons for APs that are not related to the test, but otherwise it's intact. $ zcat /tmp/reduced-delayed-proberesp.pcap.gz | tcpdump -r - ... 00:42:12.670744 1947809503us tsft 6.0 Mb/s 5745 MHz 11a -38dB signal antenna 1 Probe Request (AVERY_Bu1_TestWifi) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] 00:42:12.672960 1947812849us tsft 6.0 Mb/s 5745 MHz 11a -37dB signal antenna 1 Probe Request () [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] ... 00:42:12.712490 1947853161us tsft 6.0 Mb/s 5745 MHz 11a -39dB signal antenna 1 Beacon (AVERY_Bu1_TestWifi) [6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0 Mbit] ESS CH: 149, PRIVACY ... 00:42:12.814832 1947955593us tsft 6.0 Mb/s 5745 MHz 11a -40dB signal antenna 1 Beacon (AVERY_Bu1_TestWifi) [6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0 Mbit] ESS CH: 149, PRIVACY ... 00:42:12.878434 1948017652us tsft 6.0 Mb/s 5745 MHz 11a -40dB signal antenna 1 Probe Response (AVERY_Bu1_TestWifi) [6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0 Mbit] CH: 149, PRIVACY 00:42:12.878450 1948017995us tsft 6.0 Mb/s 5745 MHz 11a -39dB signal antenna 1 Probe Response (AVERY_Bu1_TestWifi) [6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0 Mbit] CH: 149, PRIVACY 00:42:12.878455 1948018367us tsft 6.0 Mb/s 5745 MHz 11a -39dB signal antenna 1 Probe Response (AVERY_Bu1_TestWifi) [6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0 Mbit] CH: 149, PRIVACY 00:42:12.878463 1948018730us tsft 6.0 Mb/s 5745 MHz 11a -39dB signal antenna 1 Probe Response (AVERY_Bu1_TestWifi) [6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0 Mbit] CH: 149, PRIVACY Any suggestions? I looked at ath10k driver patches since the date we last grabbed a copy, and I don't see anything relevant.
reduced-delayed-proberesp.pcap.gz
Description: GNU Zip compressed data
_______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k