Use the Framed-IP-Address AVP containing a client's IP address correctly in RADIUS accounting.

  • 9
  • Idea
  • Updated 3 years ago
  • Under Consideration
As our reseller has, despite chasing, gone silent since the 31st of October on their 365 support address, I am posting this as an idea here! :)

We have Single-Sign-On (SSO) taking place to Palo Alto firewalls via a Network Policy Server (NPS) extension that maintains a distributed state table of RADIUS sessions that exist as a result of sucessful 802.1X authentication attempts.

Following grumbles from users about Internet access being blocked for a while when they wake their devices up that connect via the wireless network, we did some investigating. It was obvious after some quick debugging what the root cause was:

The Framed-IP-Address AVP, which contains the client's IPv4 address for a session, is only received in a RADIUS accounting Interim-Update packet from HiveOS around 20 seconds after the session has been started at the RADIUS server via an accounting Start packet.

This issue is problematic and disruptive to any Single Sign On process that integrates at the RADIUS accounting level. Until the IP address is known, no actionable information can be supplied to any dependent system.

It would be fantastic if a fix could be implemented for 6.1r3 so that as soon as the IP address becomes known to HiveOS or changes after a client's DHCP process has concluded, an Interim-Update is then immediately performed.

(All the other devices that we have tested, such as our switches, do this correctly and immediately perform an Interim-Update when the IP address of a client becomes known or changes.)

Websense have an integration for SSO that snoops the RADIUS accounting alone (not auth) for the Framed-IP-Address in a stateless manner. It is similarly affected by this issue in HiveOS that causes it to not become privy to the IP in a timely, reasonable manner.

See: http://www.websense.com/content/suppo...

A second issue with the Framed-IP-Address in RADIUS accounting is that HiveOS should only account with the authoritative IP address that has been snooped from the DHCP exchange.

It should never account based on an IP address that a device happens to be using as this is security vulnerable to spoofing, accidental or intentional. We have noticed that the IP address that HiveOS considers a client to have is not based solely on DHCP snooped information making the data that accounting is performed with falsifiable/inaccurate where a static and/or secondary IP address is in use. It would be great if consideration could be given to resolving this security issue in 6.1r3.

This also affects the client IP address information that is available via syslog, SNMP or within HiveManager.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes

Posted 5 years ago

  • 9
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Below is some debugging information from our Network Policy Server extension that maintains a state table of active sessions.

We can observe HiveOS always taking 20 seconds in its default configuration to first account with the client's IP address from session start in an Interim-Update.

(It is possible to dial down the default accounting period to 10 seconds reducing the window but this is still a user perceptable delay and it doubles the load on the RADIUS server. It should be possible to set the accounting period to something sensible like 180 seconds and not have this issue.)

In the highlighted area of the screenshot, we can furthermore see that HiveOS has accounted with a Framed-IP-Address AVP of 10.15.67.122, overwriting the address that was previously accounted with for the session that was obtained via DHCP. (10.15.67.122 is a secondary IP address that a client is using that has never been issued via DHCP.)

Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Ack. This is actively under consideration.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
For some perspective, we are clearly a customer from hell for Aerohive who wants to get something working that many people are not doing today in anger.

Aerohive's products are awesome, I am a strong proponent, day to day we rarely see issues. (No, nobody has asked me to write this!)

What we are doing is, for the moment, a relatively atypical use case but is something I hope will see wider deployment down the line. Single Sign On really is enabling and awesome when it works properly.

These RADIUS issues are all part of the scaffolding required to get it going reliably.

When I have documented them, I often forget the part where the grand vision is explained and just stick to the abstract technical facts.

We embarked on a single sign on project because we wanted to ensure that within our network that with a single 802.1X log in, accurate and granular Web filtering and tracking was possible for users accessing the network via unmanaged 'BYOD' clients (not domain joined).

The key requirement for us was to avoid the need to use a second, inconvenient and often insecure login via a captive Web portal or HTTP challenge and to do so in a secure, robust and reliable way that was vendor agnostic and standards based.

You cannot do this properly with Syslog or SNMP integration.

