Re: [PATCH 1/1] wifi: mac80211: ignore PM bit in non-bufferable MMPDUs for PS start

[Johannes Berg <johannes@sipsolutions.net>]

On Tue, 2026-10-20 at 07:58 +0100, Lee Jones wrote:
> 
> You were also right to suspect the client-side TIM path in
> ieee80211_rx_mgmt_beacon(), when (dynamic_ps_timeout == 0) (for instance,
> when power-save is disabled on the client interface) and IEEE80211_CONF_PS
> is not set, mac80211 currently ignores its AID bit in the TIM and never
> sends a wake nullfunc frame to flush the AP's buffered frames.
> 
> If you're happy for me to do so, I'll send the following 2-patch v3 series:
> 
>  1. Symmetric PM-bit handling in ieee80211_rx_h_sta_process() (only
>     consulting the PM bit on data and bufferable management frames, while
>     waking sleeping stations on Auth / (Re)AssocReq as-per 9fef65443388).
> 
>  2. Sending a wake nullfunc in ieee80211_rx_mgmt_beacon() when the TIM
>     indicates buffered unicast traffic while IEEE80211_CONF_PS is not set.
> 
> Does this help or hinder?  Your call.  If you decline, I'll go ahead and
> close out our internal (Android) report as `Won't Fix` and move on to
> something else.

I think what you do with your report is probably not my problem ;-)

IMHO adding the client side defence definitely makes sense, though in
many/most cases it'll be up to the firmware anyway.

I don't think I have a problem with the AP-side spec alignment, even if
it's a touchy area, but depends how complex the code gets perhaps? I
don't think any client would rely on us not handling the PM bit in those
frames, and they're supposed to set it to 0 (reserved) anyway, so I'm
not very worried about it. The patch was fine and I guess moving that
around to apply to both sides wouldn't really change it much? Want to
try?

johannes