Accounting-On and Accounting-Off being sent on a per-BSS basis not per-NAS

[Nick Lowe]

> 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