On May 21, 2015, at 9:37 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
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.
That's a very non-standard use. Accounting-On / Off is supposed to be for the entire NAS. i.e. the WLAN controller / BSS. Not for a particular 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.
The BSS should be the RADIUS client.
I think it makes a lot of sense for Accounting-On and Accounting-Off therefore to include this in a Called-Station-Id attribute.
Which, in the normal RADIUS model, is just the MAC address of the RADIUS client. Which never changes. So it's not really useful to send it.
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.
Wow... that's bad, but good they've fixed it.
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.)
That's a good idea.
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.
That's bad.
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.)
Accounting-Off is for when the NAS is about to reboot. Accounting-On is for when the NAS has just booted.
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.
Yes. They're better off just sending an Accounting-On message.
I've suggested that they consider implementing the retransmission behaviour recommended in your excellent RFC 5080.
Yeah... which is years old.
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.
They've been sending accounting "stop" packets after an Access-Reject. Uh... no. If the user was rejected, there's no session, and no need for a "stop" packet. I think I should write a "best practices" document for NAS vendors. Alan DeKok.