On 2006-06-15 07:50, Stefan Winter <stefan.winter@restena.lu> wrote:
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.
Essentially, the vendor-specific attribute value is a 1-byte unsigned integer, not a string. Haven't done a live test yet, so I do not know how it handles the empty value. Perhaps all goes well. I'll let you know. My rfc-reading seems to contradict you a little bit, though? RFC2869 section 5: 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 [8] 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. -- Erik Bolsø Linpro AS