On 26/10/2013 19:39, Alan DeKok wrote:
Phil Mayers wrote:
I'm having a *really* hard time understanding how this works at all; I don't get how the code in peap.c:~1126 actually causes a proxy request to be sent; ultimately it's all called via rad_authenticate, which only seems to check/process request->proxy after authorize, when rlm_eap does all it's work in authenticate.
Yes. That's exactly it. The PEAP module bails out of the authenticate section. The packet is proxied. When the proxy reply arrives, the PEAP is called again.
Sure; it's not strictly relevant here, but what confused me is how the middle bit works - peap bails, but what causes the proxy packet to be emitted? I see how this happens if you bail in "authorize", but not "authenticate". (This is not hugely important however, it must be said)
See rlm_eap.c, eap_post_proxy() for more magic.
Put another way - the original PEAP request containing the PEAP inner comes into rad_authenticate via listen.c - I don't see how, once TLS is decoded and peap.c has run the fake request via the inner tunnel server, how the proxy packet gets sent and replied to.
(The reason for wanting to know this is to understand where to put the processing code so that the "fake" can be pushed through post-auth correctly without breaking "proxy as non-EAP" workaround)
That was done in rad_authenticate, IIRC. See commit 860dd99c9d
I'm not seeing that, or I'm doing something wrong. AFAICT rad_virtual_server only calls post-auth if request->reply->code is set, and for packets which are proxied, it is==0 because the reply hasn't been generated yet. The post-proxy/post-auth code for eap/peap ultimately ends up in eappeap_postproxy and AFAICT only calls post-auth if "fake" is found in REQUEST_DATA_EAP_MSCHAP_TUNNEL_CALLBACK, which is only set for the "proxy inner as non-eap" case? In other words, I think post-auth works for peap proxied inner only if "proxy_tunneled_request_as_eap = no", which is not the case for what I'm trying to do. The thing I'm actually trying to do is cause the inner eap-mschapv2 requests to be proxied [to another FR process] to free up the outer processing thread ASAP - this relates to the recent issues we and others have been having with peap/ntlm_auth timeouts under load spikes, which seem to be some sort of Samba concurrency issue - I've used packet captures to time the on-wire response times for the MS-RPC calls from winbind, and they're completing in a timely fashion, but something in the fork/exec/ntlm_auth/winbind-pipe sequence is going slow and blocking the request thread pool :o( Throwing hardware at the problem is the other solution, but I have no way of knowing if this will solve or hide the problem - it could come back at any time, and I really want to understand the cause (e.g. is it the load of fork/exec or does ntlm_auth/winbind have some kind of built-in concurrency issue?)