I like your changes better. It allows to in the future add a retry max so each failure could be counted and send a R=0 after a certain number of failures. I had briefly looked at the other area and decided it would take more changes work with a response from a failure code than adjust it over when sending the failure with a challenge. Do we know if the password change (and adjustments to retry which make it work) will be included in 2.1.11? johnh... On Thu, 21 Apr 2011, Phil Mayers wrote:
Date: Thu, 21 Apr 2011 12:17:55 From: Phil Mayers <p.mayers@imperial.ac.uk> Reply-To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> To: freeradius-users@lists.freeradius.org Subject: Re: MS-CHAP-V2 with no retry
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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html