Radius Accounting issue with 330 and 320 series Ap's

  • 2
  • Question
  • Updated 3 years ago
  • Answered
We are seeing the errors message from our 330 and 320 Aerohive AP's to Cisco ACs 5.2 RADIUS request dropped: RADIUS packet contains invalid attribute anyone seen this before? The only way we can stop it is to disable accounting on the AP's.
Photo of Andy


  • 2 Posts
  • 0 Reply Likes

Posted 5 years ago

  • 2
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2486 Posts
  • 448 Reply Likes
Does it tell you which attribute it considers to be invalid?

HiveOS's Acct-Multi-Session-Id is also certainly dubious as it does not contain printable text in UTF-8 encoded 10646 characters as it really should do per the RFCs. (It is not strictly mandatory just strongly recommended and sane, however.)

Rather, it is 10 or so bytes of binary data, probably from an internal data structure that was convenient to use.

It is certainly broken for many logging purposes, which expect text, therefore.That classifies it as invalid in my books.

It should really be in the format:

Original AP MAC Address | Supplicant MAC Address | NTP Timestamp

For example:


RFC 2866 states:

5.11. Acct-Multi-Session-Id


This attribute is a unique Accounting ID to make it easy to link together multiple related sessions in a log file. Each session linked together would have a unique Acct-Session-Id but the same Acct-Multi-Session-Id. It is strongly recommended that the Acct-Multi-Session-Id contain UTF-8 encoded 10646 [7] characters.

RFC 3580 states:

2.2. Acct-Multi-Session-Id

The purpose of this attribute is to make it possible to link together multiple related sessions. While [IEEE8021X] does not act on aggregated ports, it is possible for a Supplicant roaming between Access Points to cause multiple RADIUS accounting packets to be sent by different Access Points.

Where supported by the Access Points, the Acct-Multi-Session-Id attribute can be used to link together the multiple related sessions of a roaming Supplicant. In such a situation, if the session context is transferred between Access Points, accounting packets MAY be sent without a corresponding authentication and authorization exchange, provided that Association has occurred. However, in such a situation it is assumed that the Acct-Multi-Session-Id is transferred between the Access Points as part of the Inter-Access Point Protocol (IAPP).

If the Acct-Multi-Session-Id were not unique between Access Points, then it is possible that the chosen Acct-Multi-Session-Id will overlap with an existing value allocated on that Access Point, and the Accounting Server would therefore be unable to distinguish a roaming session from a multi-link session.

As a result, the Acct-Multi-Session-Id attribute is unique among all the bridges or Access Points, Supplicants and sessions. In order to provide this uniqueness, it is suggested that the Acct-Multi-Session-Id be of the form:

Original AP MAC Address | Supplicant MAC Address | NTP Timestamp

Here "|" represents concatenation, the original AP MAC Address is the MAC address of the bridge or Access Point at which the session started, and the 64-bit NTP timestamp indicates the beginning of the original session. In order to provide for consistency of the Acct-Multi-Session-Id between roaming sessions, the Acct-Multi-Session-Id may be moved between Access Points as part of IAPP or another handoff scheme.

The use of an Acct-Multi-Session-Id of this form guarantees uniqueness among all Access Points, Supplicants and sessions. Since the NTP timestamp does not wrap on reboot, there is no possibility that a rebooted Access Point could choose an Acct-Multi-Session-Id that could be confused with that of a previous session.

Since the Acct-Multi-Session-Id is of type String as defined in [RFC2866], for use with IEEE 802.1X, it is encoded as an ASCII string of Hex digits. Example: "00-10-A4-23-19-C0-00-12-B2-14-23-DE-AF-23-83-C0-76-B8-44-E8"

RFC 5080 states:

2.3.2. Acct-Session-Id and Acct-Multi-Session-Id

[RFC2866] Section 5.5 describes Acct-Session-Id as Text within the figure summarizing the attribute format, but then goes on to state that "The String field SHOULD be a string of UTF-8 encoded 10646 characters".

[RFC2865] defines the Text type as "containing UTF-8 encoded 10646 characters", which is compatible with the description of Acct-Session-Id. Since other attributes are consistently described as "Text" within both the figure summarizing the attribute format, and the following attribute definition, it appears that this is a typographical error, and that Acct-Session-Id is of type Text, and not of type String.

The definition of the Acct-Multi-Session-Id attribute also has typographical errors. It says:

A summary of the Acct-Session-Id attribute format ...

This text should read:

A summary of the Acct-Multi-Session-Id attribute format ...

The Acct-Multi-Session-Id attribute is also defined as being of type String. However, the language in the text strongly recommends that implementors consider the attribute as being of type Text. It is unclear why the type String was chosen for this attribute when the type Text would be sufficient. This attribute SHOULD be treated as Text.
Photo of Andy


  • 2 Posts
  • 0 Reply Likes
I cannot tell which attribute is malformed but here are the screenshot of my packet capture and error message from ACS.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2486 Posts
  • 448 Reply Likes
I think it tells you the problem down the bottom. The Acct-Session-Id is missing from HiveOS's Accounting-On and Accounting-Off RADIUS accounting packets. They are forms of Accounting-Request packet.

