Re: [PATCH] brcmfmac: support AP isolation to restrict reachability between stations

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

On 4/26/2025 10:37 AM, Johannes Berg wrote:
> On Sat, 2025-04-26 at 13:21 +0530, Gokul Sivakumar wrote:
>> IMHO, In CFG80211, if we introduce a bitmap to track which BSS Parameter
>> is changed by the userspace in the SET_BSS operation and then used this
>> bitmap while handling the request, then the WLAN Driver would reject the
>> operation with "EOPTNOTSUPP", instead of doing AP Isolation, because it
>> does not support setting the other BSS params in the request.
> 
> Not necessarily?
> 
>> For Example, considering hostapd (iwd doesn't support SET BSS operation)
>> if the user only enabled the config file param "ap_isolate", but didn't
>> explicitly set "preamble", hostapd would implicitly set default value
>> (0 - LONG_PREAMBLE) in the preamble param while sending the SET_BSS
>> operation request to CFG80211.
> 
> But presumably that's still the default value in the driver too?
> 
> Hostapd could also be fixed too, to not change it if not requested.

To me this raises the question as to when this SET_BSS primitive should 
be used. As I recall one of the goals of nl80211 was to get rid of doing 
individual configuration change like we had in wext which even sometimes 
required specific order to get what we want. So why are these parameters 
not in the START_AP primitive (actually the P2P parameter are). Some of 
the parameters are probably implicit as they are represented in the 
beacon data passed in START_AP. The ap_isolate however is not expressed 
in the beacon afaik.

When all parameters would be handled by START_AP what would be the need 
for SET_BSS. I think it would be to modify the parameters for a BSS that 
is active, ie. beaconing, and possibly serving client STAs. However, 
this is where I get a bit confused. There is also a SET_BEACON primitive 
which looks like it supports a similar scenario.

>> CFG80211 would then mark the bit corresponding to the SHORT_PREAMBLE BSS
>> param as "changed" in the bitmap. WLAN Driver on receiving this SET_BSS
>> request, would then have to reject the entire operation without enabling
>> the user requested "ap_isolation" param, because of the preamble param
>> that is not even explicitly requested by the user.
> 
> Or the driver can accept short-preamble setting, and reject it only if
> it's set to short-preamble, rather than long-preamble.
> 
>> However, for other AP BSS Parammeters, we don't have the corresponding
>> NL80211 feature flags.
> 
> Uh such a long time ago :) I don't remember why we had these. Given the
> above do we need new ones? We can I guess, but I'm not sure it's needed
> even if we change hostapd - if we do change it then it can just set only
> the ones that were set in the config file?

The drivers that implement .change_bss() today have a relaxed policy. If 
we add restrictions in .change_bss() for brcmfmac that means from 
user-space perspective the API is not driver agnostic. Restricting the 
.change_bss() in the other drivers will likely cause user-space 
regression. So there should be a capability exchange between driver and 
user-space. My idea here is to have the driver add a nested attribute in 
NL80211_CMD_GET_WIPHY listing the bss parameters supported. Probably can 
use the same attribute as flag in NL80211_CMD_SET_BSS to indicate 
user-space does handle the bss parameter support info from the driver. 
Will try to get something implemented to see how that goes.

Regards,
Arend