wpa_supplicant failure in "Server Fail Fallback" switch setup - rfc4137 EAP Peer State Machine in eap.c

[Mahmood, Shahid Shahid]

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,

Regards,
----------------------
Shahid Mahmood
Avaya Inc, Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20140226/3f434dce/attachment.htm>