Re: [RFC] carl9170: Fix memory accounting when sta is in power-save mode.

[Nicolas Cavallari <Nicolas.Cavallari@lri.fr>]

On 24/02/2012 14:39, Johannes Berg wrote:
> On Fri, 2012-02-24 at 14:34 +0100, Nicolas Cavallari wrote:
>> On 23/02/2012 19:51, Nicolas Cavallari wrote:
>>> On 23/02/2012 19:08, Christian Lamparter wrote:
>>>> On Thursday, February 23, 2012 06:27:59 PM Nicolas Cavallari wrote:
>>>>> On 23/02/2012 17:52, Christian Lamparter wrote:
>>>>>> On Thursday, February 23, 2012 04:53:34 PM Nicolas Cavallari wrote:
>>>>>>> While this seems to fix my problem, there could still be problems remaining
>>>>>>> in this code path.  Particularly carl9170_tx_status will do lots of things
>>>>>>> like incrementing counters and waking up mac80211 queues...
>>>>>> That should be alright. As a rule of thumb, for every call to
>>>>>> carl9170_tx_accounting [called by carl9170_op_tx tx handler]
>>>>>> we need to call carl9170_tx_status. If the station is still in
>>>>>> ps mode, mac80211 will cache the station's frames and sets
>>>>>> the TIM bits. 
>>>>> Part of the reason i wrote this, is because, while this patch fixes the
>>>>> memory accounting problem and prevent the AP from stopping working, the
>>>>> powersaving station sometimes cannot communicate with the AP anymore
>>>>> (other stations can). The station uses ath9k, and is just really doing a
>>>>> background scan. The first traces that i have just indicate that the
>>>>> station entered powersave mode, then sends probe requests and probe
>>>>> requests directed to the AP, then sends authentication requests to the
>>>>> AP (?), but the AP does not respond to any of them...
>>>>>
>>>> Do you run an 802.11n ap on carl9170?
>>> No, it's a 802.11g currently.
>>> My current wild guess is that, the responses to those requests are
>>> somehow still queued ...
>>
>> And i was right...
>>
>> /*
>>  * Ignore doze->wake transitions that are
>>  * indicated by non-data frames, the standard
>>  * is unclear here, but for example going to
>>  * PS mode and then scanning would cause a
>>  * doze->wake transition for the probe request,
>>  * and that is clearly undesirable.
>>  */
>> if (ieee80211_is_data(hdr->frame_control) &&
>>     !ieee80211_has_pm(hdr->frame_control))
>> 	ap_sta_ps_end(sta);
>>
>> As (re)associations requests and Auth frames are not data frames,
>> mac80211 still considers that the station is still in powersave mode, so
>> it still queues frames, and even queues the responses to the auth
>> frames. Except that the station disassociated silently, and is trying to
>> re-associate after a short time.
>>
>> Shouldn't mac80211 transition the sta to "awake" when receiving
>> auth/assoc frames ?
> 
> I don't think so, that would make us send frames to the station it no
> longer deserves to have. Hostapd should instead delete & re-create the
> station entry, I think?
> 
> johannes
> 

Hostapd already does that¹ ... after the association response is acked.

Will send a patch for hostapd then.

[¹] :
/*
 * Remove the STA entry in order to make sure the STA PS state gets
 * cleared and configuration gets updated in case of reassociation back
 * to the same AP.
 */
hostapd_drv_sta_remove(hapd, sta->addr);