First to answer your question: The 'string' field can contain anything from 0 to 255 of binary values, that is 8-bit ASCII code. If a data of value 1 is stored in the DB it is just 1. When we print it out and add the HEX prefix to signify that it is a 1 in HEX format, we show it as '0x1'. But you can not say this '0x1' string is the same as the value '1' when you compare them within a program because they are not the same, literally, any more.
If the client is to treat the 'octets' (bytes) is an opaque object and resend it to the server for accounting purpose, you would expect the data not be modified at all anywhere. The fact is that a string 'ABCD' is stored in the DB at the server side as '0x41, '0x42', '0x43', '0x44', in HEX format. This corresponds to the ASCII symbols of 'A', 'B', 'C', and 'D'. It is a string of 4-octets. So what should be received by the client if it is sent by the server back to it? Exactly 4 octets, right? But if the server is sending '0x41424344', then it is a string of '0', 'x', '4', '1', '4', 2', '4', '3', '4' and '4'. The values have been altered from binary form to human readable form. That's the reason why I ask if this is done by the 'radclient' to translate a string of 4 octets, with HEX value of '0x41', '0x42', '0x43' and '0x44', it receives from the server to the string '0x41424344' on stdout. Because I am using the 'radclient' as the media to talk to the server, I am not writing a radius client using the radius protocol so I cannot access the actual data at protocol level. If I parse the reply shown on the stdout by the 'radclient' and resend it unmodified back to the server, what do I get now? A series of 4 octets has been turned into a series of 10 octets. This means that whatever is digesting the 'Class' value on the accounting part of the server has to walk through the octet string to 1. subtract the '0x' header. 2. take every two octets and combine they into a string. 3. look up the corresponding HEX value of this string. 4. Reconstruct the original data. I can do the translation on the client side if I know the data needs to be reconstructed, I am only questioning if 'radclient' is doing this so a non-printable character in the 'Class' attribute can be represented when it prints to stdout. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Paul > Hampson > Sent: Saturday, July 12, 2003 12:49 AM > To: [EMAIL PROTECTED] > Subject: RE: Handling of the 'Class' attribute > > > > 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
