hostapd mixing EAP ids

[Jouni Malinen]

On Thu, Oct 20, 2005 at 04:35:53PM -0600, Ahmet Basagalar wrote:

> I think I have found the problem. In ieee802_1x.c, function 
> ieee802_1x_new_auth_session , eapolEap flag must set to False, otherwise in 
> some cases when there is a left over eap response from supplicant, it is 
> send as the response to Radius server (BE_AUTH goes to RESPONSE state 
> without getting the response from supplicant)

Thanks! This is very helpful information.

> So I just added:
> 
>     sm->eapolEap = FALSE;
> 
> at the end of this function. It seemed to fix the problem. Let me know your 
> comments...

I was trying to reproduce this kind of problems in my test setup and was
easily able to get into this state with 0.4.x branch since it has a
change that ends up allowing received EAP packets to be processed before
all possible EAPOL state machine steps have been completed. However,
this issue did not happen with 0.3.9 that you are using since it runs
EAPOL steps to completion before receiving the next frame.

Setting eapolEap to FALSE in ieee802_1x_new_auth_session() sounds
reasonable, but it is also looking like it could be just hiding the real
problem. I would like to understand what is triggering this behavior
with the 0.3.x-style of EAPOL state machine stepping that does not
allow, e.g., EAPOL-Start and EAP-Identity/Response to be processed while
going through possible steps from the previous packet.

It is possible that something else is not initialized in case of
EAPOL-Start processing. If the exact trigger mechanism for this issue
can be figured out (e.g., from debug log, if this can be easily
reproduced). If this seems to take too much time, I'm considering of
just applying this changes since it looks like something that should not
cause problems (apart from maybe hiding the real bug in a way that makes
it even more difficult to find in the future, should there be a need to
really fix it).

-- 
Jouni Malinen                                            PGP id EFC895FA