I did mean: 1) Introduce code that automatically appends the BSSID to the NAS-Identifier. Where you would otherwise have ap-foobar-01, something like ap-foobar-01_00-10-A4-23-19-C0 would instead be placed in to the attribute value. 2) Implement a new config flag to toggle this behaviour on or off. 3) Put this flag in to the configuration appropriately so that it is enabled by default going forward for new deployments. Old deployments would largely retain the current behaviour with their existing configuration. 4) When this flag is not specified, Accounting-On and Accounting-Off would always suppressed as they are not RFC compliant* as currently sent. An approach that just changed the configuration today would not achieve this, bad Accounting-On and Accounting-Off Accounting-Request packets would still be generated. This is why I favour a config flag. *The RFC errata process exists to correct issues like this, it has effectively amended the RFC removing the ambiguity by being marked Verified. >From hostapd's perspective, it should never be in the position that the NAS-Identifier is not sent in Access-Requests and Accounting-Requests. It should never be possible to be in this position. This can break other things too if it is ever omitted, practically it doesn't happen. There shouldn't be a concern here in relation to hostapd therefore. RADIUS clients and their shared secret are configured in RADIUS servers on the basis of the IP address/host name/DNS name that the request is coming in off of, so there's likely to be little by the way of compatibility implications of the change there. There would be a compatibility implication for those who expect and look for a particular value of the NAS-Identifier who would need to amend their RADIUS server configuration. This shouldn't be seen as a problem as the behaviour wouldn't change in this area for existing deployments of hostapd without a configuration change. You say whoever designs RADIUS should be aware of this type of thing, yet this issue with Accounting-On/Accounting-Off has remained in hostapd for years and has been an overlooked problem previously with commercial AP vendors too. Cheers, Nick _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
