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