Cisco are correct here therefore. This is a bug in HiveOS as it is in clear deviation to RFC 2866 that states:

5.5. Acct-Session-Id


This attribute is a unique Accounting ID to make it easy to match start and stop records in a log file. The start and stop records for a given session MUST have the same Acct-Session-Id. An Accounting-Request packet MUST have an Acct-Session-Id. An Access-Request packet MAY have an Acct-Session-Id; if it does, then the NAS MUST use the same Acct-Session-Id in the Accounting-Request packets for that session.

The Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters.

For example, one implementation uses a string with an 8-digit upper case hexadecimal number, the first two digits increment on each reboot (wrapping every 256 reboots) and the next 6 digits counting from 0 for the first person logging in after a reboot up to 2^24-1, about 16 million. Other encodings are possible.

Typically, devices send a 'zeroed' value for Accounting-On and Accounting-Off Accounting-Requests packets for which a conceptual session does not exist as it represents global state. (By zeroed, the device specific format should be sent but it must represent a null session on it.)

As HiveOS does accounting per-BSSID/SSID, Accounting-On and Accounting-Off packets are seen per-BSSID/SSID. HiveOS would need to ensure unique Acct-Session-Ids are used per-BSSID/SSID so that a RADIUS server would have no grounds to complain and/or reject.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2486 Posts
  • 448 Reply Likes
Just a quick update... The Acct-Multi-Session-Id issue I mentioned has been resolved in 6.1r2, it is now presented in valid UTF-8 encoded text.

I have been told that the issue with the Acct-Session-Id in Accounting-On and Accounting-Off accounting request packets is being considered.

The specification is clear and non-ambiguous thankfully. Accounting-On and Accounting-Off are forms of Accounting-Request packet and, like the Acct-Status-Type, it is a mandatory attribute in all cases. I have highlighted the part of RFC 2866 below that requires this, 0 is not an option.

5.13. Table of Attributes

The following table provides a guide to which attributes may be found in Accounting-Request packets. No attributes should be found in Accounting-Response packets except Proxy-State and possibly Vendor-Specific.

# Attribute
0-1 User-Name
0 User-Password
0 CHAP-Password
0-1 NAS-IP-Address [Note 1]
0-1 NAS-Port
0-1 Service-Type
0-1 Framed-Protocol
0-1 Framed-IP-Address
0-1 Framed-IP-Netmask
0-1 Framed-Routing
0+ Filter-Id
0-1 Framed-MTU
0+ Framed-Compression
0+ Login-IP-Host
0-1 Login-Service
0-1 Login-TCP-Port
0 Reply-Message
0-1 Callback-Number
0-1 Callback-Id
0+ Framed-Route
0-1 Framed-IPX-Network
0 State
0+ Class
0+ Vendor-Specific
0-1 Session-Timeout
0-1 Idle-Timeout
0-1 Termination-Action
0-1 Called-Station-Id
0-1 Calling-Station-Id
0-1 NAS-Identifier [Note 1]
0+ Proxy-State
0-1 Login-LAT-Service
0-1 Login-LAT-Node
0-1 Login-LAT-Group
0-1 Framed-AppleTalk-Link
0-1 Framed-AppleTalk-Network
0-1 Framed-AppleTalk-Zone
1 Acct-Status-Type
0-1 Acct-Delay-Time
0-1 Acct-Input-Octets
0-1 Acct-Output-Octets
1 Acct-Session-Id
0-1 Acct-Authentic
0-1 Acct-Session-Time
0-1 Acct-Input-Packets
0-1 Acct-Output-Packets
0-1 Acct-Terminate-Cause
0+ Acct-Multi-Session-Id
0+ Acct-Link-Count
0 CHAP-Challenge
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2486 Posts
  • 448 Reply Likes
The issue with the missing Acct-Session-Id has been resolved in 6.1r3, confirmed with a packet capture. You may wish to retest to confirm that the issue you were experiencing has gone away.

Interestingly, it appears that it has been experienced before:

ACS 5.1 with an aerohive AP issue
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2486 Posts
  • 448 Reply Likes
HiveOS prior to 6.6r1 included Acct-Terminate-Cause and Acct-Authentic attributes in the Accounting-On and Accounting-Off forms of Accounting-Request packets that it was sending.

This was against spec as this attribute is only valid in the Stop form of Accounting-Request packet.

5.10.  Acct-Terminate-Cause
      This attribute indicates how the session was terminated, and can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop.
The Acct-Authentic attribute was also dubious as it is only semantically valid in the context of a session:
5.6.  Acct-Authentic
      This attribute MAY be included in an Accounting-Request to
      indicate how the user was authenticated, whether by RADIUS, the
      NAS itself, or another remote authentication protocol.  Users who
      are delivered service without being authenticated SHOULD NOT
      generate Accounting records.


If you are still around, do you know if you ever got this resolved from your perspective?

Not being an ACS user, I do not think that we ever got to the bottom of why this was happening.

It could easily have been the presence of the Acct-Terminate-Cause and/or Acct-Authentic attributes that were causing this issue in these Accounting-Request packets rather than the lack of an Acct-Session-Id.

Your screenshot does state "RADIUS packet contains invalid attribute(s)" in red as well as the fact that the AcctSessionId was missing under detailed info.