Option proxy_tunneled_request_as_eap=no increases debug level for subpackages #839

Closed
qnet-herwin opened this Issue Nov 21, 2014 · 3 comments

Projects

None yet

2 participants

@qnet-herwin
Contributor

When using a PEAP module, proxying the innner request to another server (proxy-inner-tunnel) and disabling the option proxy_tunneled_request_as_eap results in a very high debug level for a few internal packets. Logfiles appear like this:

Fri Nov 21 14:35:04 2014 : Info: Signalled to terminate
Fri Nov 21 14:35:04 2014 : Info: Exiting normally
Fri Nov 21 14:35:04 2014 : Info: Debugger not attached
Fri Nov 21 14:35:04 2014 : Info: Loaded virtual server <default>
Fri Nov 21 14:35:04 2014 : Warning: Ignoring "sql" (see raddb/mods-available/README.rst)
Fri Nov 21 14:35:04 2014 : Warning: Ignoring "ldap" (see raddb/mods-available/README.rst)
Fri Nov 21 14:35:04 2014 : Info: Loaded virtual server inner-tunnel
Fri Nov 21 14:35:04 2014 : Info: Loaded virtual server default
Fri Nov 21 14:35:04 2014 : Info: Loaded virtual server proxy-inner-tunnel
Fri Nov 21 14:35:04 2014 : Info: Ready to process requests
Fri Nov 21 14:35:06 2014 : Debug: (7) # Executing group from file /opt/freeradius/etc/raddb/sites-enabled/proxy-inner-tunnel
Fri Nov 21 14:35:06 2014 : Debug: (7)   authenticate {
Fri Nov 21 14:35:06 2014 : Debug: (7)     modsingle[authenticate]: calling eap (rlm_eap) for request 7
Fri Nov 21 14:35:06 2014 : Debug: (7) eap: Peer sent method Identity (1)
Fri Nov 21 14:35:06 2014 : Debug: (7) eap: Calling eap_mschapv2 to process EAP data
Fri Nov 21 14:35:06 2014 : Debug: (7) eap_mschapv2: Issuing Challenge
Fri Nov 21 14:35:06 2014 : Debug: (8) # Executing group from file /opt/freeradius/etc/raddb/sites-enabled/proxy-inner-tunnel
Fri Nov 21 14:35:06 2014 : Debug: (8)   authenticate {
Fri Nov 21 14:35:06 2014 : Debug: (8)     modsingle[authenticate]: calling eap (rlm_eap) for request 8
Fri Nov 21 14:35:06 2014 : Debug: (8) eap: Expiring EAP session with state 0xf9309b6df93881ac
Fri Nov 21 14:35:06 2014 : Debug: (8) eap: Finished EAP session with state 0xf9309b6df93881ac
Fri Nov 21 14:35:06 2014 : Debug: (8) eap: Previous EAP request found for state 0xf9309b6df93881ac, released from the list
Fri Nov 21 14:35:06 2014 : Debug: (8) eap: Peer sent method MSCHAPv2 (26)
Fri Nov 21 14:35:06 2014 : Debug: (8) eap: EAP MSCHAPv2 (26)
Fri Nov 21 14:35:06 2014 : Debug: (8) eap: Calling eap_mschapv2 to process EAP data
Fri Nov 21 14:35:06 2014 : Debug: (8) eap_mschapv2: cancelling authentication and letting it be proxied
Fri Nov 21 14:35:06 2014 : Debug: (8) eap: No EAP proxy set.  Not composing EAP
Fri Nov 21 14:35:06 2014 : Debug: (8)     modsingle[authenticate]: returned from eap (rlm_eap) for request 8
Fri Nov 21 14:35:06 2014 : Debug: (8)     [eap] = handled
Fri Nov 21 14:35:06 2014 : Debug: (8)   } # authenticate = handled
Fri Nov 21 14:35:06 2014 : Info:  ... adding new socket proxy address * port 58098
Fri Nov 21 14:35:06 2014 : Debug: (9) # Executing group from file /opt/freeradius/etc/raddb/sites-enabled/proxy-inner-tunnel
Fri Nov 21 14:35:06 2014 : Debug: (9)   authenticate {
Fri Nov 21 14:35:06 2014 : Debug: (9)     modsingle[authenticate]: calling eap (rlm_eap) for request 9
Fri Nov 21 14:35:06 2014 : Debug: (9) eap: Expiring EAP session with state 0xf9309b6df83981ac
Fri Nov 21 14:35:06 2014 : Debug: (9) eap: Finished EAP session with state 0xf9309b6df83981ac
Fri Nov 21 14:35:06 2014 : Debug: (9) eap: Previous EAP request found for state 0xf9309b6df83981ac, released from the list
Fri Nov 21 14:35:06 2014 : Debug: (9) eap: Peer sent method MSCHAPv2 (26)
Fri Nov 21 14:35:06 2014 : Debug: (9) eap: EAP MSCHAPv2 (26)
Fri Nov 21 14:35:06 2014 : Debug: (9) eap: Calling eap_mschapv2 to process EAP data

In guess the culprit is this piece of code in peap.c, but I'm not sure about it (since it's being read a few more times:

      if (!t->proxy_tunneled_request_as_eap) {
        fake->log.lvl |= RAD_REQUEST_OPTION_PROXY_EAP;
@alandekok alandekok closed this in 02571c5 Nov 21, 2014
@qnet-herwin
Contributor

This results in a segfaults (at least in 3.0.x, haven't tried master).

In peap.c:1117 fake->packet is set to NULL. In peap.c:1141 an attempt to read fake->packet->offset is done.

@qnet-herwin
Contributor

Changing fake->packet->offset to request->proxy->offset seems to do the trick, since line 1110 copies fake->packet to request->proxy

@alandekok
Member

fixed via commit a1c8bf0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment