> From: Alex Chen
> Sent: Saturday, 12 July 2003 9:36 AM

Short answer: That's working like it's supposed to. See if
it works for what you want it to do, and then ask _that_
question.

> 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'.

You might want to re-read the relevant part of RFC 2865:
(This is going to look awful if your mail read uses a non-monospaced font)
===
   A summary of the Class Attribute format is shown below.  The fields
   are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |    Length     |  String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
===
===
   String

      The String field is one or more octets.  The actual format of the
      information is site or application specific, and a robust
      implementation SHOULD support the field as undistinguished octets.

      The codification of the range of allowed usage of this field is
      outside the scope of this specification.
===

It's a field _called_ String, not a field containing a 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.

Happily, those _are_ the ASCII values of your text. And that looks like
I would expect an opaque value to be. (ie. a single value, not assumed
to be a string. :-)

(0x30 + n = n'th number, 0x40 + n = n'th lower-case letter,
0x60+n = n'th upper-case letter)

> Is this translation done in the radius server side or done at the radclient
> side?

I expect the radius server does it, since (according to the dictionary file
and as recommended by the RFC) Class is of type "octets".

> What is the reason for the translation?

To make it an opaue value as specified, not a string, which (as you noticed)
is only opaque if you have an ASCII chart handy, and so does everyone else
in between.

I guess the interesting question really is "Does it work like you want it
to even though it is being sent and received as octets but stored in your
radius DB as a string?". I suspect that's a yes, but you'd have to try it
and find out... Comparisons should work, but I suspect that it'll be stored
as a number of arbitrary bound in your accounting records, assuming you're
storing the Class in the accounting records.

Then again, I guess you won't know until you try.

--
=========================================================
Paul "TBBle" Hampson
Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

This is a one line proof...if we start
sufficiently far to the left.
        -- Cambridge University Math Department
---------------------------------------------------------
Random signature generator 3.0 by Paul "TBBle" Hampson
=========================================================


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

Reply via email to