Issues with urtwn

[Nathan Whitehorn]

This is what the debug output looks like when things go wrong:
wlan0: [54:78:1a:a0:91:22] sta power save mode on
wlan0: wlan0: [54:78:1a:a0:91:22] save frame with age 41, 1 now queued
[54:78:1a:a0:91:22] sta power save mode off
wlan0: [54:78:1a:a0:91:22] flush ps queue, 1 packets queued
wlan0: [54:78:1a:a0:91:22] sta power save mode on
wlan0: [54:78:1a:a0:91:22] save frame with age 41, 1 now queued
wlan0: [54:78:1a:a0:91:22] save frame with age 0, 2 now queued
wlan0: [54:78:1a:a0:91:22] save frame with age 0, 3 now queued
wlan0: [54:78:1a:a0:91:22] save frame with age 0, 4 now queued
wlan0: ieee80211_sta_tim_notify: TIM=1
wlan0: ieee80211_sta_tim_notify: TIM=1
wlan0: ieee80211_sta_tim_notify: TIM=1
wlan0: ieee80211_sta_tim_notify: TIM=1
wlan0: ieee80211_sta_tim_notify: TIM=1
wlan0: [54:78:1a:a0:91:22] save frame with age 0, 5 now queued
wlan0: [54:78:1a:a0:91:22] save frame with age 0, 6 now queued

Let me know if I can test anything else.
-Nathan

On 09/08/14 15:17, Adrian Chadd wrote:
> Please compile your kernel with IEEE80211_DEBUG, then enable debugging
> - wlandebug +state +power
>
> You can disable powersave with 'ifconfig wlan0 -powersave', but it
> shouldn't be enabled by default.
>
>
>
> -a
>
>
> On 8 September 2014 15:14, Nathan Whitehorn <nwhitehorn at freebsd.org> wrote:
>> So it's definitely to do with powersave. Here's a bunch of iterations of
>> ifconfig list sta on my laptop:
>> ADDR               AID CHAN RATE RSSI IDLE  TXSEQ  RXSEQ CAPS FLAG
>> 54:78:1a:a0:91:22  149    1  54M 37.0    0   4385  37104 EPS A       HTCAP
>> RSN WME
>> ADDR               AID CHAN RATE RSSI IDLE  TXSEQ  RXSEQ CAPS FLAG
>> 54:78:1a:a0:91:22  149    1  54M 37.5    0   4412  39360 EPS A       HTCAP
>> RSN WME
>> ADDR               AID CHAN RATE RSSI IDLE  TXSEQ  RXSEQ CAPS FLAG
>> 54:78:1a:a0:91:22  149    1  54M 37.5    0   4417  39360 EPS AP      HTCAP
>> RSN WME
>> ADDR               AID CHAN RATE RSSI IDLE  TXSEQ  RXSEQ CAPS FLAG
>> 54:78:1a:a0:91:22  149    1  54M 37.5    0   4417  39360 EPS AP      HTCAP
>> RSN WME
>> ADDR               AID CHAN RATE RSSI IDLE  TXSEQ  RXSEQ CAPS FLAG
>> 54:78:1a:a0:91:22  149    1  54M 37.5    0   4417  39360 EPS AP      HTCAP
>> RSN WME
>>
>> You can see the connection die on the third line, when the txseq and rxseq
>> counters stop incrementing and 'P' gets added to the FLAG field. Does this
>> mean the AP has turned on powersave on its end?
>> -Nathan
>>
>>
>> On 09/07/14 14:07, Adrian Chadd wrote:
>>> Hi,
>>>
>>> The way it's supposed to work in the legacy 802.11 powersave world is
>>> that you send a/any data frame with the powermgt bit in the 802.11
>>> header set to 0 and the AP goes "oh they're awake!" and sends you your
>>> buffered frames.
>>>
>>> By default powersave isn't enabled, so we should never be _telling_
>>> the AP that we're going to sleep and the stack always sends data
>>> frames with pwrmgt=0.
>>>
>>> You can ensure it's disabled by ifconfig wlan0 -powersave
>>>
>>> The code in -HEAD that manages that is in ieee80211_power.c. I added
>>> an explicit powersave support mode for NICs that need it done for them
>>> - and the only one it's enabled for right now is ath(4).
>>>
>>> The only reason net80211 sends pwrmgt changes outside of having
>>> net80211 power save enabled is the background scan code.
>>>
>>> I'd compile in IEEE80211_DEBUG in your kernel, then I'd use wlandebug
>>> +scan to see if somehow there's some scanning going on; and wlandebug
>>> +power to see if any power save transitions occur.
>>>
>>> Are you absolutely sure it's a receive side buffering problem, rather
>>> than a send side problem?
>>>
>>> It's also possible that the NIC stops receiving and the AP treats that
>>> as "oh ok, they've gone to sleep for a while." ath(4) now does this in
>>> hostap mode.
>>>
>>>
>>> -a
>>>