Hi Alan, On Sat, Sep 23, 2017 at 4:47 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 22, 2017, at 9:05 PM, Isaac Boukris <iboukris@gmail.com> wrote:
I've been trying to test eap-fast unauthenticated provisioning (RFC 5422), and was getting mschap errors, for which I think I found a fix - see attached patch (v3.0x).
With this patch, the mschap authentication stage succeeds using eapol_test and a tunnel-pac is provisioned (while the first eapol exchange ends with reject as allowed by the RFC, the subsequent authentication successes using the newly provisioned pac).
That looks good, thanks.
Thanks!
I also tried out the v4.0x branch but encountered some other issues. First had to add a cast to float when comparing with tls_max_version (inst->tls_conf->tls_max_version > (float) 1.1), as otherwise: float x = 1.1; if (x > 1.1) yields true for some reason.
Floats are notorious for that kind of thing...
To me this seem insane. See attached patch with some more casting, including the actual one, preventing tlsv1.1 with eap-fast, in rlm_eap_fast.c file.
Then however, I get a crash which I can't figure so far - logs with back-trace attached.
That's a straightforward infinite recursion. I've pushed a fix.
That stopped the crash. However eap-fast still fails for no obvious reason and sometimes the server exits on assertion fail - see attached log. Regards.