GNOME Bugzilla – Bug 418065
Wireless network keeps reconnecting (ubuntu edgy)
Last modified: 2010-10-03 21:20:52 UTC
Please describe the problem: NetworkManager frequently disconnects and reconnects to the network under certain conditions. Steps to reproduce: 1. Use a wireless card that is prone to the issue. A number of Intel chipsets have been confirmed, as well as a Proxim Orinoco card based on the Atheros chipset. 2. Use NetworkManager 3. Actual results: Frequent disconnect and reconnects happen, sometimes just seconds apart Expected results: The connection should stay active Does this happen every time? It happens regularly when I use an affected card, yes. Other information: Much more detail including an initial patch is provided through this bug report in the Ubuntu bug tracker: https://launchpad.net/ubuntu/+source/network-manager/+bug/64173
So why is the connection dropping? The logs indicate that wpa_supplicant lost association to the access point. It could be that periodic wireless scans trigger the driver to do something stupid and loose association. A way to test this independently of NetworkManager is to set up a wpa_supplicant config, and run successive 'iwlist eth0 scan' commands 5 or 7 seconds apart to stress the driver. If the driver looses association as a result of a scan request, this is clearly a driver bug.
This also appears to be the same bug, reported in a second Ubuntu bug report: https://launchpad.net/network-manager/+bug/37821 It's notable that the reporters say the cards work fine when NetworkManager is not in use. Outside of the bug report I had mentioned that I was using "madwifi" and not "madwifi-ng". I was believe I was incorrect and that I am using "madwifi-ng", which is installed by default on Ubuntu Edgy. I see that I have a "wifi0" device created. I also tried repeated manually scanning as you suggested. This worked very quickly, and caused no drops using Ubuntu's standard networking tools (not NetworkManager). This data seems to point back to a possible NetworkManager bug.
Here some more data points, which look like the same issue: NM 0.6.4, madwifi, reported on the NM list in Nov, 2006 (no response): http://mail.gnome.org/archives/networkmanager-list/2006-November/msg00051.html Again, on Feb 17th, 2007, a post to the NM list, also with an Atheros card on Ubuntu Edgy, showing frequent disconnects even on an unsecured network: http://www.mail-archive.com/networkmanager-list@gnome.org/msg05606.html ##### Here's some more data from own experience with it. First a capture of what "iwevent" sees: $ iwevent Waiting for Wireless Events from interfaces... 20:02:14.336413 ath0 New Access Point/Cell address:Not-Associated 20:02:14.438624 ath0 Set ESSID:off/any 20:02:24.423241 ath0 Set ESSID:"" 20:02:26.427965 ath0 Set Encryption key:off 20:02:26.428536 ath0 Set Mode:Managed 20:02:27.455615 ath0 Set Mode:Managed 20:02:27.472242 ath0 Set ESSID:"HIJB" 20:02:27.486330 ath0 New Access Point/Cell address:XXXobscuredXXX ############# I'm not sure if this interesting, but it shows what the disruption looks like to a steady stream of pings to the AP: 64 bytes from 192.168.1.1: icmp_seq=285 ttl=127 time=1.02 ms 64 bytes from 192.168.1.1: icmp_seq=286 ttl=127 time=1.03 ms 64 bytes from 192.168.1.1: icmp_seq=287 ttl=127 time=1.04 ms 64 bytes from 192.168.1.1: icmp_seq=288 ttl=127 time=1.05 ms 64 bytes from 192.168.1.1: icmp_seq=289 ttl=127 time=287 ms ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable 64 bytes from 192.168.1.1: icmp_seq=306 ttl=127 time=5.86 ms 64 bytes from 192.168.1.1: icmp_seq=307 ttl=127 time=0.890 ms 64 bytes from 192.168.1.1: icmp_seq=308 ttl=127 time=1.01 ms #########################
Can you post your /var/log/messages from during the time when you're running 'iwevent'? Neither wpa_supplicant nor NetworkManager should be disconnecting the connection unless there's an iwevent of "New Access Point/Cell 00:00:00:00:00:00" reported by the driver.
Hi guys, I'm the one who created that Ubuntu bug #64173 that was referenced above. I have looked a bit more into what is happening in the system now, and it seems that I only get these network dropouts when I see these "New Access Point/Cell 00:00:00:00:00:00" messages. Do I understand you correctly, that this is actually supposed to happen? What seems a bit strange to me is that this only happens when NetworkManager is running on my computer - when another similar tool (kwlan) is used I see no connection dropouts. If it was a driver or wpa_supplicant problem I would think that this issue would still be there - but it may be that NM is using the WLAN system a bit differently. I will see if I can find the time to reinstall kwlan and provoke the driver a bit using iwscan in the weekend.
Dan, Here's the /var/log/messages output during a disconnect/reconnect event. I include one leading line of context from the previous connection. I'm also running VPN on top of connection. It looks like the first thing that happens is that the VPN gets killed (by what?) ############## Mar 15 20:39:04 mat pppd[8295]: remote IP address 192.168.97.133 Mar 15 20:41:59 mat pppd[8295]: Terminating on signal 15 Mar 15 20:41:59 mat pppd[8295]: Connect time 3.0 minutes. Mar 15 20:41:59 mat pppd[8295]: Sent 385658 bytes, received 853276 bytes. Mar 15 20:41:59 mat pppd[8295]: Child process /usr/sbin/pptp 12.161.105.133 --nolaunchpppd (pid 8296) terminated with signal 15 Mar 15 20:41:59 mat pppd[8295]: Modem hangup Mar 15 20:41:59 mat pppd[8295]: Connection terminated. Mar 15 20:42:01 mat pppd[8295]: Exit. Mar 15 20:42:01 mat kernel: [17257483.080000] ADDRCONF(NETDEV_UP): ath0: link is not ready Mar 15 20:42:04 mat kernel: [17257485.120000] ADDRCONF(NETDEV_CHANGE): ath0: link becomes ready Mar 15 20:42:11 mat dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.ge t.host_name Mar 15 20:42:11 mat dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.ge t.domain_name Mar 15 20:42:11 mat dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.ge t.nis_domain Mar 15 20:42:11 mat dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.ge t.nis_servers
I tried the patch for this issue provided here: https://launchpad.net/ubuntu/+source/network-manager/+bug/64173 It allows some timeout value to be adjusted from 8 seconds to 20 seconds. Once applied, the problem completely disappears on Ubuntu Edgy (using NM 0.6.3). Mark
Hello folks. I wanted to report my experience with the patch suggested by Mark S. (provided by Fionn). In the three days of testing it on Ubuntu Fiesty with NetworkManager 0.6.4, I can report that it does help significantly but has not completely eradicated the problem in my case. Over the last 16hrs (roughly) of computer usage, I can remember two drop-out/reconnects. Compare this to one every 5-15 minutes (or less) and progress has definitely been made. I'll watch /var/log/messages for changes during a reconnect even in the future. This message will be reposted under lauchpad bug #64173 as well. Matt
As promised, here's an output from /var/log/messages during a reconnect event: Apr 8 09:52:14 squid-linux kernel: [ 2871.588823] ADDRCONF(NETDEV_UP): ath0: link is not ready Apr 8 09:52:16 squid-linux kernel: [ 2873.894889] ADDRCONF(NETDEV_CHANGE): ath0: link becomes ready Apr 8 09:52:22 squid-linux dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.host_name Apr 8 09:52:22 squid-linux dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.domain_name Apr 8 09:52:22 squid-linux dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.nis_domain Apr 8 09:52:22 squid-linux dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.nis_servers
Would it help if I loaned a developer an affected (Proxim) card for a couple of weeks? I have a backup card, which works but lacks a couple of features.
I just want to re-iterate my offer to loan a developer an affected card if that would help to get this problem fixed.
What are the details on the Proxim card? Is it driven by the hostap driver, and if so, what version? I've personally got a b/g madwifi card, prism54, cisco aironet minipci & pccard, orinocos, tiacx, ipw2200, ipw2100, ipw3945, and they all exhibit varying stages of working/less-working drivers, but none appear to exhibit this problem.
This bug is also present in Ubuntu Gutsy using an Atheros chipset 02:00.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
There is a _lot_ of discussion on the Ubuntu bug tracket about this, as they are gearing up for the 7.10 release in October and this is such a critical issue.. https://bugs.launchpad.net/bugs/64173
Someone says on the launchpad that blacklisting the ipv6 module fix this issue
You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you please check again if the issue you reported here still happens in a recent version and update this report by adding a comment and adjusting the 'Version' field? Again thank you for reporting this and sorry that it could not be fixed for the version you originally used here. Without feedback this report will be closed as INCOMPLETE after 6 weeks.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
Hi, guys! This bug is really annoying, it must be fixed. It's really a pity that many wifi users are forced to use wicd. BTW, it works fine and stable, so it's not the drivers/hardware to blame. If you search the web, you'll find many topics like this one: http://ubuntuforums.org/showthread.php?t=787645 Of course, there's still some possibility that driver doesn't behave correctly, but there should be some workaround. It seems that during network scans NetworkManager sometimes resets SSID to some garbage - and we have what we have. For example, that's what I've seen just a second earlier: root@darkmoon:~# iwconfig lo no wireless extensions. eth0 no wireless extensions. wlan0 IEEE 802.11bg ESSID:"%\xCF\x08\xF5\xE9\xE2^S`\xAA\xD2\xB2\xD0\x85\xFAT\xD85\xE8\xD4f\x82d\x98\xD9\xA8\x87uepZ\x8A" Mode:Managed Frequency:2.427 GHz Access Point: Not-Associated Tx-Power=20 dBm Retry long limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off While under normal condition this reads as: root@darkmoon:~# iwconfig lo no wireless extensions. eth0 no wireless extensions. wlan0 IEEE 802.11bg ESSID:"kse_wifi_network" Mode:Managed Frequency:2.427 GHz Access Point: 00:1A:70:33:B6:CD Bit Rate=24 Mb/s Tx-Power=20 dBm Retry long limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=59/70 Signal level=-51 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 This is very likely to be NetworkManager bug. Possibly in some network scanning code or auto-connection code.