GNOME Bugzilla – Bug 766454
Add: priority list of network connections.
Last modified: 2020-11-12 14:28:05 UTC
Please add possibility to group networks by priority. For example, some wireless networks should be more preferable than other's. Or someone woul like to make wireless connection more preferable than Ethernet.
Priority or preferable in which regard? Regarding autoconnect, there is connection.autoconnect-priority Regarding routing, there is ipv4.route-metric and ipv6.route-metric. Regarding DNS, there is now ipv4.dns-priority and ipv6.dns-priority.
Regarding autoconnect. I do not see any oprion in nm-applet...
nm-connection-editor does not expose this in the UI (yet). Set if for example with nmcli connection modify $CONNECTION connection.autoconnect-priority 5 See `man nm-settings`.
Thanks! :) Hope to see it in GUI in future !
> Or someone woul like to make wireless connection more preferable than Ethernet. reading this again... note that "autoconnect" works like this, that when a device becomes ready to be automatically connected (e.g. when you plugin the ethernet cable, or a Wi-Fi network comes into range), then NM will search through all applicable connections that are configured to autoconnect. If there are multiple candidates, it prefers the one with higher autoconnect-priority. If there are still multiple candidates left, the one that was connected last is chosen (by timestamp). That's why your previous statement doesn't apply for autoconnect: an ethernet device can only use a connection of type ethernet and a wifi device only uses connections of type wifi. In other words, the autoconnect-priority between an ethernet connection and a wifi connection doesn't matter, as they are never compared against each other. > For example, some wireless networks should be more preferable than other's. yeah, that is the main use of autoconnect-priority. Say, you live above starbucks and when you are at home you always want to preferably connect to your home-wifi.
Is it possible to combine several connections and several devices priorities ? I have both ethernet and Wi-Fi. Ethernet is faster, but rarely it becomes broken due to chinese switch and I would like to have automatic Wi-Fi connection when the ethernet connection is unavailible. For example I may be await from computer and the computer may download something. I understand that they are enabled simultaneously, but OS uses only one.
You can activate multiple connections at the same time, e.g. your ethernet and Wi-Fi. Say, both connection provides access to the same network (or the entire internet, in case of the default-route). Then it depends on the route-metric which device is preferred. This is entirely unrelated to autoconnect and autoconnect-priority. By default, ethernet gets a metric of 100, while Wi-Fi devices get a metric of 600 (thus ethernet is preferred). You can overwrite this by setting nmcli connection modify $CONNECTION ipv4.route-metric 99 (you also see the metric with "ip route") However, in your example, you would have the default-route along the ethernet device (which already happens by default as it gets metric 100). But there is no automatism that detects that your ethernet switch becomes defunct and automatically switches the default-route to a different device. You would have to switch manually be activating a different connection (or deactivating the ethernet connection). (btw, if you download something and change the default-route from ethernet to Wi-Fi, your download will abort -- unless your download script is intelligent enough to retry, or you have some special setup, like multipath tcp or what-not).
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).