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