PEAP/MSCHAP doesn't run post-auth in inner-tunnel for reject?

[Phil Mayers]

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/1b26bbb7576fabed84c477e9f5f70e4d21906877



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?