RE: VSA id's higer than 255
I was writing to check if support for VSA Id's higher than 255 has been added in freeRadius 1.0.5. I will appreciate any feedback you guys might have. Regards, Swaran Sethi -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan DeKok Sent: Tuesday, August 02, 2005 2:09 PM To: FreeRadius users mailing list Subject: Re: VSA id's higer than 255 Michael Lecuyer [EMAIL PROTECTED] wrote: The format for the long tag VSA is the same as the standard Vendor-Specific attribute (8 bit tag, 8 bit length) but the sub-attribute tag field has been expanded to 16 bits. The sub-attribute length field remains 8 bits. That doesn't sound too bad. All vendor specific attributes are coded using 16-bit attribute type in network byte order and Lucent-Vendor-Id (4846) as Vendor-Id. That makes it easier. I believe the support for long Vendor-Specific tags was discussed here in the past with limited interest in support. It's about 40 lines of code to support. The weirdness that I recall was Nortel, which mixed normal VSA's, and USR-style VSA's in the same vendor space. 192.168.1.1 ... VendorLongTags=Ascend - indicating that Ascend VSA's use long tags and all other VSA's like Cisco) would be short. Ascend / Lucent VSA's do not always use long tag VSAs. If it's always that the Lucent attributes use 16-bit id's, it's OK. This introduction of long tags is a real wart for every RADIUS server. There are probably other ways to have avoided 16 bit tags. Naturally the offender is too big to ignore and arbitrarily forced the issue. Remember that in the past Ascend (pre-Lucent) grabbed unassigned RADIUS attributes (from 119 to 255) without thinking there might be a problem with that either. Yup. I'll add something to the CVS head. Grab a snapshot in a few days, and see if it works. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: VSA id's higer than 255
Swaran S. Sethi [EMAIL PROTECTED] wrote: I was writing to check if support for VSA Id's higher than 255 has been added in freeRadius 1.0.5. I will appreciate any feedback you guys might have. It's not in 1.0.5, and I'm not sure it will be. It's in the CVS head, including Starent attributes, which are 16/16 bits. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: VSA id's higer than 255
Thanks Alan. -Swaran -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan DeKok Sent: Thursday, November 10, 2005 3:45 PM To: FreeRadius users mailing list Subject: Re: VSA id's higer than 255 Swaran S. Sethi [EMAIL PROTECTED] wrote: I was writing to check if support for VSA Id's higher than 255 has been added in freeRadius 1.0.5. I will appreciate any feedback you guys might have. It's not in 1.0.5, and I'm not sure it will be. It's in the CVS head, including Starent attributes, which are 16/16 bits. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: VSA id's higer than 255
Fawaz Qamhawi [EMAIL PROTECTED] wrote: We are using freeradius 1.0.4 and having a problem with VSA id's higher than 255 (more than 8 bit). Hmm.. those aren't in the standard dictionaries that I can see. When one of the attributes above are sent back to the NAS, it seems that radius is sending it as 8 bit thus interpreted as something else on the Lucent NAS. The code in src/lib/radius.c is responsible. It should be checking for attributes above 255, and discarding them. Any simple solution for that ? How are the attributes supposed to be encoded in the packet? The normal VSA's use one byte to represent vendor attributes. Since 287 won't fit into ne byte, something else has to be done here. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: VSA id's higer than 255
Ascend (as Lucent) has been introducing tags with values higher than 256 in the VSA's for a while (first message I saw where the problem of long tags was mentioned was from January 2004). An example from their dictionary shows: ATTRIBUTE Ascend-MOH-Timeout 261 integer The format for the long tag VSA is the same as the standard Vendor-Specific attribute (8 bit tag, 8 bit length) but the sub-attribute tag field has been expanded to 16 bits. The sub-attribute length field remains 8 bits. All vendor specific attributes are coded using 16-bit attribute type in network byte order and Lucent-Vendor-Id (4846) as Vendor-Id. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attr Type | Length | Vendor-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id (cont) | Vendor Type(16-bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Length | Vendor-value.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- I believe the support for long Vendor-Specific tags was discussed here in the past with limited interest in support. It seems that this is on a NAS by NAS basis and only some of the VSA's are using the 16 bit tags. The solution seems to be to indicate that long tags are used by this NAS for particular vendors. Something like: 192.168.1.1 ... VendorLongTags=Ascend - indicating that Ascend VSA's use long tags and all other VSA's like Cisco) would be short. Ascend / Lucent VSA's do not always use long tag VSAs. This introduction of long tags is a real wart for every RADIUS server. There are probably other ways to have avoided 16 bit tags. Naturally the offender is too big to ignore and arbitrarily forced the issue. Remember that in the past Ascend (pre-Lucent) grabbed unassigned RADIUS attributes (from 119 to 255) without thinking there might be a problem with that either. Alan DeKok wrote: Fawaz Qamhawi [EMAIL PROTECTED] wrote: Any simple solution for that ? How are the attributes supposed to be encoded in the packet? The normal VSA's use one byte to represent vendor attributes. Since 287 won't fit into ne byte, something else has to be done here. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: VSA id's higer than 255
Michael Lecuyer [EMAIL PROTECTED] wrote: The format for the long tag VSA is the same as the standard Vendor-Specific attribute (8 bit tag, 8 bit length) but the sub-attribute tag field has been expanded to 16 bits. The sub-attribute length field remains 8 bits. That doesn't sound too bad. All vendor specific attributes are coded using 16-bit attribute type in network byte order and Lucent-Vendor-Id (4846) as Vendor-Id. That makes it easier. I believe the support for long Vendor-Specific tags was discussed here in the past with limited interest in support. It's about 40 lines of code to support. The weirdness that I recall was Nortel, which mixed normal VSA's, and USR-style VSA's in the same vendor space. 192.168.1.1 ... VendorLongTags=Ascend - indicating that Ascend VSA's use long tags and all other VSA's like Cisco) would be short. Ascend / Lucent VSA's do not always use long tag VSAs. If it's always that the Lucent attributes use 16-bit id's, it's OK. This introduction of long tags is a real wart for every RADIUS server. There are probably other ways to have avoided 16 bit tags. Naturally the offender is too big to ignore and arbitrarily forced the issue. Remember that in the past Ascend (pre-Lucent) grabbed unassigned RADIUS attributes (from 119 to 255) without thinking there might be a problem with that either. Yup. I'll add something to the CVS head. Grab a snapshot in a few days, and see if it works. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
