Re: Unnecessary reconnects

On Tue, 2006-12-05 at 14:35 -0700, Wade Berrier wrote:
> Hi,
> I'm using NetworkManager on SuSE 10.1 with the madwifi driver.
> I occasionally get messages such as these (from wpa_cli):
> > <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
> <2>Trying to associate with 00:13:10:43:3b:42 (SSID='berrier' freq=2462
> MHz)
> <2>Association request to the driver failed
> <2>Associated with 00:13:10:43:3b:42
> <2>WPA: Key negotiation completed with 00:13:10:43:3b:42 [PTK=TKIP
> <2>CTRL-EVENT-CONNECTED - Connection to 00:13:10:43:3b:42 completed
> (reauth)
> When I use NetworkManager and this happens, network manager disconnects
> and reconnects, flushing evolution, firefox, gaim, and dhcpcd, as well
> as shutting down all my vpn connections.
> When I use the traditional ifup/down method and the above disconnect
> happens, there is a network hiccup, but after about 15 seconds my
> services continue to work, making me think a full reconnect is
> unnecessary.
> Maybe a timeout period could be lengthened or specified to give enough
> time for wpa_supplicant to try to recover before restarting all the
> services?

That seems like a gross hack.  Is this the rekey interval?  Does it
really take 15 seconds to rekey?   If so, are you at the margins of the
network?  what's your configuration, WPA[2] Enterprise?  Because if this
is a WPA-PSK connection, that's really wrong...  Also, what madwifi
revision #?  Older ones are _known_ not to work well in some cases.

> What triggers the disconnect in nm?  The CTRL-EVENT-DISCONNECTED message
> from wpa_supplicant, or the inability to reach the gateway?

wpa_supplicant sees the connection has been disconnected, and tells NM.
NM starts a 6 or 10 second timer, and if the connect has not been
brought back up after that time, it kills the connection.

> In either case, it seems that it would be better for nm to wait 10 or 20
> seconds to see if the connection comes back up, rather than to restart
> the world.

Again, that seems like a hack.  People always complain that "the
timeouts are too short for my situation" without fully understanding
_why_ they are too short.  The solution is not to keep increasing the
timeouts to infinity, it is to find out what's going on and if the
problem is the network, or NM.  That's not clear to me right now.  But
requests to up the timeouts raise serious questions and need to be
considered fully before something like that is done...


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]