wpa_supplicant failure in "Server Fail Fallback" switch setup - rfc4137 EAP Peer State Machine in eap.c
Mahmood, Shahid Shahid
Wed Feb 26 08:38:44 PST 2014
We have a situation where a Juniper Networks switch is configured in a 'Server Fail Fallback' mode. See:
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->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.
- 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,
Avaya Inc, Canada
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Hostap