> Whoever (or whatever) configures hostapd already has an option of doing > so with the nas_identifier parameter that is set for each BSS. I don't > think hostapd should be modifying this parameter on its own (e.g., the > proposal of adding a BSSID into this). This can have unexpected changes > when upgrading hostapd without touching configuration. Please note that > nas_identifier is used also for other purposes than RADIUS (mainly, FT > key holder name). I think that hostapd should append the BSSID to the end of the NAS-Identifier, by default, if this is deemed a viable way forward so that the default behaviour becomes compliant to RFC 2866. The RFC has, after all, been amended by errata to explicitly state that the current behaviour is not what is expected. 802.11r would be unaffected if we use the unappended value for this. > In general, it is a bad idea to change default behavior if there is a > risk of it breaking something. I do not know what exactly the proposed > new default behavior would be, but I find it difficult to see a clean > solution for this that could automatically be determined in a manner > that would cover all possible use cases. As such, I'd rather keep the > current behavior as the default in the future as well. > > Please note that there are also devices that use multiple hostapd > processes (one for each BSS), so the issue you describe is not going to > disappear even if the default behavior within a single process would be > changed. There could be a configuration option to use standards compliant RADIUS, disabled by default when undefined retaining the current behaviour, but enabled by default in the default configuration. This would ensure that there are no unexpected changes when upgrading hostapd with an existing configuration. If the BSSID were to be appended by default to the NAS-Identifier via configuration going forward for new configurations, this would apply to both single and multiprocess deployments and solve this Accounting-On/Accounting-Off issue. We shouldn't and it is in my view unrealistic to expect everyday people to understand the nuance of RADIUS to configure this in a way that avoids this problem. I strongly agree that we need to get Subsystem-on/Subsystem-off Acct-Status-Types defined as soon as possible. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap