On 04/21/2011 04:03 PM, John.Hayward@wheaton.edu wrote:
Thanks again for your work on this facility.
I built and installed with the new patches. Unfortunately things did not quite work - however with a small change I could get the retry to work properly on a windows7 machine.
The problem is that when we do a retry in addition to setting the challenge value we also need to change the data->code to challenge rather than failure. When the response comes back we can correctly deal with it.
Hmm. I don't see that behaviour. That is probably due to the later changes I made in the EAP-MSCHAPv2 state machine, here: https://github.com/philmayers/freeradius-server/commit/8e3eece6e3c397f3a4b0c... Specifically, the old code compares client current opcode against server last opcode; the patch I wrote above does a switch over server last opcode, then permits one or more valid client opcodes. Response is specifically permitted after failure, as it change-password (opcode 7).
==== original patch -- with suggested changes **** ==== 678 - pairmove2(&response, &handler->request->reply->vps,
This patch is a bit "magic" for my tastes. The only reason it works is because eapmschapv2_compose completely ignores data->code - it chooses the EAP-MSCHAPv2 opcode based on the 2nd VALUE_PAIR* argument. So essentially you're setting data->code to trick the state machine in mschapv2_authenticate, but to someone unfamiliar with the code it would read like you're sending a challenge back, which you're not - you're sending a failure back. An alternative approach would be: --- rlm_eap_mschapv2.c~ 2010-10-13 13:34:16.000000000 +0100 +++ rlm_eap_mschapv2.c 2011-04-21 18:08:19.000000000 +0100 @@ -424,10 +424,6 @@ * a challenge. */ case PW_EAP_MSCHAPV2_RESPONSE: - if (data->code != PW_EAP_MSCHAPV2_CHALLENGE) { - radlog(L_ERR, "rlm_eap_mschapv2: Unexpected response received"); - return 0; - } /* * Ensure that we have at least enough data i.e. remove the check for "client opcode 'response' only valid if we sent a 'challenge'". Or of course, widen the check to: challenge or failure Anyway, they're more or less equivalent. A matter of taste I guess.