On Tue, Jan 19, 2016 at 08:51:40PM +0000, Matthew Newton wrote:
On Tue, Jan 19, 2016 at 03:43:21PM -0500, Alan DeKok wrote:
On Jan 19, 2016, at 3:39 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
I'm probably fairly unusual in having an eap instantiation (two even) that's not called "eap".
I've done some more spelunking, and calling the "eap" module is only done when it's proxying the inner-tunnel EAP data. I've pushed fixes which convert the error into a WARNING, which won't break existing configurations.
OK thanks - I'll push that out right now to test it.
That looks better, thanks: # Linked to sub-module rlm_eap_peap peap { tls = "tls-common-outer" default_eap_type = "tls" copy_request_to_tunnel = yes use_tunneled_reply = no proxy_tunneled_request_as_eap = yes virtual_server = "inner-tunnel" soh = yes require_client_cert = no soh_virtual_server = "soh-server" } tls: Using cached TLS configuration from previous invocation Failed to find 'Auth-Type eap' section in virtual server inner-tunnel. The server cannot proxy inner-tunnel EAP packets. # Instantiating module "inner-eap" from file /srv/radius/mods-enabled/eap # Linked to sub-module rlm_eap_tls then starts up fine, and is now authenticating live sessions... Rather than hard-coding "eap", does it make sense to do the attached patch? (Haven't tested it here.) Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>