Probe Response packets sometimes delayed by 200ms

Michal Kazior michal.kazior at tieto.com
Fri Oct 3 00:37:39 PDT 2014


On 3 October 2014 08:39, Avery Pennarun <apenwarr at gmail.com> wrote:
> On Fri, Oct 3, 2014 at 2:10 AM, Michal Kazior <michal.kazior at tieto.com> wrote:
>> On 3 October 2014 07:48, Avery Pennarun <apenwarr at gmail.com> wrote:
>>> 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.)
>>
>> Was the Macbook Air disconnected cleanly on the AP?
>
> In my particular test case, I was actually already associated with the
> AP while I was doing these steps.  I don't think that affects the
> results, which means in this case that there is no question of being
> uncleanly disconnected since I was not disconnected at all.

But this kind of confirms that if there's a peer entry then ath10k AP
will try to do powersave game with probe req / resp.


>> There's a tx credit starvation bug which blocks wmi commands after
>> disassoc+deauth frames are queued (via wmi as well) and aren't acked
>> by station in which case wmi peer delete command times out and
>> sta_state splats a calltrace in kernel logs. This effectively leaves
>> firmware thinking the peer is still connected and it is never
>> disconnected (you can expect spurious sta kickout events after an hour
>> once that happens). This could explain why ath10k AP tries to play
>> powersave with the Macbook Air.
>
> I think we previously ran into the tx credit starvation bug and
> cherry-picked one of your patches to fix it.  So I don't think that's
> the problem here.

Tx starvation credit bug cannot be simply fixed in host. It needs
firmware changes as well which aren't there. Perhaps this is actually
what causes the problem? I recall my patches had a timeout on wmi mgmt
tx. Wasn't it 2x beacon interval? That's the 200ms. Pcap suggests your
beacon interval is 100ms.

Can you look at ath10k logs if each wmi mgmt tx is sent immediately
after wmi mgmt rx? Can you share the exact patch you cherry-picked?


>> Or perhaps this is related to uAPSD? Do you have it enabled in
>> hostapd? Is Macbook Air associating with uAPSD enabled?
>
> We tried enabling uAPSD but it caused lots of problems so we turned it
> off again.

I'm asking since it calls per-peer powersave wmi command a few times
(wmi_ap_ps_peer_cmd).


Michał



More information about the ath10k mailing list