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.