On 22 Jul 2013, at 10:45, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 22 Jul 2013, at 10:43, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
expand: %{control:RESTENA-SSHA1-Password} -> oPQYKSRg5w8XWEiJCcNtzKRhUhtJMUQ/WjdCWlVQS2JWN2Qz expand: 0x%{base64tohex: %{control:RESTENA-SSHA1-Password}} -> 0xffff18292460ff0f175848ff09ff6dffff61521b4931443f5a37425a55504b6256376433
when I take this base64 and use an online base64-decode service such as http://base64decode.net/ and use its output with an online hex-encoder such as http://convertstring.com/EncodeDecode/HexEncode I end up with the string
203F182924603F0F1758483F093F6D3F3F61521B4931443F5A37425A55504B6256376433
The bit-diff to what the FreeRADIUS fucntion produces is like:
203F182924603F0F1758483F093F6D3F3F61521B4931443F5A37425A55504B6256376433 ffff18292460ff0f175848ff09ff6dffff61521b4931443f5a37425a55504b6256376433 ***---------*---------*---*---*-*---------------------------------------
(I was wondering from the start why there are many more FF's in the FreeRADIUS version than what probability would suggest)
Yes that was the first thing I did. I suspected the base64 decoder (it's new), but, I just tested with rlm_pap in version 3.0 which uses that decoder and it works fine. The code is pretty simple... I'll keep digging.
sprintf "%02x" was giving the wrong result. I'm not sure why. I've switched to our own internal hex encoder which is probably faster anyway, and it gives the correct hex encoding. Using your hash and example password, authentication now succeeds. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team