On 2006-06-15 11:09, Stefan Winter <stefan.winter@restena.lu> wrote:
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.
Then you are supposed to use the "integer" type, not "octets" (then, you don't even have to jump through hoops to achieve a "0": just use the integer 0, no need for \000).
But the radius integer type is a 4-byte value, which is three bytes too long. I've tested that, it doesn't work.
My rfc-reading seems to contradict you a little bit, though?
No. I read this section quite a few times. octets is another word for string, i.e. treat what is in there as undistinguished octets (as opposed to: treat it as an integer). And that's why the section of RFC 2869 is perfectly right: you wanted to send a string that has a \000 (= hex 00, = NUL) as last character. And that's forbidden:
Nothing forbidding a NUL here... "servers and clients MUST be able to deal with embedded nulls". A 1-byte string containing just \000 seems perfectly valid to me.
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.