Probe Response packets sometimes delayed by 200ms

Avery Pennarun apenwarr at gmail.com
Thu Oct 2 22:48:01 PDT 2014


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reduced-delayed-proberesp.pcap.gz
Type: application/x-gzip
Size: 2743 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20141003/1485f4c6/attachment-0001.bin>


More information about the ath10k mailing list