Re: brcmfmac: implement basic AP-follow-STA

[Arend Van Spriel <arend.vanspriel@broadcom.com>]

[-- Attachment #1: Type: text/plain, Size: 2363 bytes --]

On June 17, 2024 3:19:56 PM Kalle Valo <kvalo@kernel.org> wrote:

> 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.

Right. Only had taken a quick glance and noticed this. The 802.11 spec does 
not really cover the concept of virtual interfaces, but still having this 
solved through a module parameter for a specific driver is definitely not a 
first choice.

Anyway, I do have some thoughts about this patch. Hopefully I can dive into 
this in coming days.

Regards,
Arend

> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches




[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]