| RE: Issue 193: Peer SM review | <– Date –> <– Thread –> |
|
From: Pasi.Eronen (Pasi.Eronen |
|
| Date: Mon, 15 Dec 2003 10:35:09 -0600 (CST) | |
Replying to myself (not a good habit):
>
> However, eapSuccess and eapFail must be initialized by
> the lower layer; otherwise there's a race condition.
...but 1X-REV/D8 explicitly states that they are
initialized by EAP. And yes, there's a race condition.
Here's a possible sequence of events:
1. portEnabled becomes TRUE
2. Supplicant PAE moves to CONNECTING state and executes it
3. After a while, eapolEap becomes TRUE (a request is received)
4. Supplicant PAE moves to RESTART state and executes it,
setting eapRestart to TRUE
5. EAP peer moves to DISABLED state and executes it,
resetting eapRestart to FALSE
6. Supplicant PAE moves to AUTHENTICATING state and executes it,
setting suppStart to TRUE (among other things).
7. Supplicant backend was sitting happily in the IDLE state.
Now it checks the conditions "eapFail && suppStart" and
"eapSuccess && suppStart".
8. EAP peer moves to INITIALIZE state and executes it; but
it's now too late to initialize eapSuccess and eapFail!
Hmm, would this change fix it?
portEnabled && eapRestart
|
V
+----------------------+
+----------+ | INITIALIZE |
| DISABLED | +----------------------+
!portEnabled --->+----------+--portEnabled-->| eapSuccess=FALSE |
| | | eapFail=FALSE |
+----------+ | ... |
| eapRestart=FALSE |
+----------------------+
|
UCT
|
V
Best regards,
Pasi
- RE: Issue 193: Peer SM review, (continued)
-
RE: Issue 193: Peer SM review CONGDON,PAUL (HP-Roseville,ex1), November 14 2003
- RE: Issue 193: Peer SM review Bernard Aboba, November 19 2003
-
RE: Issue 193: Peer SM review Pasi.Eronen, December 15 2003
- Re: Issue 193: Peer SM review Jari Arkko, December 15 2003
- RE: Issue 193: Peer SM review Pasi.Eronen, December 15 2003
-
RE: Issue 193: Peer SM review CONGDON,PAUL (HP-Roseville,ex1), November 14 2003
Results generated by Tiger Technologies using MHonArc.