I'm seeing some inconsistent handling of encoding/escaping of attributes in rlm_perl between calls to the module (i.e. when setting an attribute in one call and then reading it back in the next). I was expecting "something out, something in", but instead I'm getting "something out, something-modified in". In authorize, my script does an LDAP lookup and then sets the $RAD_CHECK{'Ldap-UserDn'} attribute for later: rlm_perl: Added pair Ldap-UserDn = CN=Ireland\, Scott,OU=[...] In authenticate, I go to read this back but find that the \ in the attribute is coming back to me escaped: rlm_perl: Added pair Ldap-UserDn = CN=Ireland\\, Scott,OU=[...] So, I end up having to strip off the escaping backslashes before using the value. I'm seeing something similar with the State attribute going out in an Access-Challenge and coming back in on the next Access-Request. In authorize, I set $RAD_REPLY{'State'} to the single byte value 0x01 that I send back in an Access-Challenge rlm_perl: Added pair State = ? Sending Access-Challenge of id 253 to [ip] port 63308 State = 0x01 When authorize next sees the follow-up request from the NAS, things look OK in the RADIUS packet: rad_recv: Access-Request packet from host [ip] port 14034, id=254, length=146 State = 0x01 rlm_perl: Added pair State = 0x01 But when I read it in Perl, $RAD_REQUEST{'State'} comes back as the string "0x01", so I have to turn around and pack() this to get back what I put in. The same thing happens for different values as well; for instance, if I were to use the literal 1 as a value, State goes out as 0x31 (the string "1") and comes back in as the string "0x31", which again needs a pack() to fix. I've been able to work around this by doing a bit of extra processing when I read any of these attributes back, but it doesn't really seem like intended behaviour.