Stefan Winter <stefan.winter@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@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