hostapd mixing EAP ids

[Jouni Malinen]

On Fri, Oct 21, 2005 at 03:40:06PM -0600, Ahmet Basagalar wrote:

> IEEE 802.1X: 00:02:6f:07:c4:dc BE_AUTH entering state REQUEST
> IEEE 802.1X: Sending EAP Packet to 00:02:6f:07:c4:dc (identifier 34)
> IEEE 802.1X: 00:02:6f:07:c4:dc REAUTH_TIMER entering state INITIALIZE
> IEEE 802.1X: 00:02:6f:07:c4:dc BE_AUTH entering state RESPONSE
> Encapsulating EAP message into a RADIUS packet

I was able to reproduce similar case by forcing the supplicant to send
out all EAP packets twice. This transition from BE_AUTH REQUEST to
RESPONSE without receiving anything from the supplicant seems to be the
main problem. It means that there was a pending EAP-Response from the
station (likely EAP-Response/Identity) and the authenticator is just
sending it out when receiving a new request from the authentication
server.

I did not find any clear place in the state machine that would clear
eapolEap in cases where an extra EAP packet is received unexpectedly.
After going through the state machines for a while, it looks like the
best way to resolve this would be to set eapolEap to FALSE in
BE_AUTH::REQUEST. This is quite close to what you did in the function
generation EAP-Request/Identity, but actually done for all EAP packets
since this is by no means limited to just EAP-Request/Identity.

It would still be interesting to find out where this happened in real
life since my test case is done be forcing the supplicant to do odd
things.. If there is a clear scenario for this happening during normal
operations, it would be worthwhile to update the IEEE 802.1X standard to
take this into account.

-- 
Jouni Malinen                                            PGP id EFC895FA