\000 in "octets" attribute?

[Erik Bolsø]

On 2006-06-15 07:50, Stefan Winter <stefan.winter at 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