> -----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 check what was stored in it. What I saw was that the stuff I inserted with the perl script matched the output from mysql command. > > 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. > > 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'? > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