The good news is that it is something that will be released for general consumption if-and-when all the Lego bricks are in place to make it work well.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Cisco's documentation is an interesting background read in this area:

http://www.cisco.com/en/US/docs/ios-x...

They comment that in their implementation:

"The Framed-IP-Address AV pair (Attribute 8) is sent only if a valid Dynamic Host Control Protocol (DHCP) binding exists for the host in the DHCP snooping bindings table."

This is to address the security concerns that exist otherwise.

---

On the frequency of updates:

RFC 2869 defines the optional Acct-Interim-Interval RADIUS attribute.
http://www.ietf.org/rfc/rfc2869.txt

There, comment is made that:

"The Value field contains the number of seconds between each interim update to be sent from the NAS for this session. The value MUST NOT be smaller than 60. The value SHOULD NOT be smaller than 600, and careful consideration should be given to its impact on network traffic."

Obviously, we should be mindful that the RFC harks back from the year 2000 and read it in that context, but the present default cadence of 20 seconds is arguably too short and unnecessary if an interim update is performed immediately when something pertinent changes. (Conceptually, it is like polling vs event based notification, the latter is always a better design where achievable.)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
geekonastick commented on this:

[That is] "similar behaviour to my findings today with FortiAuthenticator.. SSO (w/ UserName + Framed-IP-Address). Acct stop block Internet"

This is interesting and, at first sight, could be due to an oversight/limitation in Fortinet's FortiAuthenticator.

HiveOS is documented as sending a Stop for the old session before a Start for the new session that is created when a roam occurs. (This is perfectly reasonable behaviour and is in line with what the RFC expects/requires: A new session is created when a roaming event occurs but the RFC doesn't specify the order that is expected.)

This means that an SSO implementation that integrates with RADIUS must defer acting upon a Stop where there is an Acct-Multi-Session-Id (dynamically generated, constant across sessions that share the same EAP authentication) for around 10 seconds to handle the case where a new session is started with the same Acct-Multi-Session-Id.

It means, therefore, that an SSO implementation must maintain an appropriate state table to know about related sessions that share an Acct-Multi-Session-Id to be correctly implemented.

To play nicely with implementations that do not perform appropriate correlation around the Acct-Multi-Session-Id, HiveOS could be friendly and be enhanced to send an immediate Interim-Update when a roam occurs, reasserting the IP for the client for the new session. (The information could also be included in the Start, but it is less likely to be acted upon.)

Is this something that might be considered?

I wonder if Websense is implemented correctly here... My strong suspicion is that it will not be.
Photo of thewifigeek

thewifigeek, Champ

  • 86 Posts
  • 12 Reply Likes
For notation only...
AMSI == Acct-Multi-Session-Id (type 50)
ASI == Acct-Session-Id (type 44)
RADIUS = Network Policy Server (Win 2008 R2).

After some pcap investigations, comments below:
1. AH sends RADIUS Accounting (stop) when 1X client power save, intra-roam or inter-roam.
2. The inter-roam establishes GRE from new AH to source AH to preserve IP address of client. Verify using show station and show gre.
3. 20 seconds after Account (start) on new AH, AH RADIUS Acct interim update with preserved IP address (Framed-IP-Address).
4. On radius logs, Client1 is assigned different AMSI to Client2.
5. When Client1 roams to another AP, on radius, maintains same AMSI but different ASI as expected. This means Client1 on iPad (user) and Client2 on Win8 (same user account) will obtain different AMSI linked to the same 1X user account.

It makes sense to use AMSI on SSO platform (i.e. in my case, Fortinet FortiAuthenticator) however I do not believe popular Wifi Vendors send AMSI. I also like the idea of deferring the deletion of SSO client entry off the SSO platform if a new Start message is received within given period for a given AMSI... I would like to see this configurable 10 to 60s. This last paragraph could be possible feature request(s) to Fortinet and other SSO platforms.

As this is an Aerohive forum, would you consider an immediate interim-update when 1X client roams to another AP? Perhaps sending an interim-update upon completion of identifying Device OS type via DHCP?

Thanks for your time. Thanks to Nick for "dragging" me into this thread :-P
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Interesting... Do other wireless vendors really not do this correctly!?

See both:

http://tools.ietf.org/html/rfc2866#se...
http://tools.ietf.org/html/rfc3580#se...

The Acct-Session-Id is not expected to be unique across NASes so it can never be treated as being such by an SSO implementation, especially in a vendor heterogeneous environment. (To avoid collisions, an implementation therefore must combine it with another identifier that uniquely identifies the NAS, typically NAS-Identifier but possibly NAS-IP-Address or NAS-IPv6-Address).

Oh, and no problem! ;)

Nick
Photo of thewifigeek

thewifigeek, Champ

  • 86 Posts
  • 12 Reply Likes
I know of one other wireless vendor that does not send AMSI......

RFC3580 is categorised Informational. Perhaps is not mandatory requirement?

Just keeping you in the loop, Fortinet has agreed to enhance FortiAuthenticator code but no confirmed dates as yet :-P

Aerohive, have you considered any dates for the interim-update feature? This would help reduce the amount of Acct messages to FortiAuthenticator.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Who is this other vendor?
Photo of thewifigeek

thewifigeek, Champ

  • 86 Posts
  • 12 Reply Likes
it's pretty obvious...
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Strictly, yes, Acct-Multi-Session-Id use is not mandatory in either RFC 2866, where it is defined, or RFC 3580, where the expected behaviour for 802.1X is specified, but this is because it is only relevant to NASes that support roaming... It also only possible in an environment where there is coordination between the APs where such an identifier can be shared.

It is one of those optional aspects of the specs that must be implemented for it to work correctly where roaming between multiple APs takes place otherwise you lose track of the connection. Without it, you have no constant and unique session id - that's spectacularly broken for accounting purposes!

It is not at all useful to persist the Acct-Session-Id value across a roam as, by the RADIUS spec, they are always to be treated as being unique only on a per-NAS basis to avoid collisions with other NASes.

(Identical values for independent, unrelated sessions on different APs are perfectly legal and valid and to be expected.)

The other vendor should definitely be encouraged with a large stick to fix this therefore to start using the Acct-Multi-Session-Id AVP so that you get sane, usable accounting that ties a client's connection to its constituent sessions.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Quick update...

I have just tested to observe what, if anything, has changed between 6.1r2 and 6.1r3.

The Framed-IP-Address handling behaviour has not changed, so here's hoping for 6.1r4! I have heard on the grape vine that this is still being considered.

The things that did change, and were not in the release notes:

1) The Acct-Session-Id attribute that was previously missing in Accounting-On and Accounting-Off packets is now present.
2) The Service-Type attribute now present.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Is it possible to get a reconsideration of this all these months on? After chasing with the reseller I have been told that it was apparently considered a feature request and not a bug, yet this was never relayed back. Honestly, I am somewhat unhappy about this and I cannot agree with this determination.

If we take a look at the RADIUS specifications by the book:

RFC 2869 defines the Acct-Interim-Interval attribute and specifies the lowest interval that a NAS may send an Interim-Update on. (It further clarifies RFC 2866 where the Interim-Update form of Accounting-Request packet is defined.)

The RFC mandates that the interval must not be lower than 60 seconds (1 minute) and should not in typical use cases be lower than 600 seconds (10 minutes).
 
HiveOS is not conformant to this lower bound by a factor of 3 as it defaults to sending Interim-Updates for a client's connection every 20 seconds, and this can be configured down to 10 seconds, a violation of lower bound of the specification by a factor of 6.
 
Under section 2.1 it is stated that:
"The Network and NAS CPU load of using Interim Updates should be carefully considered, and appropriate values of Acct-Interim-Interval chosen."
 
Under section 5.16 it is specified that:
"The Value field contains the number of seconds between each interim update to be sent from the NAS for this session. The value MUST NOT be smaller than 60.  The value SHOULD NOT be smaller than 600, and careful consideration should be given to its impact on network traffic."
 
