(RADIATOR) 2 copies of User-Name attribute

[Dave Kitabjian]

Follow up:

I did some more digging in the RFC:

   Some attributes MAY be included more than once.  The effect of this
   is attribute specific, and is specified in each attribute
   description.

   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

In other words, the accounting record may contain 0 or 1 copies of the
User-Name. That means it's out of spec to send 2 copies. I'll take this
up with Cisco. Meanwhile, I'm still open to feedback on the Radiator
side (since Cisco notoriously drags its feet on our bug reports).

Dave

> -----Original Message-----
> From: Dave Kitabjian 
> Sent: Thursday, February 28, 2002 9:34 AM
> To: radiator at open.com.au
> Subject: (RADIATOR) 2 copies of User-Name attribute
> 
> 
> 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.
> 
===
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.