EAP-Fail processing

Chuck Tuffli CTuffli
Tue Sep 2 16:09:45 PDT 2008


I was looking into a problem with EAP-Fail and noticed that the
EAP_RECEIVED state in SM_STEP(EAP) doesn't process rxFail. After
receiving an EAP-Failure, I would have expected the state machine to go
to EAP_FAILURE instead of EAP_DISCARD. Does it make sense to add the
following to the receive processing

--- wpa_supplicant-0.5.10.orig/eap.c  2007-03-24 19:09:50.000000000
-0700
+++ wpa_supplicant-0.5.10/eap.c       2008-09-02 10:13:46.067430000
-0700
@@ -649,6 +649,8 @@
                else if (sm->selectedMethod == EAP_TYPE_LEAP &&
                         (sm->rxSuccess || sm->rxResp))
                        SM_ENTER(EAP, METHOD);
+               else if (sm->rxFailure && sm->decision !=
DECISION_UNCOND_SUCC)
+                       SM_ENTER(EAP, FAILURE);
                else
                        SM_ENTER(EAP, DISCARD);
                break;

? This seems to improve the problem I had with WPS, but I wasn't sure if
this would adversely effect other EAP methods. The goal is to process
the fail immediately instead of waiting for the timeout to expire.

The supplicant trace showing the behavior I was trying to fix is:

5760.604326: EAPOL: SUPP_PAE entering state AUTHENTICATING
5760.604402: EAPOL: SUPP_BE entering state REQUEST
...
5762.028250: EAPOL: SUPP_BE entering state RECEIVE
5777.021936: RX EAPOL from 00:03:7f:00:c0:37
5777.022179: RX EAPOL - hexdump(len=8): 02 00 00 04 04 ed 00 04
5777.022480: EAPOL: Received EAP-Packet frame
5777.022569: EAPOL: SUPP_BE entering state REQUEST
5777.022643: EAPOL: getSuppRsp
5777.022722: EAP: EAP entering state RECEIVED
5777.022840: EAP: Received EAP-Failure
5777.022929: EAP: EAP entering state DISCARD
5777.023006: EAP: EAP entering state IDLE
5777.023086: EAPOL: SUPP_BE entering state RECEIVE
5791.180103: EAPOL: startWhen --> 0
5806.260140: EAPOL: authWhile --> 0
5806.260309: EAPOL: SUPP_BE entering state TIMEOUT

---chuck



More information about the Hostap mailing list