On 2006-06-15 11:09, Stefan Winter <[EMAIL PROTECTED]> 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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html