wpa_supplicant failure in "Server Fail Fallback" switch setup - rfc4137 EAP Peer State Machine in eap.c
Shahid Mahmood
mahmoods at avaya.com
Fri Mar 28 16:39:59 EDT 2014
Mahmood, Shahid (Shahid <mahmoods <at> avaya.com> writes:
>
>
>
> Hello,
> We have a situation where a Juniper Networks switch is configured in a
‘Server Fail Fallback’ mode. See:
>
http://www.juniper.net/techpubs/en_US/junos12.2/topics/task/configuration/802-1x-server-fail-fallback-cli.html
> In this mode, the switch sends an ‘EAP-Success’ to the device in response
to just an ‘EAP-Request-ID’, without going through the full cycle
authentication.
> 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
> Notice there is no ‘EAP-Request-MD5/TLS’ coming in from the switch.
>
> The device, running a wpa_supplicant (0.5-10) lands here:
> -- eap.c: SM_STEP(EAP)
> {
> …
> else if (sm->methodState != METHOD_CONT &&
> ((sm->rxFailure &&
> sm->decision !=
DECISION_UNCOND_SUCC) ||
> (sm->rxSuccess &&
sm->decision == DECISION_FAIL &&
> (sm->selectedMethod !=
EAP_TYPE_LEAP ||
> sm->methodState !=
METHOD_MAY_CONT))) &&
> (sm->reqId == sm->lastId ||
>
eap_success_workaround(sm, sm->reqId, sm->lastId)))
> ==> SM_ENTER(EAP, FAILURE);
> ..
> }
> At this point, sm->rxSuccess *is* true but sm->decision == DECISION_FAIL,
due to initial condition. This effectively decides the final state
transition, in this case, a FAILURE. rxReq is also false but ignored here.
>
> Although eap.c appears to correctly implement the intent of rfc4137
(specifically page 8 Figure 3: “EAP Peer State Machine”) this obviously
contradicts the expectations from the switch folks.
>
> Questions:
> - Has anyone experienced this? If so, how was that handled?
> - Is this a limitation of rfc 4137 or the implementation? (or both).
> If answer is ‘no’ to all, I would like to know how this configuration can
be supported.
>
> Otherwise, I can share a patch for review, which addresses this scenario.
>
> Appreciate your time,
>
Here is a patch for review. This patch adds handling of "Server Fail
Fallback" configuration in the switch. Authentication happens without
involving RADIUS. wpa_supplicant is running in -D"wired" mode.
VERSION_STR "0.5.10":
---- patch starts --------
diff --git a/eap.c b/eap.c
index 8072d04..7cf3636
--- a/eap.c
+++ b/eap.c
@@ -648,6 +648,12 @@ SM_STEP(EAP)
(sm->reqId == sm->lastId ||
eap_success_workaround(sm, sm->reqId, sm->lastId)))
SM_ENTER(EAP, SUCCESS);
+/* >> AVAYA - Handle switch "Failover", when Success is sent without
authentication */
+ else if (sm->rxSuccess && !sm->rxFailure && !sm->rxReq &&
(sm->reqId == sm->lastId))
+ {
+ SM_ENTER(EAP, SUCCESS);
+ }
+/* << AVAYA */
else if (sm->methodState != METHOD_CONT &&
((sm->rxFailure &&
sm->decision != DECISION_UNCOND_SUCC) ||
@@ -1191,7 +1197,6 @@ struct eap_sm * eap_sm_init(void *eapol_ctx, struct
eapol_callbacks *eapol_cb,
sm->eapol_ctx = eapol_ctx;
sm->eapol_cb = eapol_cb;
sm->msg_ctx = msg_ctx;
- sm->ClientTimeout = 60;
os_memset(&tlsconf, 0, sizeof(tlsconf));
tlsconf.opensc_engine_path = conf->opensc_engine_path;
------- patch ends -----------------
Regards,
Shahid Mahmood
Avaya Inc, Canada
More information about the HostAP
mailing list