(RADIATOR) 2 copies of User-Name attribute

[Hugh Irvine]

Hello Dave -

I'm glad I didn't have to point you to that section of the RFC.

:-)

The easy way to deal with the problem is with a PreClientHook to remove any 
duplicate attributes.

You know where to find the examples ("goodies/hooks.txt").

cheers

Hugh


On Fri, 1 Mar 2002 03:02, Dave Kitabjian wrote:
> 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.

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
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.