Re: networkmanager fails to associate (ipw3945)

[Dan Williams <dcbw redhat com>]

On Sun, 2007-02-11 at 03:36 +0000, Volker Braun wrote:
> On Sat, 10 Feb 2007 17:17:21 -0500, Dan Williams wrote:
> > This is a really complicated issue.  It depends on what disconnect means
> > during the association attempt.  During 802.1x handshakes, it's
> > certainly possible that we have associated and authed to the access
> > point, but if our credentials are wrong, the RADIUS server may have
> > kicked us off, and wpa_supplicant returns a DISCONNECT event.
> 
> With wpa-psk, wpa_supplicant tells you (*)
> 
> "WPA: 4-Way Handshake failed - pre-shared key may be incorrect"
> 
> before disconnecting, that seems to be a better diagnostic. I don't
> know about WPA enterprise. I know that WEP sucks in that regard as well :-)
> 
> My point was that if we get an unspecific CTRL-EVENT-DISCONNECTED we
> shouldn't give up, but try again until the full timeout or until 
> we get an error that makes it clear that we will not be able to
> authenticate. Right now the disconnect shortens the whole 20sec timeout.

In the strict view, if the card or driver sends a DISCONNECT event
during the association attempt, there's nothing that NM or the
supplicant can do.  The card/driver has said it cannot connect.  If
that's in error, then the _driver_ needs to get fixed.  Linux wireless
drivers have a history of being crappy.

In reality, we walk a tightrope of zero-tolerance and making NM usable
for people.  One example is the stance on _only_ using the 'wext' driver
for wpa_supplicant.  This has the happy result of making all major
drivers start actually using WEXT and WE-19, including ndiswrapper and
madwifi.  The airo driver used to send disconnect events during a scan.
I fixed that, and was able to remove the disconnect-suppression during
scan.

Look at this from 10,000 ft.  Why on _earth_ should a WEP+SK or WPA
handshake take more than 20 seconds?  If you're at the margins of the
network, then get closer.  We're not going to make the experience of NM
worse for everyone just to make it better for users who are trying to
connect from the margins of a network.  I understand that the inherent
unreliability of wireless communications makes things more difficult,
but if you don't enforce limits, nobody has an incentive to make things
better.

> Maybe NetworkManager could continue to try to associate in the
> background after the reasonable (like 20sec) timeout passed. That is,
> after 20 sec show again the password dialog but continue quietly until the
> user clicks OK/Cancel. If association succeeds after the timeout, just
> close the password dialog.

I disagree.  That just complicates internal operations & code, and
muddles expectations of the user.

Seriously, when does an association _really_ take more than ~ 20
seconds?  What are you trying to achieve here?  Point: Mac OS X connects
within 3 seconds  in almost all cases, WEP and WPA.  Why does NM +
wpa_supplicant take so darn long?  Part of that time is dhclient being
really slow, and part of it is drivers being buggy.

> Volker
> 
> (*) Though when I tried right now I couldn't associate with the correct
> psk on FC6+ipw2200+wpa_supplicant -Dwext, while NetworkManager works fine.

Right; there are cases that I don't understand where the association
results between NM and wpa_supplicant are different.  We need to find
out why.  It could be that NM is not passing the right options to
wpa_supplicant, or that there are bugs in either NM or wpa_supplicant.
We need to find out where the difference is.

So in conclusion, maybe we remove the " || nm_device_is_activating
(dev)" from supplicant_status_cb() and just ignore the link timeout
while activating.  But the real question is, _why_ would the auth/assoc
take > 20 seconds, and _why_ is the driver sending disconnect events
during the attempt, especially if the association doesn't complete
within the 20s timeout?  What _really_ needs to be fixed here, the
driver or NM?

Thanks,
Dan