On Sat, 2007-02-10 at 16:46 +0000, Volker Braun wrote: > In dragoran's wpa_supplicant log there is this suspicious entry somewhere > at the beginning: > > Wireless event: new AP: 00:00:00:00:00:00 > Added BSSID 00:00:00:00:00:00 into blacklist > State: ASSOCIATING -> DISCONNECTED > > driver bug? wpa_supplicant bug? I don't see the reason for why > wpa_supplicant disconnects, but it does. Of course, it immediately tries > again and succeeeds.
This is a driver bug. The driver lost association to the AP, or the AP told the driver to disconnect itself by sending a disassociation or deauthentication frame, or a driver/firmware timer expired, or something like that. It's essentially the card saying "I can't connect" or "I lost the connection", and there's not much that NM or wpa_supplicant can realistically do about it. > But NetworkManager then ticks differently. The supplicant_timeout_cb() had > 20 seconds to complete, but now it has only 8 seconds for the > link_timeout_cb. > > Feb 8 13:48:49 localhost NetworkManager: <information> SUP: sending > command 'ENABLE_NETWORK 0' > Feb 8 13:48:49 localhost NetworkManager: <information> SUP: response > was 'OK' > Feb 8 13:48:49 localhost NetworkManager: <information> Activation > (eth1) Stage 2 of 5 (Device Configure) complete. > Feb 8 13:48:57 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes > ready > > Comment: doesn't that mean that the link is up now? Not really; that's the driver calling netif_carrier_on(), which doesn't really mean anything for wireless interfaces. Does it mean that the card associated? Or does it mean that the card has authenticated? Or does it mean the card can actually pass frames to the AP? Or does it mean that you can actually send traffic _beyond_ the AP? netlink carrier detect is essentially useless on wireless links, and nobody (neither NM nor wpa_supplicant) uses wireless carrier notifications for anything because of that. All drivers do netif_carrier_* differently anyway, partially because its useless. > Feb 8 13:48:59 localhost avahi-daemon[2565]: New relevant interface > eth1.IPv6 for mDNS. > Feb 8 13:48:59 localhost avahi-daemon[2565]: Joining mDNS multicast group on > interface eth1.IPv6 with address fe80::218:deff:fe05:f79e. > Feb 8 13:48:59 localhost avahi-daemon[2565]: Registering new address record > for fe80::218:deff:fe05:f79e on eth1. > > Comment: it is now 11 seconds past the start of the supplicant_timeout, > usually we wouldn't give up yet. > > Feb 8 13:49:00 localhost NetworkManager: <information> Activation > (eth1/wireless): disconnected during association, asking for new key. > Feb 8 13:49:00 localhost NetworkManager: <information> Activation > (eth1) New wireless user key requested for network 'mynet'. > > I think the heuristic DISCONNECT => need new password is wrong. We should > at least try a few times. Either wait until we have a fixed number of > disconnects, or wait until the end of the supplicant timeout even if there > are initial disconnects. 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. There was a patch a while ago that normalized the 'new key' requests. It seemed to make sense at the time. Before we change it, I'd urge a review of what exactly it means when wpa_supplicant sends the disconnect event during an association for the different auth methods (including WEP shared key/open system). NetworkManager should probably be trying a little harder before giving up, but definitely not by increasing timeouts. Remember that on WEP Open System connections, you _never_ know if your WEP key is wrong until 45 seconds later when DHCP times out. Trying again would be a connect time of 1:30, and that's just wrong. WPA is a lot better here because there are hard failures when your credentials or keys are wrong, and we should take advantage of that. Dan _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list