So far I have not seen much mentioning of the 'Class'
attribute, and according to the RFC, it should be
treated as an opaque object by the client.  My understanding
is that when a client is granted access, the server may optionally
include a 'Class' attribute in its accept reply.
The client can resend this AV pair, without interpretation, to the Radius
accounting. The value of the 'Class' attribute is 'string'.
But I found that the radius server seem to have modified this attribute:

Here is what is stored in radreply:
mysql> select * from radreply;
+----+----------+--------------+----+---------------+
| id | UserName | Attribute    | op | Value         |
+----+----------+--------------+----+---------------+
|  1 | Alex     | Service-Type | := | Login         |
|  2 | Alex     | Class        | := | ABCDabcd      | <----- Notice the
string
|  3 | Mark     | Service-Type | := | Login         |
|  4 | Mark     | Class        | := | 12345678      |
|  5 | Crypt    | Service-Type | := | Login         |
|  6 | Crypt    | Class        | := | abcd1234      |
+----+----------+--------------+----+---------------+

When I tried to authenticate these users, through 'radclient',
I got the following replies for the three users, respectively:

Received response ID 35, code 2, length = 36
        Service-Type = Login
        Class = 0x4142434461626364

Received response ID 38, code 2, length = 36
        Service-Type = Login
        Class = 0x3132333435363738

Received response ID 41, code 2, length = 36
        Service-Type = Login
        Class = 0x6162636431323334

I do not have the ASCII table at hand, but it seem that the string
'ABCDabcd' has been turned into a string of HEX numbers, 0x41, 0x42, 0x43,
0x44, etc.
Is this translation done in the radius server side or done at the radclient
side?
What is the reason for the translation?


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to