> IIRC, it was to remember replies better. When the inner tunnel > returns accept and the outer sends a challenge... remember the > accept for later.
I just cloned and built the latest 2.1.10 to do some testing. I did a PEAP-MSCHAPv2 authentication, with bad credentials, using eapol_test. What I found seems to indicate the problem I was referring to still exists in 2.1.10 (probably because I wasn't clear enough in describing the issue). It seems that after ntlm_auth fails, it sends the EAP failure via an Access-Challenge. Then, after it receives the response in the next Access-Request, it sends Access-Reject. This is how it behaved prior to 2.1.9 also (this is what I meant by "extra round trip" in a previous post). The problem is that any information stored in an attribute, after the ntlm_auth failure, will not survive the subsequent Access-Challenge, Access-Request. I can post the debug output if you'd like to see it. When I originally discovered this, I suggested storing the ntlm_auth output in the eap handler so it could be saved in Module-Failure-Message when the response to the EAP failure is received. Is there a better approach? If you tell me your preference, I'd be willing to create a patch.. Thanks for your time Alan. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
