\000 in "octets" attribute?
Hello. I'm having a curious problem with a vendor-specific single-byte "octets"-attribute and attr_rewrite. attr_rewrite att1 { attribute = Vendor-Specific-Thingie searchin = reply searchfor = "0" replacewith = "\000" } Essentially, I'm trying to rewrite an ascii "0" to a single-byte 0x00 value. But after this rewrite rule, a zero-byte value is returned instead. Any way to get around this? With \001, \002, etc, all's well. (incidentally, this is freeradius version 1.0.1 in RHEL4) -- Erik Bolsø Linpro AS
Hi,
I'm having a curious problem with a vendor-specific single-byte "octets"-attribute and attr_rewrite.
Essentially, I'm trying to rewrite an ascii "0" to a single-byte 0x00 value. But after this rewrite rule, a zero-byte value is returned instead. Any way to get around this?
With \001, \002, etc, all's well.
(incidentally, this is freeradius version 1.0.1 in RHEL4)
the RADIUS RFC forbids attributes with a terminating \000. The server knows that, and will shorten the octet attribute by cutting off the \000 - leaving an empty string behind. If your NAS really requires a trailing \000: fix the NAS. It is not RFC-compliant then. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Stefan Winter <stefan.winter@restena.lu> writes:
I'm having a curious problem with a vendor-specific single-byte "octets"-attribute and attr_rewrite.
Essentially, I'm trying to rewrite an ascii "0" to a single-byte 0x00 value. But after this rewrite rule, a zero-byte value is returned instead. Any way to get around this?
With \001, \002, etc, all's well.
(incidentally, this is freeradius version 1.0.1 in RHEL4)
the RADIUS RFC forbids attributes with a terminating \000. The server knows that, and will shorten the octet attribute by cutting off the \000 - leaving an empty string behind. If your NAS really requires a trailing \000: fix the NAS. It is not RFC-compliant then.
RFC 2865 says "Note that none of the types in RADIUS terminate with a NUL (hex 00). In particular, types "text" and "string" in RADIUS do not terminate with a NUL (hex 00). The Attribute has a length field and does not use a terminator. Text contains UTF-8 encoded 10646 [7] characters and String contains 8-bit binary data. Servers and servers and clients MUST be able to deal with embedded nulls. RADIUS implementers using C are cautioned not to use strcpy() when handling strings." There is nothing here that forbids an attribute containing nothing but a NUL, or ending in NUL. The point is that the NUL in that case must be a *significant part* of the attribute value. RADIUS clients and servers MUST *handle* the NULs, not silently ignore them like string terminators. That is: "blah\000" and "blah" have different value and length, but they are both allowed as attribute values. In particular, integer attributes will often have 0 as value (just grep the dictionary VALUEs), which of course ends in 0. Bjørn
RFC 2865 says
"Note that none of the types in RADIUS terminate with a NUL (hex 00). In particular, types "text" and "string" in RADIUS do not terminate with a NUL (hex 00). The Attribute has a length field and does not use a terminator. Text contains UTF-8 encoded 10646 [7] characters and String contains 8-bit binary data. Servers and servers and clients MUST be able to deal with embedded nulls. RADIUS implementers using C are cautioned not to use strcpy() when handling strings."
There is nothing here that forbids an attribute containing nothing but a NUL, or ending in NUL. The point is that the NUL in that case must be a *significant part* of the attribute value. RADIUS clients and servers MUST *handle* the NULs, not silently ignore them like string terminators.
Reading is a tough task, obviously. They are required NOT to end with a NUL. So,
That is: "blah\000" and "blah" have different value and length, but they are both allowed as attribute values.
blah\000 is an attribute that has a hex 00 as last character, while the RFC says "In particular, types "text" and "string" in RADIUS do not terminate with a NUL (hex 00)." So, it is NOT allowed as an attribute value. Maybe you are confused about _embedded_ NULs. blah\000foo is perfectly fine with the RFC, since the NUL is between other parts, thus _embedded_. blah\000 however isn't. Though I have to admit that FreeRADIUS is in a way not RFC-compliant because it will not handle embedded \000s correctly.
In particular, integer attributes will often have 0 as value (just grep the dictionary VALUEs), which of course ends in 0.
The OP talked about "octets", which is a string. If he would be talking about "integer", a 0 as value would be perfectly fine. Which I told him in my previous reply. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Stefan Winter <stefan.winter@restena.lu> writes:
RFC 2865 says
"Note that none of the types in RADIUS terminate with a NUL (hex 00). In particular, types "text" and "string" in RADIUS do not terminate with a NUL (hex 00). The Attribute has a length field and does not use a terminator. Text contains UTF-8 encoded 10646 [7] characters and String contains 8-bit binary data. Servers and servers and clients MUST be able to deal with embedded nulls. RADIUS implementers using C are cautioned not to use strcpy() when handling strings."
There is nothing here that forbids an attribute containing nothing but a NUL, or ending in NUL. The point is that the NUL in that case must be a *significant part* of the attribute value. RADIUS clients and servers MUST *handle* the NULs, not silently ignore them like string terminators.
Reading is a tough task, obviously. They are required NOT to end with a NUL.
Obviously. Where in the quoted text from the RFC do you find the word "end"?
That is: "blah\000" and "blah" have different value and length, but they are both allowed as attribute values.
blah\000 is an attribute that has a hex 00 as last character, while the RFC says "In particular, types "text" and "string" in RADIUS do not terminate with a NUL (hex 00)."
"terminate with" != "end with" The RFC talks about NULs used as terminators. A terminator is a character that is not part of the string, but is used merely to signify the end of data. Bjørn
participants (3)
-
Bjørn Mork -
Erik Inge Bolsø -
Stefan Winter