> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> Alan DeKok
> Sent: Monday, July 14, 2003 1:56 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Handling of the 'Class' attribute
>
>
> $ 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"
>
>
In your case, you send the string '0x41424344' and the server receives it
as '0x41424344'. That is expected and I am not disputing it.
The problem is, like I said in my previous mail, I have the following
setting in Raidus's
MySQL backend radreply table, which contains stuff the server sends back to
the client
when authentication succeeds.
+----+----------+--------------+----+---------------+
| id | UserName | Attribute | op | Value |
+----+----------+--------------+----+---------------+
| 1 | Alex | Service-Type | := | Login |
| 2 | Alex | Class | := | ABCD | <---the text is ABCD,
the hex values are 0x41, 0x42, 0x43, and 0x44
+----+----------+--------------+----+---------------+
When I tried to authenticate these users, through 'radclient',
I got the following reply
Received response ID 35, code 2, length = 36
Service-Type = Login
Class = 0x41424344 <------- This is a hex representation of 'ABCD'
The scenario becomes:
1. Data stored is 'ABCD' on the server.
2. Data sent to the client is 'shown' as '0x41424344' on screen. I assume
the server
is doing the right thing of sending only 'ABCD' to the client,
but 'radclient' probably converts 'ABCD' to show as '0x41424344' on the
screen.
For human consumption, it is OK because we know this string is a hex
string
and would map it back to 'ABCD' in the ASCII table. But what if the
program
just resend this '0x41424344' back to the server, in either an access
request
or an account request? The server will see only '0x41424344', it does
not remap
it back to 'ABCD'.
3. Unless I do the translation again somewhere, the round-trip of 'ABCD'
does not
come back intact but instead becomes '0x41424344'. When a human eyes
read this,
they mean the same ASCII code. But unless the program does something
extra,
strcmp of 'ABCD' and '0x41424344' will not be the same.
When you do SQL query from the DB, it will not give '0x41424344' for the
value of 'ABCD', will it?
Now this behavior is clear to me, I can do the translation myself in either
the
client side when it receives that string, or on the server side when
processing
this in the DB when it parses that string.
> 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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
