WPA-Enterprise and wpa_supplicant/hostapd
jkmaline at cc.hut.fi
Tue Sep 20 23:39:35 EDT 2005
On Tue, Sep 20, 2005 at 04:47:19PM +0200, Cristian Ionescu-Idbohrn wrote:
> The thing is 'EAP state=SUCCESS' seems to be enough. Got a green light
> on the switch port and I can talk to the box plugged in there.
The client side is unlikely to care since I'm not aware of any wired
Linux driver that would implement PAE and port control.. Authenticator
does not have an EAP state machine, but anyway, as far the Authenticator
was concerned, the negotiation had already been completed successfully.
It was just wpa_supplicant that was blocking on not receiving EAPOL-Key
> > This is not usually used with wired networks and as such,
> > wpa_supplicant just gets stuck waiting for EAPOL-Key packets. This
> > is otherwise valid behavior, but I would agree that it is a bug if
> > there is no timeout on that state..
> Fixable bug?
Well, the invalid configuration part would be fixed by changing the
Actually, there is a timeout for the full authentication, but I had
disabled it for the wired case. In this case, it would not really have
helped to timeout the association and try again. I ended up changing
wpa_supplicant to ignore eapol_flags configuration if wired driver is
used. I don't know whether I would call that a fix, but at least it
should get rid of this particular cases and all other cases are using
the authentication timeout.
> But, if I now run (cvs 20050920 snapshot):
> # wpa_cli reconfigure
> (no configuration changes) the supplicant will send a 'EAPOL Start',
> the switch will answer with 2 'EAP Request, Identity' (30 s interval),
> followed by a 'EAP Failure' cycle, repeated forever. So it seams the
> 'reconfigure' puts the supplicant in 'EAP state=CONFUSION' ;-) It does
> not reauthenticate. Last known status:
Pointer to the current network configuration was not updated when using
ap_scan=0 mode. This is now fixed in CVS.
Jouni Malinen PGP id EFC895FA
More information about the HostAP