GNOME Bugzilla – Bug 778152
Add option to disable scanning while connected
Last modified: 2020-11-12 14:30:43 UTC
Some kernel drivers (i.e. some Intel cards) do not support background scanning. The combination of this with NM's frequent scan policy makes that the connection becomes very unstable, as every scan request requires channel hopping and thus network throughout drops. I talked with a Intel kernel developer some time ago and they won't fix drivers for older cards, just for new cards. I would like to ask for an adding an option (possible in NetworkManager.conf, nothing too visible) that allows disabling scanning while the card is already connected. This would take less than 10 lines of code (add the option to the file, and add the lines to avoid scanning in src/devices/wifi/nm-device-wifi.c if the option is set) Indeed, I maintain a package in AUR (ArchLinux) https://aur.archlinux.org/packages/networkmanager-noscan/ which completely disables scanning while connected (though it does not provides an option). The package has 12 votes, meaning that at least 12 people are so concerned about this behaviour that are building NM from source just to fix this. IMO adding this option would not hurt NM's quality, as it just allows disabling a particular behaviour which is hurting for a not so small group of users (even if it's arguably a driver's fault).
The comments for the linked networkmanager-noscan package also has some useful information. Just to re-iterate: - read-up for context: https://blogs.gnome.org/dcbw/2016/05/16/networkmanager-and-wifi-scans/ - one way to disable scanning while being connected is configuring an explicit BSSID: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/devices/wifi/nm-device-wifi.c?id=11bc3f191eb2e7cc2039a30a38522873e0919ab6#n1275 bug 513820 - see related bugs: - request scans from applet: bug 774848 - bug 766482 I think first bug 766482 should be fixed, and then we should see what is still missing.
Yes, I know that you can fix to a BSSID, but that's only useful at home (in my case). At work I use the "eduroam" (https://www.eduroam.org/) SSID, which allows internal roaming. There I'm doomed, as either I have to fix to every possible AP I move (the range can be >50, as I use eduroam when I travel to universities around Europe), or I have to enable roaming which breaks any high-speed transfer (including VoIP). Even using wpa_supplicant bsscan_simple might not work, as it might behave in a similar way and will not fix the Card's limitations. Note that bgscan is optional in wpa_supplicant. That's why I'd like to ask for adding a new option here. Nevertheless, I agree that if the whole scanning functionality is about to change for future versions, it does not make sense to think on this option now, until we see how its is finally implemented. But sure it is something to keep in mind for the redesign.
(In reply to alejandro.perez.mendez from comment #2) > Yes, I know that you can fix to a BSSID, but that's only useful at home (in > my case). ACK. makes sense!
Bug 766482 is now fixed, and at least for non-EAP stuff NM will no longer scan on short intervals. This didn't change EAP/WPA Enterprise background scan interval, which is still set at 300 seconds (eg, 5 minutes). In your case, do you ever roam between APs with EDUROAM? Or are the devices in question always in the same place and never move? If you're using VOIP on EDUROAM, and don't have background scanning enabled, I would expect your AP->AP roaming performance to be pretty awful, as the connection will be broken before the supplicant can scan for a new AP to connect to. Depends on how often the supplicant decides to roam and how much signal strength of the APs fluctuates though.
Umm, I don't recall having been notified about this comment. Sorry for the long delay. In my case, with the laptop I've never been in need to roam between APs while an application was on. It's completely different with the mobile phone, of course. But with the laptop, my "roams" consist basically on suspending it, moving to a different meeting room, waking it up and connecting again. But even if I had to roam, I'd prefer to have that single connection drop, than one drop every other minute because of background scanning. I'm not asking for dropping internal roam support. Just asking for a nice gui option to disable it when I KNOW it's not needed. Or, if you prefer, an option that can be set to a connection telling whether it must scan or not in the backgruond. It would be enabled by default, so not interested users would have the same behaviour as now, but advanced users with problems would be able to set it off. I can imagine myself having two eduroam connections, one automatic with background roaming support (for the general usage even these drops are ok), and another one called "eduroam-no-roam" with no roaming disabled that I would active whenever I have to make a long audio conference and I really don't want it to break. Thanks!
Bug 597998, comment 1 (for as much as old) made this seem a no goer
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).