On 06/06/2011 07:27 PM, Bruno Tiago Rodrigues wrote: > The standard radiator dictionary file specifies at least a pair of > invalid entries sharing the same ID. > Apparently, Ascend defines a set of attributes on the global (IANA > assigned) range. > > ATTRIBUTE X-Ascend-FCP-Parameter 119 string - > conflicts with Digest-Domain > ATTRIBUTE X-Ascend-Modem-PortNo 120 integer - > conflicts with Digest-Stale > ATTRIBUTE X-Ascend-Modem-SlotNo 121 integer - > conflicts with Digest-HA1 > ATTRIBUTE X-Ascend-Modem-ShelfNo 122 integer - > conflicts with SIP-AOR > ATTRIBUTE X-Ascend-Call-Attempt-Limit 123 integer - > conflicts with Delegated-IPv6-Prefix > > (Possibly more. See > http://www.iana.org/assignments/radius-types/radius-types.xml for > reference) > > These entries show up on the dictionary.ascend file (which makes > sense, some people might still be using equipment with the "invalid > ID" Ascend attributes) but for the rest of the crowd deploying IPv6 > (for instance), it takes a few hits at the standard dictionary file to > comment out the "old" lines, as these entries still show up there. > > I was wondering if this could be fixed (or at least documented) on the > next releases.
I'll check about adding these to Radiators dictionary. If the attributes from IANA are added after the conflicting old Ascend attributes, then Radiator will treat e.g., incoming attribute 119 as Digest-Domain. About attributes 126-132 that Alan mentioned, those are already in dictionary. The dictionary has the old Ascend attributes first followed later by IANA versions of 126-132. As a result one can this: ./radpwtst -trace 4 -noacct Operator-Name=4 or this ./radpwtst -trace 4 -noacct Ascend-Route-Preference=4 but in both cases Radiator sees attribute 126 as Operator-Name with results like this respectively: Operator-Name = "4" Operator-Name = "<0><0><0><4>" Since Operator-Name is a string and Ascend-Route-Perference is an integer, radpwtst packs a string or int into outgoing request. When Radiator receives the attribute it always treats it as a string. So adding the IANA attributes 119-123 after the Ascend attributes would bring them available for Radiator and for example, radpwtst could be used with old Ascend and the current IANA attributes. It might also be possible to remove the old Ascend attributes completely, but I'm not sure if that changes anything as long as the current IANA attributes are defined in the dictionary too. I'll do some research about this. Thanks! -- Heikki Vatiainen <h...@open.com.au> Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator