On Jan 19, 2016, at 12:54 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
Heads-up in case my note on github doesn't get seen before 3.0.11 arrives...
Just compiled up latest 3.0.x HEAD and now get
/srv/radius/mods-enabled/eap[51]: Failed to find 'Auth-Type eap' section. Cannot authenticate users. rlm_eap (outer-eap): Failed to initialise rlm_eap_peap
Yup. I added some more sanity checking, and it seems to have broken some configurations. The question is, should we relax those sanity checks, or are the configurations really broken?
EAP modules here are called "outer-eap" and "inner-eap" (for my sanity - we've got PEAP/EAP-TLS, so it's "double-stacked" :-) )
What does the inner-tunnel "authenticate" section? i.e. does it have: authenticate { ... inner-eep ... } or does it have: authenticate { ... Auth-Type EAP { inner-eep } ... }
Adding in the new "inner_eap_module" option to the outer PEAP section fixes it (inner_eap_module = "outer-eap") but I'm not sure why it needs to break in 3.0.x?
It doesn't need to break, of course. But sanity checks are good. The problem was that the PEAP module was *hard-coded* to use "Auth-Type EAP". Which worked fine for situation (2) above, but not so much for situation (1). Hmm... If I configure the inner-tunnel virtual server as (1), I get: /raddb/mods-enabled/inner-eap[15]: Failed to find 'Auth-Type inner-eap' section. Cannot authenticate users. ./raddb/mods-enabled/inner-eap[15]: Instantiation failed for module "inner-eap" That's wrong. Let me go fix that, at least. Alan DeKok.