> After further thought, how about this: > > # Optional NAS-Identifier, containing a string value used to identify the NAS > # originating RADIUS packets. This must be unique to the NAS within the > # scope of a RADIUS server. For example, a fully qualified domain name can be > # used here appended with the . > # Where nas_identifier has not been set, the BSSID will be sent in RADIUS > # packets. This will be of the form 00-10-A4-23-19-C0. > # When using IEEE 802.11r, nas_identifier must be set and be between 1 and > # 48 octets long. > #nas_identifier=ap.example.com > > # Whether to include the BSSID in the NAS-Identifier sent in RADIUS packets. > # For example, where the nas_identifier is configured as ap.example.com, a > # value of the form ap.example.com_00-10-A4-23-19-C0 will be used. > # Where mutiple BSSes are offered by a NAS, each BSS for which RADIUS accounting > # is occuring must be presented as being an individual NAS for Accounting-On and > # Accounting-Off to be handled correctly by a RADIUS server. > # This option has no effect where the nas_identifier has not been set. > # Where this is the case, the BSSID will always be sent. > # This will be of the form 00-10-A4-23-19-C0. > nas_identifier_include_bssid=1 This approach seems very optimal as: 1) It would enhance hostapd so that it will always send a NAS-Identifier attribute where nas_identifier isn't defined. This is a very good thing. 2) Existing deployments with an older configuration won't define nas_identifier_include_bssid, which will default to 0. We would ensure hostapd won't send Accounting-On/Accounting-Off where nas_identifier_include_bssid is 0. This means they would only see a minor, acceptable change in behaviour. 3) New deployments will have nas_identifier_include_bssid defined with a value of 1. Accounting-On/Accounting-Off will be sent in this case. Nick _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
