"Alex Chen" <[EMAIL PROTECTED]> wrote:
> First to answer your question: The 'string' field can contain anything
> from 0 to 255 of binary values, that is 8-bit ASCII code. If a data of
> value 1 is stored in the DB it is just 1. When we print it out and add the
> HEX prefix to signify that it is a 1 in HEX format, we show it as
> '0x1'. But you can not say this '0x1' string is the same as the value '1'
> when you compare them within a program because they are not the same,
> literally,
> any more.
You are mistaking strings displayed in ASCII on your screen for data
which goes across the wire.
For the purposes of FreeRADIUS & the Class attribute, the following
values are identical:
"a"
0x61
They are *printed* differently, but they are the same in the RADIUS
packet.
> to the server for accounting purpose, you would expect the data not be
> modified at all anywhere. The fact is that a string 'ABCD' is stored in the
> DB at the server side as '0x41, '0x42', '0x43', '0x44', in HEX format.
> This corresponds to the ASCII symbols of 'A', 'B', 'C', and 'D'.
> It is a string of 4-octets. So what should be received by the client
> if it is sent by the server back to it? Exactly 4 octets, right?
Yes.
> But if the server is sending '0x41424344', then it is a string of
> '0', 'x', '4', '1', '4', 2', '4', '3', '4' and '4'. The values have been
> altered from binary form to human readable form.
Nonsense. Do you really think that the string "0x41424344" is sent
as-is in the RADIUS packet?
Did you bother to run 'tcpdump', to check?
> Because I am using the 'radclient' as the media to talk to the
> server, I am not writing a radius client using the radius protocol
> so I cannot access the actual data at protocol level.
tcpdump ? It isn't that difficult to find or install.
And you shouldn't *care* about the RADIUS protocol. The client Does
The Right Thing.
> If I parse the reply shown on the stdout by the 'radclient' and
> resend it unmodified back to the server, what do I get now? A series
> of 4 octets has been turned into a series of 10 octets.
That shouldn't happen, and it doesn't:
$ more test
User-Name = "bob", User-Password = "bob", Calling-Station-ID = "foo",
Class = 0x41424344
$ ./radclient -xd ../../share/ -f test localhost auth testing123
Sending Access-Request of id 193 to 127.0.0.1:1812
User-Name = "bob"
User-Password = "bob"
Calling-Station-Id = "foo"
Class = 0x41424344
rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=193, length=32
Reply-Message = "Hello, bob"
And the server says:
rad_recv: Access-Request packet from host 127.0.0.1:1029, id=193, length=54
User-Name = "bob"
User-Password = "bob"
Calling-Station-Id = "foo"
Class = 0x41424344
See?
If you see anything else, then you've probably gone out of your way
to EDIT the string for the Class attribute.
e.g. the server prints:
Class = 0x41424344
and you give it to radclient as:
Class = "0x41424344"
Do you see the difference? Do you think the difference is
meaningful?
> This means that whatever is digesting the 'Class' value on the
> accounting part of the server has to walk through the octet string
> to
...
Treat it as a string of octets.
So?
I completely fail to understand what the problem is. If you hate
the 'octets' data so much, change the dictionary type to 'string'.
Geez, that's why the dictionaries are in ASCII, and editable.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
