(RADIATOR) 2 copies of User-Name attribute

[Dave Kitabjian]

Recently I've been noticing that the Radius Accounting packets coming
from some of our Cisco gear has been sending some attributes in
duplicate; in particular, we get two copies each of User-Name and
Nas-Port.

Fortunately, the two copies have identical values. But it still causes a
problem. We have lots of logic that rewrites usernames, parses out the
realm, adds in custom attributes, etc. The problem is that Radiator's
RewriteUserName appears to be only acting on the FIRST instance of the
User-Name attribute, and the 2nd instance remains unrewritten. Down the
line, our post-processing software doesn't know how to tell which one is
the "right one", and so we get messed up results.

I've asked our networking people to look into why we're getting dups of
some attributes. But meanwhile, I checked out the Radius Accounting RFC
(http://www.ietf.org/rfc/rfc2866.txt?number=2866), and I noticed this:

   Attributes

      Attributes may have multiple instances, in such a case the order
      of attributes of the same type SHOULD be preserved.  The order of
      attributes of different types is not required to be preserved.

So this makes me wonder if Radiator should not be able to support this.
Without looking deep into the code, my guess is that the attributes are
stored in a hash, and much of the logic depends on assuming the key is
unique, which would make support for this difficult to add. But perhaps
at least supporting it for RewriteUserName would be sensible?

Your thoughts are welcome...

Dave
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.