Scott Ireland wrote:
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=[...]
That string is a Perl string. It's allowed to have backslashes in it, and they mean nothing special. The server treats backslashes as something special.
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=[...]
Yes. The backslash is escaped.
So, I end up having to strip off the escaping backslashes before using the value.
Why are you escaping the comma? That doesn't make much sense. Commas are allowed in strings in FreeRADIUS, and have no special meaning. The solution would be to *not* escape the comma in the first place.
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 = ?
Because the State attribute is binary data. The debug message is trying to print that binary data, and not doing a good job of it.
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",
That could be fixed. But you could then argue that IP addresses should be passed to Perl as a 4 byte binary blob. Well, the interface to the Perl code is text. Always text. If that's difficult for Perl, that's just the way it is right now.
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.
Sad to say, yes.
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.
It's awkward, but it's consistent. Everything is a string. For v3, it may be worth adding mapping functions like we now have in LDAP and other places. So you should be able to say "Yes, my Perl script expects State as a binary blob. That's fine". As always, patches are welcome. Alan DeKok.