\000 in "octets" attribute?

[Bjørn Mork]

Stefan Winter <stefan.winter at restena.lu> writes:

>> Seems to work here, as long as the attribute is of type "octets".
>
> Hm, what exactly do you mean? 
>
>> Calling-Station-Id =\000
>>
>> results in:
>>
>>         Calling-Station-Id = ""
>
> This is the behaviour I described as fine (the \000 is kicked since it is the 
> last character, 

In fact, the string will always be cut off at \000.  But I guess this
may be caused by the files parser and/or radclient.

> and what remains is a completely empty attribute), and what 
> your colleague would probably describe as bad: he thinks, the \000 should be 
> sent in the packet.
>
> Actually, I don't think that Calling-Station-Id is on the wire at all, since 
> empty attributes are supposed to be suppressed. And that's why the packet 
> arrives on the server without this attribute:

Correct.  And as long as the resulting string on the client is "",
then that's also correct behaviour.  No discussion there

>> Received on the server as:
>>
>> Packet-Type = Access-Request
>> Thu Jun 15 13:55:14 2006
>>         User-Name = "ppp1 at example.com"
>>         User-Password = "b"
>>         NAS-Port-Type = xDSL
>>         MS-CHAP-Challenge = 0x00
>>         NAS-IP-Address = 127.0.0.1
>>         Stripped-User-Name = "ppp1"
>>         Realm = "example.com"
>
> Since you _want_ the \000 to be sent, I don't see why it "seems to work here"? 
> Maybe the only thing that would really give clarity about what is really 
> happening is a pcap capture with ethereal or similar.

Notice the MS-CHAP-Challenge.  That's why I said "as long as the
attribute is of type "octets"".  

Calling-Station-Id is truncated at the first NUL. 

MS-CHAP-Challenge is transmitted, even if it contains just a single
NUL octet



Bjørn