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 _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
