Hi, On Wed, 2006-12-06 at 08:11 -0500, Dan Williams wrote: > On Tue, 2006-12-05 at 14:35 -0700, Wade Berrier wrote: > > > > > > 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. No question the problem is in the driver, so it would be a nm hack. But, this 'hack' is already in place. A timer is already started when getting the DISCONNECTED message from wpa_supplicant. In my situation (which others are running into as well), it might help if this timer was extended. Maybe I just need to try it and report... It's not a rekey, nm and wpa_supplicant handle the rekeying perfectly. And, I have pretty good signal (about 25 feet away in my house through some walls). And, although this sounds kinda funny, it happens more when the microwave is turned on and off a few times :) I'm using wpa 1, with tkip psk. I'm using madwifi revision 1732 that comes with Novell SLED, but as noted below, the problem still happens in 0.9.2. > > > 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... I understand that we don't want to increase the timeouts to infinity. And I probably do have noise: several other networks in the neighborhood, the above mentioned microwave, etc... what other problems in the network should I be looking for? Just trying to offer some solutions that will help my wireless usage, and possibly other's as well. Thanks, Wade
Attachment:
signature.asc
Description: This is a digitally signed message part