GNOME Bugzilla – Bug 403245
NM takes too long to update list of APs
Last modified: 2016-08-25 00:49:46 UTC
Please describe the problem: NM is taking a long time to update the list of available access points through nm-applet, even though the AP can be seen through iwlist ethX scan. Most of the times I have to reload the wifi kernel module (in this case ipw3945) so that NM can actually see any changes. Disabling and reenabling wifi connections through nm-applet doesn't work for that. Steps to reproduce: 1. Turn Off wifi AP 2. Turn on the computer and run NM 3. Turn on the AP Actual results: The AP isn't shown in nm-applet's list of available APs Expected results: The SSID of the new AP should appear in the list and allow me to connect. Does this happen every time? Yes Other information: I'm using Ubuntu Edgy (6.10) with gnome and NM 0.6.3 The wifi card is an IPW3945 embedded in an Acer Laptop
Confirmed here. wifi-radar produces results almost instantaneously, but its documentation warns that it consumes alot of power trying to pull this off. Maybe it would be helpful if nm was told that a client, eg, nm-applet, was viewing the AP list, and could scan the network more frequently when it knows that information is likely to be needed? Also, shortly after resuming from a suspend/hibernate, when roaming between networks is especially likely?
@ronan: is this still a problem with NM 0.6.4 or 0.6.5? Can you see if there are any log messages in /var/log/messages about what NM is trying to do? There's no material difference between how NM scans and how other tools like wifi-radar and wpa_supplicant scan, but drivers make a big difference here. Some drivers don't cooperate when more than one application requests scan results around the same time. Also, can you run "iwevent" and then run, as root, "iwlist eth1 scan" and report the output of iwevent? NM listens for wireless scan events and gathers access points from the card when that even comes in.
@Dan: This is still a problem in 0.6.5 (as used in Ubuntu 7.10), though not so critical as it has been, because the time it takes to recognize the new topology is shorter. There is no message in /var/log/messages about NM, just about the driver (ipw3945). I know there's no difference between *how* NM scans for APs, the problem is *when* it scans and how it stores the results. Normally, this isn't that much of an issue, because it appears only when one is moving and is trying to change APs. iwevent isn't showing outputting anything for now, even after iwlist returned one AP in one run and two in another one. The point is that in this time, NM is showing *four* APs, and from those, only one is listed in iwlist (the listed one is my own AP, and the other one from iwlist isn't listed). All this can be solved if someone adds a button to nm-applet to force it to rescan for APs, instead of waiting for an event, because right now if it doesn't find the AP I'm trying to connect to, I have to disable and reenable NM, so that it "wakes up". The annoying part is that sometimes the AP that I want to connect to is listed in iwlist, but it takes some time to appear in NM's list. Anyway, I don't know if that's a driver problem, since I don't really know the kernel's internal workings, and so I don't know if an AP to appear in iwlist generates the events that NM is waiting for.
wifi-radar produces results essentially immediatly. The man page actually WARNS about this behavior: "Because of a continuous scan, wifi-radar is very power consuming." It seems what we want network-manager to do is a similar continuous scan, but under certain circumstances, eg, when I have the network list popup open. It should also be scanning immediately on login, or resume from suspend/hibernate (in my experience it sometimes takes a while to realise that, no, it's not in the same building it was when I suspended 2 hours ago.)
I am using network-manager 0.6.5-0ubuntu16.7.10.0. I am experiencing the same problems as everyone else. With everyone saying that continuous scanning takes a lot of battery power, it doesn't sound like a good idea to continuously scan when a laptop is unplugged. I like Jeremy's idea of re-scanning on specific events like login and resume from suspend. I also think that a scan should occur when the laptop lid is opened. I frequently close my laptop lid and walk to another building with another access point. I also like the idea of having a "rescan" button in nm-applet that will refresh the list of wireless networks.
Some ubuntu users have noticed this and have made comments: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/150888 While at first a rescan button seemed to be a good solution, I think the suggestion of a rescan being done when the list is opened is a better solution. For those who say that even that may be too often, perhaps a configurable timer can be set so that a rescan happens when the list is opened, and more than 1 minute has passed since last scan, etc.
I think that this should be definitely implemented. Regarding the alternatives, I don't know much about the low level details (wi-fi radar, etc.) but based on what I've read in this thread, I would presume that having a 'rescan/refresh list of networks' would be the best option ... because then you know for sure that the user needs to refresh it. The other alternative mentioned (refreshing when the user opens the nm-applet menu, and only if >n minutes have passed since last refresh) would definitely be good in the sense that you don't need to do anything, but it may end up doing unnecessary scans (sometimes I open the menu to switch to the wired network and turn off wireless networking ... I don't need a rescan at this point).
I also believe that implementing such an option ("rescan wireless networks" in the applet) would be a huge improvement for nm, and I can not understand why this feature has not yet been added. Thanks for your work.
Definitely agree with the comments above. My experience with a laptop: Connect to WiFi network in one building. Suspend laptop and resume in another building miles away. Laptop struggles to reconnect to the previous AP, taking a minute or so, and then pops a dialog asking me to re-enter the password for the now-unavailable AP. That's misleading and annoying. BUT NOTE: Clicking on the nm-applet icon shows the unavailable AP in the list, with a good strong signal, *sometimes in addition to with the newly available AP*. That seems to show that some kind of scan is actually being done, but for some reason the results are getting added to the previous list instead of simply replacing it. Making network-manager flush its old AP list and obtain a new one before attempting to connect after a resume seems like the best approach.
Is this still an issue in 0.9?
I just ran into this again on Ubuntu Precise (NetworkManager 0.9.4.0-0ubuntu3). The workaround that solves it for me is to use a script to turn OFF the WiFi adapter when the machine resumes from suspend. This seems to force NM to do a scan on resume. The script lives in /etc/pm/sleep.d/20-wlan0-down and has the following contents: ============= bin/sh # Use ifconfig to turn off wlan0 so NetworkManager will do a scan and make a connection on resume case "$1" in resume) ifconfig wlan0 down ;; esac =============
I can't believe this is still not fixed :( It's very annoying to disable/enable the interface to do a simple rescan ! There are two simple solutions : - Rescan when opening the applet - Adding a "Rescan" button If I could I would patch this myself
For those still having this problem, what wifi hardware do you have, and what wifi driver are you using? Second, if you have Ubuntu look in /var/log/syslog, if you have Fedora look in /var/log/messages or "journalctl | grep Net" and look for NetworkManager saying that it is "waking up". If you don't see that message, then something on your system is not properly telling NM to wake up from suspend, so NM doesn't know to request a new scan from the wifi driver.
For me the problem isn't after suspend/resume, it's a general issue with NetworkManager not scanning often enough.
(In reply to comment #12) > I can't believe this is still not fixed :( It's very annoying to disable/enable > the interface to do a simple rescan ! ftr, you can do "nmcli dev wifi rescan". However, as mentioned above, that should not be necessary after a suspend/resume.
it still takes ~2-5 minutes to update the wifi list after I do "nmcli dev wifi rescan", is that considered to be a problem ?
This bug is very old, spanning several no longer NetworkManager releases. Since 1.2 NetworkManager uses the scan-list as provided by wpa-supplicant, instead of maintaining it's own list in parallel. https://blogs.gnome.org/dcbw/2016/01/18/networkmanager-1-2-has-better-wi-fi-scanning/ Also, there were several fixes, for example bug 733105. There is still room for improvement, see for example: https://blogs.gnome.org/dcbw/2016/05/16/networkmanager-and-wifi-scans/ , but this bug isn't about those in particular. So, the code in recent NetworkManager changed, and problems with the scan list are quite likely different then what they were years ago. I am closing this as OBSOLETE. If there is still a problem with recent NM, please open a new bug, providing TRACE logfile showing the issue. I am sorry if that is unsatisfying, but chances are that the original bug does no longer happen.
I've tested it again on deepin, which derived from debian unstable, with network-manager 1.2.2, the bug seems still exist. So I'll open a new bug entry later, thanks Thomas. (In reply to Thomas Haller from comment #17) > This bug is very old, spanning several no longer NetworkManager releases. > > Since 1.2 NetworkManager uses the scan-list as provided by wpa-supplicant, > instead of maintaining it's own list in parallel. > https://blogs.gnome.org/dcbw/2016/01/18/networkmanager-1-2-has-better-wi-fi- > scanning/ > > Also, there were several fixes, for example bug 733105. > > > There is still room for improvement, see for example: > https://blogs.gnome.org/dcbw/2016/05/16/networkmanager-and-wifi-scans/ , but > this bug isn't about those in particular. > > > So, the code in recent NetworkManager changed, and problems with the scan > list are quite likely different then what they were years ago. > > I am closing this as OBSOLETE. If there is still a problem with recent NM, > please open a new bug, providing TRACE logfile showing the issue. I am sorry > if that is unsatisfying, but chances are that the original bug does no > longer happen.