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 <STDOUT> 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
