Thanks for the confirmation, Alan! :) The Called-Station-Id is actually really useful as it defines the scope of the Accounting-On/Accounting-Off which are sent here on a per-BSS basis for the 802.11 NAS. Eg: Called-Station-Id: 40-18-B1-AB-CD-EF:MySSID (BSSID:SSID) Otherwise, I cannot see how you would properly handle the Accounting-On and Accounting-Off correctly as BSSes are brought up and down with a configuration change. To reconcile/link them to the subsequent accounting on a per-session basis, it seems necessary. The format is defined for auth under RFC 3580: 3.20. Called-Station-Id For IEEE 802.1X Authenticators, this attribute is used to store the bridge or Access Point MAC address in ASCII format (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0". In IEEE 802.11, where the SSID is known, it SHOULD be appended to the Access Point MAC address, separated from the MAC address with a ":". Example "00-10-A4-23-19-C0:AP1". I think it makes a lot of sense for Accounting-On and Accounting-Off therefore to include this in a Called-Station-Id attribute. On the Aerohive front, all the RADIUS accounting will include an Event-Timestamp and Acct-Delay-Time in the forthcoming release, that isn't the case today. They have also added the Message-Authenticator AVP to non-EAP based Access-Request packets for the forthcoming release too. (Enabled as an option, disabled by default.) There are a couple of other issues that I have noticed that will still need resolving in a subsequent release, things like the Accounting-On and Accounting-Off not being retried if no ACK is received. In the beta that I am testing, they are now sending an Accounting-Off and Accounting-On at boot with the same Event-Timestamp in very quick succession. (They need to just send Accounting-On at this point really.) If you make a configuration change that requires a BSS to go up and down, they send an Accounting-Off and Accounting-On, expected behaviour, but currently with the same Event-Timestamp with the two packets being sent in very quick succession. (Previously it was just two packets in quick succession with no Event-Timestamp or Acct-Delay-Time.) This could easily result in out of order receipt, it's UDP after all, or out of order handling at a RADIUS server due to threading. It's race prone. I've suggested that they consider implementing the retransmission behaviour recommended in your excellent RFC 5080. I'm pretty confident they are on the case to improve things. I've been trying to identify and weed out issues so any others you notice it would be good to know about. Thanks again! :) Cheers, Nick