linux-kernel - Re: [PATCH wireless v2] wifi: wlcore: fix wlcore AP mode

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, 18 Jun 2024 09:17:09 +0000 (UTC)
From: Kalle Valo <kvalo@...nel.org>
To: "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>
Cc: Johannes Berg <johannes.berg@...el.com>,
 Michael Nemanov <michael.nemanov@...com>, linux-kernel@...r.kernel.org,
 linux-wireless@...r.kernel.org
Subject: Re: [PATCH wireless v2] wifi: wlcore: fix wlcore AP mode

"Russell King (Oracle)" <rmk+kernel@...linux.org.uk> wrote:

> Using wl183x devices in AP mode with various firmwares is not stable.
> 
> The driver currently adds a station to firmware with basic rates when it
> is first known to the stack using the CMD_ADD_PEER command. Once the
> station has finished authorising, another CMD_ADD_PEER command is issued
> to update the firmware with the rates the station can use.
> 
> However, after a random amount of time, the firmware ignores the power
> management nullfunc frames from the station, and tries to send packets
> while the station is asleep, resulting in lots of retries dropping down
> in rate due to no response. This restricts the available bandwidth.
> 
> With this happening with several stations, the user visible effect is
> the latency of interactive connections increases significantly, packets
> get dropped, and in general the WiFi connections become unreliable and
> unstable.
> 
> Eventually, the firmware transmit queue appears to get stuck - with
> packets and blocks allocated that never clear.
> 
> TI have a couple of patches that address this, but they touch the
> mac80211 core to disable NL80211_FEATURE_FULL_AP_CLIENT_STATE for *all*
> wireless drivers, which has the effect of not adding the station to the
> stack until later when the rates are known. This is a sledge hammer
> approach to solving the problem.
> 
> The solution implemented here has the same effect, but without
> impacting all drivers.
> 
> We delay adding the station to firmware until it has been authorised
> in the driver, and correspondingly remove the station when unwinding
> from authorised state. Adding the station to firmware allocates a hlid,
> which will now happen later than the driver expects. Therefore, we need
> to track when this happens so that we transmit using the correct hlid.
> 
> This patch is an equivalent fix to these two patches in TI's
> wilink8-wlan repository:
> 
> https://git.ti.com/cgit/wilink8-wlan/build-utilites/tree/patches/kernel_patches/4.19.38/0004-mac80211-patch.patch?h=r8.9&id=a2ee50aa5190ed3b334373d6cd09b1bff56ffcf7
> https://git.ti.com/cgit/wilink8-wlan/build-utilites/tree/patches/kernel_patches/4.19.38/0005-wlcore-patch.patch?h=r8.9&id=a2ee50aa5190ed3b334373d6cd09b1bff56ffcf7
> 
> Reported-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
> Co-developed-by: Johannes Berg <johannes.berg@...el.com>
> Tested-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
> Signed-off-by: Johannes Berg <johannes.berg@...el.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>

Patch applied to wireless.git, thanks.

14f89946b6b3 wifi: wlcore: fix wlcore AP mode

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/E1sClp4-00Evu7-8v@rmk-PC.armlinux.org.uk/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches