Messages in this thread | | | From | "Maciej S. Szmigiero" <> | Subject | Re: rtlwifi/rtl8192cu AP mode broken with PS STA | Date | Tue, 6 Apr 2021 14:06:37 +0200 |
| |
On 06.04.2021 12:00, Kalle Valo wrote: > "Maciej S. Szmigiero" <mail@maciej.szmigiero.name> writes: > >> On 29.03.2021 00:54, Maciej S. Szmigiero wrote: >>> Hi, >>> >>> It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS, >>> since the driver does not update its beacon to account for TIM changes, >>> so a station that is sleeping will never learn that it has packets >>> buffered at the AP. >>> >>> Looking at the code, the rtl8192cu driver implements neither the set_tim() >>> callback, nor does it explicitly update beacon data periodically, so it >>> has no way to learn that it had changed. >>> >>> This results in the AP mode being virtually unusable with STAs that do >>> PS and don't allow for it to be disabled (IoT devices, mobile phones, >>> etc.). >>> >>> I think the easiest fix here would be to implement set_tim() for example >>> the way rt2x00 driver does: queue a work or schedule a tasklet to update >>> the beacon data on the device. >> >> Are there any plans to fix this? >> The driver is listed as maintained by Ping-Ke. > > Yeah, power save is hard and I'm not surprised that there are drivers > with broken power save mode support. If there's no fix available we > should stop supporting AP mode in the driver. >
https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/api clearly documents that "For AP mode, it must (...) react to the set_tim() callback or fetch each beacon from mac80211".
The driver isn't doing either so no wonder the beacon it is sending isn't getting updated.
As I have said above, it seems to me that all that needs to be done here is to queue a work in a set_tim() callback, then call send_beacon_frame() from rtlwifi/core.c from this work.
But I don't know the exact device semantics, maybe it needs some other notification that the beacon has changed, too, or even tries to manage the TIM bitmap by itself.
It would be a shame to lose the AP mode for such minor thing, though.
I would play with this myself, but unfortunately I don't have time to work on this right now.
That's where my question to Realtek comes: are there plans to actually fix this?
Maciej
| |