On Fri, Sep 6, 2013 at 3:57 PM, Stefan Winter <stefan.winter@restena.lu> wrote:
So I ask: is there any way to backport the fix to 2.2.x branch? I don't know C very well but if it's not so hard, I might try talking to people who knows how to code and create a unnoficial patch. I saw that the base64 is now using a brave new approach on 3.0.
You should read the (entire!) thread on -devel titled
"2.x.x (and earier?): yet another decoding SSHA issue"
during which at some point the 2.x.x branch code got fixes for the bulk of the issue. This will be in 2.2.1; but you can safely grab current branch, it's running stable on my production systems for a long time now.
That's nice to hear! Thanks! I just tested the 2.x.x branch and it's working for me.
The fix still needs config changes with a bit of a hackish workaround - read the thread til the end to get all the goodness.
I tested some of the hashes that were giving me trouble and they all worked with the current branch version. I also read all the thread, and some things were not so clear for me (sorry for the "noobiness"). Could you explain your final configuration state? I saw the unlang: update reply { SSHA1-Password := "0x%{base64tohex: %{control:RESTENA-SSHA1-Password1}}" } And the SQL syntax: SELECT id, username, 'RESTENA-SSHA1-Password', value, op FROM check_smtp_ssha1 WHERE username='%{SQL-User-Name} Is these configurations obligatory? I'm using the standard radcheck table (id,username,attribute,op,value) and query that comes with freeradius. From what I understood, I need to create a VSA, assign my SSHA1-Password attribute to it and convert it to hex format using the unlang and xlat? Without these extra configuration, the messages from authorization are now: [pap] login attempt with password "senhasecreta" [pap] Using SSHA encryption. [pap] User authenticated successfully ++[pap] = ok So the "Normalizing error" and segmentation fault isn't happening anymore. Thanks! []'s Hugo www.devin.com.br