> -----Original Message-----
> From: Alex Chen
> Sent: Tuesday, 15 July 2003 8:46 AM
> > From: Alan DeKok
> > Sent: Monday, July 14, 2003 1:56 PM
> > $ 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.
No, that's wrong. The server converts ABCD into the opaqe octet sequence
(hex) 41424344. Radclient print this in the generally accepted format 0x41424344,
and if given a value in that format as input, will internally have the same
thing that was sent to it, (hex) 41424344, which will match on the server, but
not "as is" on mySQL, unless mySQL is making the reverse assumption of FreeRADIUS'
assumption... IE FreeRADIUS is assuming a string is mapped by the ascii table
into an octet stream, mySQL would have to assume that storing a number into a
string table should be done by mapping back through the ascii table, rather than
storing the text presentation format of that number, which is what I expect it
to do.
ABCD is not a value, it's a possible meaning for the series of values 0x41, 0x42,
0x43 and 0x44. So FreeRADIUS can't send "ABCD", it can only send "0x41424344".
Since it's defined as an opaque octect sequence in the RFC, radclient doesn't
try and re-interpret it back into a string, which is the "right thing" since
it's supposed to be opaque.
You _might_ be able to change your dictionary entry for the Class attribute to
make it a string, but you'd have to change it at both ends, so both ends know
to treat the octet stream as a string, which is what you seem to want. Of course,
if you're interacting with the outside (RADIUS) world, then changing RFC attributes
is a brave brave thing to do, with complications you probably don't actually want.
> 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'.
That's right. Since as far as the server's concerned, it _is_ 0x41424344.
It's only because your DB is interpreting (and in fact storing it) as a string
that you see it as ABCD. Radius only ever sees it as 0x41424344, once it's
gotten it from the DB and converted it into an opaque octet stream.
> 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?
That's because you've told your SQL server to treat it as a string. You have
to either use a mySQL function to convert the data back into a string,
(since the knowledge that you're using the Class attribute's value as a string
is local to the database, and opaque to Radius) or instead store it as a
number, instead of a string.
> 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.
There isn't any translation needed on the client side. Doing translation on
the client side will probably confuse things... Although admittedly, if you
feed Class="ABCD" into radclient, it will (I'm guessing) successfully convert
that into the opaque representation 0x41424344 the same was FreeRADIUS server
does it. You shouldn't rely on that though, that's why it's called an opaque
value.
--
=========================================================
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
