Re: networkmanager fails to associate (ipw3945)

[Dan Williams <dcbw redhat com>]

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