Ah, it occurred to me I might know where your confusion is coming from. In an earlier email you referenced the iconv encoding library and asked shouldn't FreeRADIUS be encoding/decoding text. The answer is no. The reason why is because radius implementations treat text as an octet string (e.g. a sequence of bytes). Those octets are supposed to be a UTF-8 encoding and are supplied to FreeRADIUS by external entities. It's those external entities which are responsible for assuring the octet string they supply is a proper UTF-8 encoding. That includes backends which look-up text during processing, network clients supplying values and any text editor used to read/write config files.
*-> I understood that ones who wants to use text other than ASCII than that is up him to convert into UTF-8 first and send it to RADIUS server.* *-> But then How can free RADIUS server can performed the job of varrifying credentials in above UTF-8 case, because it is not going to understand UTF-8? * ** > I can think of only one area which might be problematic. The regular > expression engine used to match and extract strings fundamentally wants to > operate on characters not encoded octets. But that is not an RFC compliance > issue. -> *Can you please focus some more on this point?, I am not at all understood your point sir.* Regards, karnik jain
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html