> From: Alex Chen
> Sent: Wednesday, 16 July 2003 10:26 AM
> Because the client app. takes the output from 'radclient' directly,
> the 'Class' value always starts with '0x' prefix and following by the hex
> numbers representation of the octets. When it sends it back to the
> server, it is no the same raw data as the one stored in DB (in its binary form).
What it gets back is exactly the raw data stored in binary form, or at
least the raw data given in binary form to FreeRADIUS by your database.
The problem is that you've not got anything to tell your database to
present the raw data it got back as ASCII data. The default thing to
do with raw data into a string column in mySQL is to present the data
as an ASCII string representing the raw data. eg if you give 0x41424344
to mySQL to put into a string column, it will treat it as "0x41424344"
which as far as FreeRADIUS is concerned is a different value entirely.
In short, if FreeRADIUS immediately inserted what it got from mySQL,
mySQL would not contain the same value it got. And as far as I can
think at this late hour, that's correct behaviour. The exceptional case
is when the string starts with 0x, in which case FreeRADIUS interprets
it not as a series of bytes, but a string representation of those
bytes. And so when it gives it back to mySQL, mySQL ends up with the
same thing it started with.
I'd suggest that the DB schema should use a different type for Class,
except that a string is the most sensible given the variable length of
the value stored...
> The questions is how I handle this?
Store the octets in your DB in the form 0xnnnnnnnnnnn. That way the
presentation forms you get back match those you sent.
OR
Massage your INSERT/UPDATE queries (Using a stored procedure, I expect)
to transform the raw data it receives from FreeRADIUS into the characters
whose ASCII values they hold. I don't guarantee this is possible though.
:-)
The only way the attribute will actually be changed is if you put "'s
around it, as Alan pointed out earlier, when you put the data back
into radclient from your local client code.
If you want to verify or disprove the idea that the data is being
mangled, get tcpdump, an RFC, and look at the packets going back and
forth. If you're still stuck, try capturing both directions of a
single conversation with radclient (using tee?), and post 'em to
the list, just in case you've found a bug. (Although having just
read the relevant code, I doubt it.)
Given the simplicity of radclient.c, wouldn't it be easier to make your
software talk Radius through libradius than trying to talk 'text' with
radclient? (Only a thought...)
--
=========================================================
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
