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
