Hi, > 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. Yeah, I can't say I remember anything about it. Perhaps just because it was NEW_BEACON rather than START_AP originally... > 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. You can obviously change the beacon during the operation of the AP, I can't tell you now why we didn't change it to SET_AP or CHANGE_AP when we changed NEW_BEACON/DEL_BEACON to START_AP/STOP_AP ... But I agree it'd make sense today to have it all with these operations. But do we want to change everything now and have hostapd be able to do both paths? Is the cleaner future in the kernel worth that complexity? > 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. Also true, mostly, though it'd depend on what you actually want to do. I'd argue that the "default" settings should indeed be accepted by the driver, but maybe if you set something that _isn't_ supported by brcmfmac (and isn't default in hostapd) then refusing it would be more user-friendly than ignoring it? > Restricting the > .change_bss() in the other drivers will likely cause user-space > regression. Depends how much, in some ways the "regression" could be beneficial if it would otherwise ignore settings the user wanted? But yeah, it could. > 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. > Cool, thanks! :) johannes
