Kurt Van Dijck <dev.kurt@xxxxxxxxxxxxxxxxxxxxxx> 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
