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 <[email protected]>
Reply-To: FreeRadius users mailing list
<[email protected]>
To: [email protected]
Subject: Re: MS-CHAP-V2 with no retry
On 04/21/2011 04:03 PM, [email protected] 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/8e3eece6e3c397f3a4b0c06a37a80bc8964997fd
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
