On 05/18/2012 10:23 PM, Alan DeKok wrote:

Phil Mayers wrote:

...

Am I being dumb / getting something wrong or does the post-auth session not get called if PEAP/MSCHAP returns a reject?

It seems to run for successful auths, but not failures.

That is the case.

...

This is in the context of us not seeing log messages for EAP auth failures; I suspect that the client may just "hang up" and let the EAP session expire, and since the inner post-auth doesn't run, and the outer session expires, I have no logs.

There was talk about getting it to do Post-Auth-Type Reject in the inner tunnel. No code yet, tho.

Ok, so after a bit (well, a lot) of digging, the cause seems to be that "Post-Auth-Type REJECT" is actually implemented in event.c:request_post_handler as opposed to auth.c:rad_authenticate - the latter handles successful post-auth, but the former rejects. The post handler doesn't seem to be called for the PEAP (and presumably TTLS) fake requests, but I gave up trying to track down which code path invokes request_post_handler - the socket or thread code? The comments in rad_authenticate initially suggested this is probably not the intention: /* * Result should be >= 0 here - if not, it means the user * is rejected, so we just process post-auth and return. */ if (result < 0) { return RLM_MODULE_REJECT; } ...and of course the code doesn't process post-auth, it just returns. But it looks like this changed here, so in fact it's just an out-of-date comment: https://github.com/alandekok/freeradius-server/commit/1b26bbb7576fabed84c477... What's the appropriate way to fix this? Presumably, if "rad_authenticate" doesn't call post-auth for reject, then ANY caller of rad_authenticate must take responsibility for doing so, but also somehow ensure that request_post_handler doesn't call it a 2nd time?