HiveOS clearly does not meet these requirements. Surely this makes the issue underpinned by a bug? If the HiveOS were compliant it would not make the client’s IP address available for a minimum of 60 seconds. That would clearly be bonkers as you would leave a client waiting for a whole minute before Internet access became available where RADIUS-accounting based SSO is in use.

(Other similar NASes that have been tested default to a sane value for Interim-Updates, do not permit configuration below the mandatory 60 seconds and immediately send an Interim-Update when a client's IP address becomes known or changes.)
 
Some RADIUS servers, such as Cisco's and FreeRADIUS, furthermore implement rate limiting / denial of service protection to ensure that if RADIUS accounting packets are received too frequently from a NAS, they are discarded.
 
While the behaviour of sending an immediate Interim-Update when a client’s IP address becomes known or changes is not specified in any RADIUS RFC (many things are not), it is necessary and implicit. It follows as a logical requirement for any NAS that populates the Framed-IP-Address attribute based on DHCP snooped information if it wishes to make this information available in a timely manner that can be acted upon.

The other concern is with logging. Because Interim-Updates are performed so frequently, this makes any unfiltered logging that is performed to a database result in huge datasets containing vast amounts of redundant, duplicated information. This has a negative impact as the logs have to be truncated quickly and detailed access history is quickly then lost. Additionally, as with all large datasets, any query to be performed against them is unduly slowed. This clearly would impact many Aerohive customers who perform such logging.
(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I should probably add to this a breakdown of what I think should be changed in this area to fix things:

  • Defaulting to the sensible accounting Interim-Interval of 600 seconds (10 minutes).
  • Not permitting the Interim-Interval to be configured to a value less than 60 seconds (1 minute).
  • Enhancing the code to always treat a DHCP snooped IP address as being authoritative over other IP addresses a client may be using / sending ARPs out for that have no been acquired via DHCP. (Only one Framed-IP-Address attribute can be present and this is a correctness and security hardening measure to help close the spoofing vulnerability.)
  • Offering a configuration option to only use the DHCP snooped IP address as a source of information to further security harden the accounting and information shown in HiveManager.
  • Enhancing the code to always send an immediate Interim-Update when a client's IP address becomes known or changes.
(Edited)
Photo of Joe

Joe, Product Management

  • 13 Posts
  • 2 Reply Likes
Nick, apologies for the long delay as this somehow felt through the crack.  While I am new to Aerohive, I understand the general issue will ask engineering to investigate.  One clarification I'd like to get, since the correct address should be from DHCP, why do you still want an option in HM?
(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
HiveOS will still capture a client's IP even if it has not been obtained via DHCP.

The issue that has been observed is that when a client has multiple IP addresses with one being obtained via DHCP the others set by some other means, the DHCP address is not treated as being authoritative and used in preference.

This means that HiveOS will often today account to RADIUS with an incorrect IP address and HiveManager will show this too:



In practice this is an issue with some Android phones that like to use a secondary self assigned IP address in the 10.0.0.0/8 range. (The client in the above screenshot still has a DHCP issued address in the 192.168.0.0/16 range.)

Finally, as a further hardening measure against a bad acting client that uses a static IP to spoof another, HiveOS should have a configuration option to only use the DHCP snooped information for a client when determining its IP address. This would mean that no address would be shown for clients that are using a static IP so it presumably should be disabled by default.
(Edited)
Photo of Robin Breathe

Robin Breathe

  • 1 Post
  • 1 Reply Like
Strong +1 for treating DHCP assigned addresses as authoritative. The invalid accounting and reporting data that results from the current behaviour bites us frequently.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Have you considered opening a support case on this behaviour too?

Honestly, I am pleased that it is not just me, 'doing something weird', that is being bitten by this in a deployment scenario!
(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Robin,

Another present concern in that we are meant to track a client's connection via all its constituent sessions with APs based on the Acct-Multi-Session-Id and not via the Acct-Session-Id.

Presently, for a new client connection, the Acct-Multi-Session-Id value is not provided in the Start Accounting-Request packet, it is introduced in a subsequent Interim-Update Accounting-Request packet.

If a client roam happens sufficiently quickly before this value has been received, you lose the ability to properly correlate all the constituent sessions to a client's connection based on the original EAP authentication.

We do need guaranteed asynchronous updated for pertinent information changes to fix this properly or the Acct-Multi-Session-Id value should be included in the Start Accounting-Request packet for a session.

I do not see all these issues as constituting a feature request, rather as an existing feature that does not work correctly. If it was consciously and intentionally designed like this, from my perspective, the design should be considered defective and resolving the related issues should be treated as a bug with a higher priority rather than a nice-to-have.

So, I remain hopeful that this will get revisited in a future release. I have heard that it is on the cards for further consideration.

Nick
(Edited)
Photo of Joe

Joe, Product Management

  • 13 Posts
  • 2 Reply Likes
Nick et al.,

Just want to have a quick note that we are planning to put this in, but at this point I don't have a specific timeline.  

Joe.
Photo of Paul Marchbank

Paul Marchbank

  • 2 Posts
  • 0 Reply Likes
Can we get a commitment to a specific timeline then please?
(Edited)
Photo of Paul Marchbank

Paul Marchbank

  • 2 Posts
  • 0 Reply Likes
Joe,

Like Robin, also being bitten by incorrect Framed-IP-Address values. Why is this taking so long to fix? The issue looks like it has been very clearly spelled out here.

From a pragmatic viewpoint, it seems to me that the most egregious issues here that need to be fixed in the next release are:

  1. The value used for the Framed-IP-Address being corrected so that the DHCP acquired address is authoritative. Not doing this is clearly buggy behaviour. Engineering effort should go in to this as APs are sending invalid accounting data. A really big no no.
  2. The AMSI should be included in the Start so that the value of it is never lost in a fast roaming situation. Engineering effort should go in to this as not being able to link sessions back to the original authentication in all cases is clearly buggy behaviour and is a big no no.
RADIUS accounting is a bread and butter feature of high end APs. Sure, it's not a glamorous feature, but you should get this right as we all implicitly expect this to just work when we need it.

Performing asynchronous updates for the Framed-IP-Address and guaranteeing that one will be sent on client address change is something that would be really great to see, but it isn’t as essential to see a fix ASAP.

Clearly, you should be respecting the RADIUS RFCs and only account within the bounds of the Acct-Interim-Interval, defaulting to the RFC recommended interval. However, it does not make a whole lot of sense to change this until asynchronous updates are implemented as it could regress existing use cases until then.

Thanks,

Paul
(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Personally, I would like to see fixes/improvements made definitively in one release rather than in a piecemeal fashion over subsequent releases as, from experience, it tends to just complicate things further.
(Edited)
Photo of Joe

Joe, Product Management

  • 13 Posts
  • 2 Reply Likes
I will get a better idea of the timing in a couple weeks.  I got in this late so I am trying to get it in as soon as we can.  That said, for the default interval, we may not change it right away as it may impact existing applications.  Rather, what I am looking at is to send out interim update asynchronously (immediately) once the dhcp address is snooped.  Make sense?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Thanks, Joe. A couple of points:

  • What happens if the address changes? Snooping should be a continuous process so we should see an asynchronous update in such an eventuality.
  • Can HiveOS be changed to only ever include the Framed-IP-Address AVP where an address has been DHCP snooped, otherwise omitting it? (As Cisco do.)
  • Can HiveOS be changed to consider a DHCP snooped address as being authoritative so that the client address shown in HiveOS and HiveManager is 'accurate'? (This in lieu of something more fancy that handles clients with multiple addresses showing the source of the information.)
On the interval front, it's not a big deal as we can configure it to a sane value. However, as most other devices won't even let you configure as low as HiveOS defaults to and the present default causes real loading issues in large networks, I do think that you should reconsider what the default is when balancing impact. That seems the best compromise as you can still let people configure down to 10 seconds if they really want to.

What existing applications do you see as being potentially impacted? Any hypothetical application that did have a dependency on such frequent updates would be in violation of the RADIUS RFCs so, to me, it seems very low risk.

Doing the maths for 2000 clients at the default interval of 20 seconds shows that an update will be performed on average every 0.01 seconds, 100 every second. If the RADIUS server jitters, I/O completion is a common cause, those updates can easily coalesce causing loading spikes. Unfiltered logging also easily becomes a nightmare.

Perhaps best to discuss further 'offline' rather than bouncing this thread more.
I wasn't originally planning on resurrecting this thread, honest!
(Edited)
Photo of Nick Brooker

Nick Brooker

  • 8 Posts
  • 2 Reply Likes
On a kind of related note...We have a slightly odd issue (thewifigeek will probably know this one) with 330s not sending RADIUS accounting information to our FortiAuthenticator. 

There are 90 odd APs and we have a couple that don't send interim-updates so the authenticator doesn't track users and so won't allow them Internet access. We've reset them and reconfigured them with no joy and only replacing them works.  So I'm not sure if there are hardware differences or if it just luck the replacements (which are older ones from our stock) work.

Packet captures show the AP sending an accounting on and authentication messages but no interim updates.  They originally had 6.1r3 and were recently updated to 6.1r6 but reverting didn't seem to fix the problem.

Anyone else seen this?

Thanks

Nick
Photo of thewifigeek

thewifigeek, Champ

  • 86 Posts
  • 12 Reply Likes
howdy!

So the replaced units (with same static IP) works?!?  

In the packet captures, are there Accounting Messages with Acct-Status-Type set to interim-update (not start/stop) and contains Framed-IP-Address? 
Photo of James Ball

James Ball

  • 4 Posts
  • 0 Reply Likes
Hi,

Does anyone know if the Interim Update delay of 20 seconds has been addressed in anyway in 6.2r1?

James
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Nothing changed in 6.2r1.

The default interval is still 20 seconds, but you have always been able to configure it to something sensible like 300 seconds.

The underlying issue with the Framed-IP-Address, making the client's IP address available, has been resolved in 6.4r1.
Photo of James Ball

James Ball

  • 4 Posts
  • 0 Reply Likes
Thanks,

Did you mean 6.3r1?

James
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
No, 6.4r1 that is currently in testing.

There's some information on the release schedule here:

http://www.aerohive.com/support/security-center/security-bulletins/psa-cve-2014-3566-poodle
(Edited)
Photo of James Ball

James Ball

  • 4 Posts
  • 0 Reply Likes
Great,

Thanks Nick,
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
So, the awesome news is that 6.4r1 has shipped and the Framed-IP-Address attribute is now populated with DHCP-snooped information only and it is sent asynchronously in an Interim-Update where needs be.
(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Just to update this thread all these months later for those who are following. HiveOS 6.6r1 is largely there with regards to its RADIUS accounting. There's a great set of fixes in it with regards to RADIUS generally. Well worth updating...

As for what remains that I am aware of:

1) There is a bug where the Acct-Multi-Session-Id is intermittently missing for a session. This is a blocking bug for session tracking as the value is needed to keep track of a session when a roam occurs from one BSS to another. Show in a screenshot from Wireshark. The left hand side shows the attribute missing, the right shows it present as expected:


(For unrelated testing purposes, a Class attribute wasn't sent by the RADIUS server here but one is usually included.)

2) Additionally, there is a flaw in the Acct-Session-Id format. It is not constructed in a way where it is guaranteed to be globally unique, across reboots etc. Presently, it is conceptually possible for an Acct-Session-Id to be reused. This is a rare event though and we're unlikely to observe this happening day-to-day. (All session IDs should have the properties of a GUID/UUID.)

3) There is an edge case bug where the new Acct-Delay-Time can give a bogus value as HiveOS incorrectly uses the system clock to calculate the delay when it should be using a monotonic system timer. Such a timer isn't vulnerable to shifts from NTP sync etc. (In reality, this is only tangibly noticeable at boot when you get a shift from the UNIX time epoch to the current time.)

4) There is an issue where the Acct-Multi-Session-Id occasionally contains whitespace. This strictly complies to the RFC but this can trip up code that expects a printable UTF-8 encoded value without whitespace. This ought to be changed so that whitespace is never present.
(Edited)