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. 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 Alan DeKok.