[PATCH] wpa_supplicant failure in "Server Fail Fallback" switch setup - rfc4137 EAP Peer State Machine in eap.c
Mon Mar 31 06:52:00 PDT 2014
The following patch addresses the situation when wpa_supplicant goes into a
failed state in a certain switch configuration.
Some switches, such as those from Juniper Networks, allow a so called
"Server Fail Fallback" mode, in which case, if the RADIUS server is
unreachable, the switch itself makes EAP-Success or EAP-Fail decisions.
Roughly, the transaction looks like this:
1) Switch: ===> EAP-Request-ID
2) Device: ===> EAP-Response-ID
3) Switch: ===> EAP-Success
4) Device goes to a FAILURE state
There is no ?EAP-Request-MD5/TLS? coming in from the switch. wpa_supplicant
goes into FAILED state.
I checked the RFC 4137 and the behavior seems to reflect correctly what is
mentioned in Fig 3 "EAP Peer State Machine". I have launched another probe
into that direction. But with current state of the state machine in
wpa_supplicant, thi type of switch configurations are impossible to support.
I have also heard that Cisco switches can also support something like. I
think it is reasonable to expect EAP clients (with wpa_supplicant) to
respond in a meaningful way.
For that, I am proposing the following patch (which has been tested with
this and other common scenarios):
The wpa_suppicant version: 0.5.10, in "wired" mode.
Author: Shahid Mahmood <mahmoods at avaya.com>
Date: Mon Mar 31 06:47:09 2014 -0700
[PATCH] Handle RADIUS Failover switch configuration
diff --git a/eap.c b/eap.c
index a5cd982..5afc8c4 100644
@@ -618,6 +618,12 @@ SM_STEP(EAP)
(sm->reqId == sm->lastId ||
eap_success_workaround(sm, sm->reqId, sm->lastId)))
+/* >> AVAYA - Handle switch "Failover", when Success is sent without authentica
+ else if (sm->rxSuccess && !sm->rxFailure && !sm->rxReq && (sm->r
+ SM_ENTER(EAP, SUCCESS);
+/* << AVAYA */
else if (sm->methodState != METHOD_CONT &&
sm->decision != DECISION_UNCOND_SUCC) ||
shahid (mahmoods at avaya.com)
Avaya Inc, Canada
More information about the Hostap