netdev - 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:   Thu, 8 Apr 2021 21:04:51 +0200
From:   "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
To:     Pkshih <pkshih@...ltek.com>
Cc:     "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "johannes@...solutions.net" <johannes@...solutions.net>,
        "kvalo@...eaurora.org" <kvalo@...eaurora.org>,
        Larry Finger <Larry.Finger@...inger.net>
Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA

On 08.04.2021 06:42, Pkshih wrote:
>> -----Original Message-----
>> From: Maciej S. Szmigiero [mailto:mail@...iej.szmigiero.name]
>> Sent: Thursday, April 08, 2021 4:53 AM
>> To: Larry Finger; Pkshih
>> Cc: linux-wireless@...r.kernel.org; netdev@...r.kernel.org; linux-kernel@...r.kernel.org;
>> johannes@...solutions.net; kvalo@...eaurora.org
>> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
>>
(...)
>>> Maceij,
>>>
>>> Does this patch fix the problem?
>>
>> The beacon seems to be updating now and STAs no longer get stuck in PS
>> mode.
>> Although sometimes (every 2-3 minutes with continuous 1s interval pings)
>> there is around 5s delay in updating the transmitted beacon - don't know
>> why, maybe the NIC hardware still has the old version in queue?
> 
> Since USB device doesn't update every beacon, dtim_count isn't updated neither.
> It leads STA doesn't awake properly. Please try to fix dtim_period=1 in
> hostapd.conf, which tells STA awakes every beacon interval.

The situation is the same with dtim_period=1.

When I look at a packet trace (captured from a different NIC running in
monitor mode) it's obvious that the pinged STA wakes up almost
immediately once it sees its DTIM bit set in a beacon.

But many beacons pass (the network has beacon interval of 0.1s) between
where a ping request (ICMP echo request) is buffered on the AP and where
the transmitted beacon actually starts to have DTIM bit set.

I am observing delays up to 9 seconds, which means a delay up to 90
beacons between when DTIM bit should be set and when it actually gets
set.

As I said above, this happens only sometimes (every 2-3 minutes with
continuous 1s interval pings) but there is definitely something wrong
here.

My wild guess would be that if the NIC is prevented from sending a beacon
due to, for example, its radio channel being busy it keeps that beacon
in queue for the next transmission attempt and only then sends it and
removes from that queue.
Even thought there might be newer beacon data already available for
transmission.

And then these "unsent" beacons pile up in queue and the delays I am
observing are simply old queued beacons (that don't have the DTIM bit
set yet) being transmitted.

But that's just my hypothesis - I don't know how rtl8192cu hardware
actually works.

> --
> Ping-Ke

Thanks,
Maciej