peap/eap change in 3.0.x with inner_eap_module now required

[Alan DeKok]

On Jan 19, 2016, at 12:54 PM, Matthew Newton <mcn4 at 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.