> 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). > 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: > > 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. 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: [EMAIL PROTECTED] Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
pgpxiDC8yyzfv.pgp
Description: PGP signature
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
