GNOME Bugzilla – Bug 602215
network-manager unreliable with multiple APs
Last modified: 2014-11-29 17:57:25 UTC
Ubuntu users (at least) are experiencing major reliability issues with network-manager on networks with multiple APs. This has made networking largely useless for affected users, and the generally advised course of action is to switch to an alternative (wpasupplicant and dhclient directly, or wicd). Details at: http://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/111502
That bug report has a bunch of stuff rolled into one. Not a great bug report. ----------------------------------------------- garyo wrote on 2009-07-06: #25 I'm having a similar issue. I have two APs at home, ober83in2 (the good one I want it to use, it's wpa-2) and ober83in1 (the bad one I don't want used). If I'm connected to ober83in2 and suspend the laptop and resume, network manager auto connects me to ober83in1! Is there a config file somewhere I need to edit to make sure it tries ober83in2 first? Oddly, I can't find a man page for network manager. ** this means he tried to connect to ober83in1 at least once. He needs to remove that network from the connection editor by right-clicking the nm-applet icon, then Edit connections..., then deleting that network from the Wireless tab. ----------------------------------------------- Other issues: 1) kernel mac80211 nullfunc scan problems Any kernels earlier than 2.6.29 had a bug where scans could cause the access point to kick you off. That was fixed in 2.6.29. There were a few other bugs with probe-scans that were also fixed in 2.6.29 that could help reconnections with hidden networks after a scan. 2) wpa_supplicant AP hysteresis (or lack thereof) This is especially a problem in WPA and WPA Enterprise networks with multiple APs with the same SSID. Every incoming scan result (some drivers also do background scanning which makes this worse) wpa_supplicant will re-evaluate the scan list and pick the strongest AP, which sometimes makes it try to reassociate with a different AP even if that AP was even 1% better than your current AP, which is pointless and leads to random reassociation failures and glitches. I developed a few patches for the Fedora version of wpa_supplicant (which are not suitable for upstream at this time) that will only switch access points after a scan when the AP is the same ESSID and demonstrably better quality: http://cvs.fedoraproject.org/viewvc/F-11/wpa_supplicant/wpa_supplicant-0.6.8-ap-stability.patch?view=log wpa_supplicant 0.7 will include enhancements to AP roaming support that make this patch unecessary. So basically I need more information from people who are experiencing this problem before I can figure out what the solution to their problem would be, whether it's drivers, wpa_supplicant, or just issues like not knowing how to delete a saved network.
Also not that at least in the 2.6.29 kernel, ath5k had major stability issues and continues to have some stability issues in 2.6.30. I belive that's straightened out in 2.6.31.
Present with a bcm4322 and 2.6.31. What information would be helpful?
Debug logs as described here: http://live.gnome.org/NetworkManager/Debugging from the failure cases. Especially to see if the supplicant is ping-ponging between access points. See the section on "Debugging WiFi Connections".
That guide seems to be out of date or inaccurate. There is no such thing as /var/log/NetworkManager.log anymore. (I believe this has been the case for the past couple of releases at least)
Thanks, fixed.
Created attachment 148085 [details] wpa_supplicant log
Created attachment 148086 [details] daemon log
I've attached the wpa_supplicant log and daemon.log as requested. It's hard to tell if it's the same issue as originally reported, but it does only occur under multiple AP scenarios, as far as I've observed.
That doesn't look like a -dddt log though, it's missing some crucial bits that full debugging gives us. Specifically, what the scan results are, what the connection status is, and what APs its trying to associate with.
Again, that was following the instructions from http://live.gnome.org/NetworkManager/Debugging to enable debugging output from wpa_supplicant under Ubuntu. If there's another way to get it, it doesn't seem to be documented.
Ok, lets try something different then. 1) stop NetworkManager 2) killall -TERM wpa_supplicant 3) wpa_supplicant -dddt -u 4) start NetworkManager 5) reproduce the issue then grab the output from the supplicant. That will ensure that *everything* gets directed to the terminal.
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!
Created attachment 162927 [details] log file from wpa_supplicant -dddt -u The link to the campus-wide WPA2-Enterprise network at UNSW regularly both disconnects and reconnects, or appears to be connected yet stops sending/receiving packets requiring a manual re-connect. This happens in the order of up to 10-15 times a day, regardless of location on campus, even when I'm not moving around. The attached wpa_supplicant -dddt -u log is from this afternoon, where both occured a several times. Thinkpad X61s Ubuntu Lucid 10.04 linux-generic 2.6.32-22-generic network-manager 0.8-0ubuntu3 Intel Wireless WiFi Link 4965AGN REV=0x4 lspci -vn: 03:00.0 0280: 8086:4230 (rev 61) Subsystem: 8086:1010 Flags: bus master, fast devsel, latency 0, IRQ 28 Memory at f7f00000 (64-bit, non-prefetchable) [size=8K] Capabilities: [c8] Power Management version 3 Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+ Capabilities: [e0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting <?> Capabilities: [140] Device Serial Number 53-86-5f-ff-ff-e8-13-00 Kernel driver in use: iwlagn Kernel modules: iwlagn Dmesg from around the time of the log is full of entries like this: [24516.833560] wlan0: associated [24614.352800] wlan0: deauthenticating from 00:23:eb:ad:f2:51 by local choice (reason=3) [24614.368772] wlan0: deauthenticating from 00:23:eb:ad:f2:51 by local choice (reason=3) [24614.375755] wlan0: direct probe to AP 00:23:eb:ad:e8:5e (try 1) [24614.376562] wlan0: direct probe responded [24614.376571] wlan0: authenticate with AP 00:23:eb:ad:e8:5e (try 1) [24614.377227] wlan0: authenticated [24614.423792] wlan0: associate with AP 00:23:eb:ad:e8:5e (try 1) [24614.425647] wlan0: RX AssocResp from 00:23:eb:ad:e8:5e (capab=0x11 status=0 aid=12) [24614.425655] wlan0: associated [24754.747768] wlan0: deauthenticated from 00:23:eb:ad:e8:5e (Reason: 1) [24756.561145] wlan0: direct probe to AP 00:23:eb:ad:e8:5e (try 1) [24756.566266] wlan0: direct probe responded [24756.566276] wlan0: authenticate with AP 00:23:eb:ad:e8:5e (try 1) [24756.567500] wlan0: authenticated [24756.567539] wlan0: associate with AP 00:23:eb:ad:e8:5e (try 1) [24756.569658] wlan0: RX AssocResp from 00:23:eb:ad:e8:5e (capab=0x11 status=0 aid=12) [24756.569665] wlan0: associated [24896.550924] wlan0: deauthenticated from 00:23:eb:ad:e8:5e (Reason: 1) [24898.485962] wlan0: direct probe to AP 00:23:eb:ad:e8:5e (try 1) [24898.490125] wlan0: direct probe responded [24898.490134] wlan0: authenticate with AP 00:23:eb:ad:e8:5e (try 1) [24898.491472] wlan0: authenticated [24898.491511] wlan0: associate with AP 00:23:eb:ad:e8:5e (try 1) [24898.493419] wlan0: RX AssocResp from 00:23:eb:ad:e8:5e (capab=0x11 status=0 aid=12) [24898.493426] wlan0: associated Let me know if you need any more information.
(I'd reopen this bug, but don't seem to have permission to)
Mike: please file a separate new bug report with your exact setup.
As requested, I'm attaching wpa-2.log, a new log from wpa-supplicant, and daemon-2.log, an ubuntu daemon.log containing network-manager and dhclient events for the same period. Sorry it took so long to get this, but since I really need the network working, and network-manager drops for minutes at a time every few minutes, I've been using wicd almost exclusively for months now. It works great... except that it doesn't integrate with anything else.
Created attachment 163082 [details] Log of wpa_supplicant -dddt -u
Created attachment 163083 [details] ubuntu daemon.log
Sorry to pull up an old bug, but I think I'm having the same issue (Gnome 3, F16). I'm a student at GSU, and we have a campus-wide network named CatChat 2x, which consists of lots of wireless gateways all over campus, all named CatChat 2x, frequently overlapping one-another. I don't have (the same magnitude of ;) problems in Windows or on my Android phone, but in Fedora 16 I frequently cannot sign on to the network, and if I do manage to sign on, I will often get disconnected. I had the same problem on my previous lap-top (I have an Aspire 7750G now, but I had the same issue with an Asus Z96-J). I have this problem at school, where we have lots of AP's with the same name near each other, but I do not have this problem at home (I can connect to my own WPA2-secured network without issue, despite being in an apartment and surrounded by lots of other wireless AP's).
(In reply to comment #20) > Sorry to pull up an old bug, but I think I'm having the same issue (Gnome 3, > F16). > I'm a student at GSU, and we have a campus-wide network named CatChat 2x, which > consists of lots of wireless gateways all over campus, all named CatChat 2x, > frequently overlapping one-another. I don't have (the same magnitude of ;) > problems in Windows or on my Android phone, but in Fedora 16 I frequently > cannot sign on to the network, and if I do manage to sign on, I will often get > disconnected. I had the same problem on my previous lap-top (I have an Aspire > 7750G now, but I had the same issue with an Asus Z96-J). I have this problem > at school, where we have lots of AP's with the same name near each other, but I > do not have this problem at home (I can connect to my own WPA2-secured network > without issue, despite being in an apartment and surrounded by lots of other > wireless AP's). If we can get some of the wpa_supplicant logs from your setup as described earlier in this bug report that would be great. See comment #12.
Created attachment 212633 [details] wpa_supplicant.log This may the wrong log. I stopped NetworkManager, killed wpa_supplicant, restarted it with the output redirected, and restarted NetworkManager, as per instructions. What I'm attaching is the output I captured from NetworkManager. I may be an idiot, but nothing in /var/log/ looked relevant, judging by file names; let me know if there's anything else that I should attach that might be useful.
Still valid?
(In reply to comment #16) > Mike: please file a separate new bug report with your exact setup. Sorry for not getting around to that, but 0.9.8.4 has been working pretty well for me around campus. I don't think this affects me any longer.
(In reply to comment #24) > I don't think this affects me any longer. Thanks. Closing as OBSOLETE then.