Re: brcmfmac: implement basic AP-follow-STA

[Kalle Valo <kvalo@kernel.org>]

Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> writes:

> /* context */
> We (Yamabiko) have an application where we migrated to a bcm4339 sdio wifi chip.
> We use it in AP+STA mode: when the chip is detected (wlan+ add uevent),
> we call 'run iw dev wlan0 interface add wap0 type __ap' and start
> wpa_supplicant on wlan0 and hostapd on wap0.
> The STA is more important than the AP.
> We have 'roamoff' parameter set. We observed problems with the firmware roaming
> before and switched to wpa_supplicant roaming.
>
> We run a linux v5.4.24 derivative.
>
> /* problem */
> We observed that the chip is able to switch channel for wpa_supplicant to
> connect to a different channel, but it soon looses connection because hostapd
> does not change channel too.
>
> This did work with our previous wifi chip (realtek 88x2 something), which notifies
> hostapd that it switched.
>
> /* patch description */
> I went down and ended up modifying the brcmfmac driver, patch appended below.
> For contributing on these mailing lists, I ported it to yesterday's master.
> The idea is that whenever a STA issues a connect with channel info, the AP's
> will switch to it too. This implies a small glitch in the AP radio, which already
> occurred before my patch. it seems that the wifi chip cannot modify radio settings
> per virtual interface, although the API to the wifi chip suggests it can (that is
> most probable a more generic communication used for other chips that can do this).
> The channel switch is also reported to userspace.
>
> To be less invasive, this new behaviour is put behind
> a module parameter 'ap_follow_sta'.

FWIW module parameters should be avoided, especially for 802.11 protocol
level functionality.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

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