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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
