linux-kernel - Re: rtlwifi/rtl8192cu AP mode broken with PS STA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 6 Apr 2021 14:06:37 +0200
From:   "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
To:     Kalle Valo <kvalo@...eaurora.org>
Cc:     Ping-Ke Shih <pkshih@...ltek.com>,
        Johannes Berg <johannes@...solutions.net>,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Larry Finger <Larry.Finger@...inger.net>
Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA

On 06.04.2021 12:00, Kalle Valo wrote:
> "Maciej S. Szmigiero" <mail@...iej.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