RE: Handling of the 'Class' attribute
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Alan DeKok > Sent: Wednesday, July 16, 2003 7:31 AM > To: [EMAIL PROTECTED] > Subject: Re: Handling of the 'Class' attribute > > > "Alex Chen" <[EMAIL PROTECTED]> wrote: > > 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). > > Then the client APP is wrong. > > Is it a FreeRADIUS-based app? If so, then it should work, and you > need to say *exactly* how you're using the Class attribute, including > REAL examples. > > If it's not based on the FreeRADIUS code, then why are you > complaining to the FreeRADIUS list that your client app is broken? > There's nothing we can do to fix it. > I am not asking for any fix in the radius server or client. I am just pointing out my observation and see what I can do to get the result I need. > Write a dumb "perl" script which converts the hex "0x41..." to a > string, and pass that string back to the broken client app. > That is what I want to hear. I indicated in my previous mail saying exactly that. I said 'something' has to do the conversion from this '0x41' hex string spit out by 'radclient' back to the original octets so they can be send back to the server. Maybe I did not read it right, but the impression I got from the mail exchange was that I should not do anything at all and just pass the string printed out by 'radclient' right back to the server. > > The server works. The code is correct. It Does The Right Thing. > I do not dispute that at all. It is the interpretation of the output printed out by 'radclient' that caused my confusion. Anyway, I think we had enough discussion on this and should let it rest. Case closed. > Alan DeKok. > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Handling of the 'Class' attribute
> 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 0xnnn. 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
Re: Handling of the 'Class' attribute
"Alex Chen" <[EMAIL PROTECTED]> wrote: > 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). Then the client APP is wrong. Is it a FreeRADIUS-based app? If so, then it should work, and you need to say *exactly* how you're using the Class attribute, including REAL examples. If it's not based on the FreeRADIUS code, then why are you complaining to the FreeRADIUS list that your client app is broken? There's nothing we can do to fix it. Write a dumb "perl" script which converts the hex "0x41..." to a string, and pass that string back to the broken client app. The server works. The code is correct. It Does The Right Thing. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Handling of the 'Class' attribute
Alan, don't get so excited. I am just point out my observation. I am not saying that it is a bug in either the radiusd or radclient. Let's forget about 'ABCD'. Maybe I started with the wrong foot. If I stated the question differently, perhaps you can point me to the right direction. I want to use the 'Class' attribute for user grouping and some other accounting purpose. So I set this attribute in the radreply table of MySQL for each user. When a user logs in, the server sends this attribute to the client (radclient). The real client app. gets this from of radclient. Upon the receipt of successful authentication, i.e. check the 'code' field of the reply, the client app. sends an 'start accounting' request back to the server, along with the value of the 'Class' attribute printed out by 'radclient'. On the server side, the SQL statement in sql.conf for 'accounting_start_query' includes extra field to access the %(Class) attribute and insert the value into the 'radacct' table. Later on I can use other scripts to massage the DB data. 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). The questions is how I handle this? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Handling of the 'Class' attribute
"Alex Chen" <[EMAIL PROTECTED]> wrote: > I think we are getting into the debate of how 'octet' values should > be handled. No. We are trying to explain it to you, and you are disagreeing with us. > But the fact remains that if something is store in the DB > with the hex values of 41, 42, 43, 44, they will be displayed on > the client side as '0x41424344'. That's fine. > And when this string is resent back, the hex values of the string > "0x41424344" will not be interpreted as 41, 42 ,43, 44. Instead they > become the hex values of ASCII code '0', 'x', '4', '1', '4',' 2', > '4', '3', '4', and '4'. Again, you have not explained WHY this is happening. Just what the heck are you doing to that data, in order to make the server NOT interpret it as a series of octets? > If the 'radclient' does not interpret the octet-string, but just > print out the octets one by one, i.e. hex values '41', '42', '43' > and '44', what will we get? The ASCII codes of 'A' 'B', 'C' and 'D', right? Absolutely not. We've tried explaining this. You refuse to listen. > Similarly if other non-printable octets are printed literally, we will > probably get junk output (to the human eyes, but not to the machine.) Which is why they're printed as octets. Do you really want non-humanly-readable binary data printed out by the server? Why the heck would ANYONE think that makes sense? > It is because the radclient maps the octet values to HEX numbers do we > get the "0x41424344" string output from the four octets. Again, you're intentionally missing the point. radclient doesn't "map" the octets. It prints them out in a form for you to understand, in the same way it prints "User-Name" instead of a binary '01'. Is this so hard for you to understand? > I use the schema defined by FreeRaius and the data type of the 'Value' > field is 'varchar'. That is the only data type that maps better to > the 'octet' type. That's fine. > What am I supposed to do when I get the string "0x41424344" from > radlicent when it prints out such thing? Don't I need to remap this > into the hex values '41', '42', '43', '44'? No. That's the whole point. You don't f*ck with it. Can you PLEASE explain to me what the REAL problem is? You're so stuck on the "octets versus string" crap that I can't for the life of me figure out if there's anything in the server which needs fixing. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Handling of the 'Class' attribute
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Paul > Hampson > Sent: Monday, July 14, 2003 6:11 PM > To: [EMAIL PROTECTED] > Subject: RE: Handling of the 'Class' attribute > > > > 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 'ABCD' is the ASCII code mapping of the hex values 41424344. Even if the server is sending the hex values 41 42 43 44, they are still 'ABCD' when mapped to the ASCII code. What matters is the server is sending a 4-byte value to the client. I assume there is no conversion from the DB to server, i.e. when the server does the SQL query programmatically, it is getting a 4-octet string of the hex values 41, 42, 43, 44. Only that will resulting in the server sending the correct hex values. The 'ABCD' shown by mysql command line is only for human eye consumption. because the field type is declared 'varchar'. > 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". I think we are getting into the debate of how 'octet' values should be handled. But the fact remains that if something is store in the DB with the hex values of 41, 42, 43, 44, they will be displayed on the client side as '0x41424344'. And when this string is resent back, the hex values of the string "0x41424344" will not be interpreted as 41, 42 ,43, 44. Instead they become the hex values of ASCII code '0', 'x', '4', '1', '4',' 2', '4', '3', '4', and '4'. > Since it's defined as an opaque octet 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. > If the 'radclient' does not interpret the octet-string, but just print out the octets one by one, i.e. hex values '41', '42', '43' and '44', what will we get? The ASCII codes of 'A' 'B', 'C' and 'D', right? Similarly if other non-printable octets are printed literally, we will probably get junk output (to the human eyes, but not to the machine.) It is because the radclient maps the octet values to HEX numbers do we get the "0x41424344" string output from the four octets. > > 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. > I use the schema defined by FreeRaius and the data type of the 'Value' field is 'varchar'. That is the only data type that maps better to the 'octet' type. > > 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, I did not tell the SQL to do any special treatment. I just modified the user2mysql.pl in the scripts directory to insert the extra Class attribute in radreply table and used 'mysql' command line interface to
RE: Handling of the 'Class' attribute
> -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
RE: Handling of the 'Class' attribute
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Alan DeKok > Sent: Monday, July 14, 2003 1:56 PM > To: [EMAIL PROTECTED] > Subject: Re: Handling of the 'Class' attribute > > > $ 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. 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'. 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? 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. > And the server says: > > rad_recv: Access-Request packet from host 127.0.0.1:1029, > id=193, length=54 > User-Name = "bob" > User-Password = "bob" > Calling-Station-Id = "foo" > Class = 0x41424344 > > > See? > > If you see anything else, then you've probably gone out of your way > to EDIT the string for the Class attribute. > > e.g. the server prints: > > Class = 0x41424344 > > and you give it to radclient as: > > > Class = "0x41424344" > > Do you see the difference? Do you think the difference is > meaningful? > > > This means that whatever is digesting the 'Class' value on the > > accounting part of the server has to walk through the octet string > > to > ... > > Treat it as a string of octets. > > So? > > I completely fail to understand what the problem is. If you hate > the 'octets' data so much, change the dictionary type to 'string'. > Geez, that's why the dictionaries are in ASCII, and editable. > > Alan DeKok. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Handling of the 'Class' attribute
"Alex Chen" <[EMAIL PROTECTED]> wrote: > 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. You are mistaking strings displayed in ASCII on your screen for data which goes across the wire. For the purposes of FreeRADIUS & the Class attribute, the following values are identical: "a" 0x61 They are *printed* differently, but they are the same in the RADIUS packet. > 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? Yes. > 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. Nonsense. Do you really think that the string "0x41424344" is sent as-is in the RADIUS packet? Did you bother to run 'tcpdump', to check? > 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. tcpdump ? It isn't that difficult to find or install. And you shouldn't *care* about the RADIUS protocol. The client Does The Right Thing. > 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. That shouldn't happen, and it doesn't: $ 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" And the server says: rad_recv: Access-Request packet from host 127.0.0.1:1029, id=193, length=54 User-Name = "bob" User-Password = "bob" Calling-Station-Id = "foo" Class = 0x41424344 See? If you see anything else, then you've probably gone out of your way to EDIT the string for the Class attribute. e.g. the server prints: Class = 0x41424344 and you give it to radclient as: Class = "0x41424344" Do you see the difference? Do you think the difference is meaningful? > This means that whatever is digesting the 'Class' value on the > accounting part of the server has to walk through the octet string > to ... Treat it as a string of octets. So? I completely fail to understand what the problem is. If you hate the 'octets' data so much, change the dictionary type to 'string'. Geez, that's why the dictionaries are in ASCII, and editable. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Handling of the 'Class' attribute
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 | Us
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
