rlm_perl - Asymmetric attribute encoding

[Scott Ireland]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/mailman/private/freeradius-users/attachments/20140331/a53fe8c6/attachment.html>