network-manager 1.15.2 assigning route metric values with 20000 added to them
Originally submitted to Ubuntu bugs.launchpad, as I'm on Ubuntu 19.04. The maintainer there asked me to report it upstream; I'm guessing they don't do anything significant downstream to it. That bug report is here: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1814262
This is on a Dell XPS 13 running Ubuntu 19.04, often connected to a Caldigit TB3 dock to provide a wired Gigabit ethernet connection. I understand it's all pre-release versions and I'm not upset or offended there's a problem ;-) just that pre-release is presumably the best time to report bugs... :-)
On Friday last I upgraded from the previous network-manager 1.12.6 and immediately noticed that when my system was docked the network seemed very slow, and contrary to before, the network manager continued to show the wireless connection's icon instead of the wired connection. When I looked at the output of route -n
, I got:
rachel@rainbow:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 600 0 0 wlp2s0
0.0.0.0 192.168.1.254 0.0.0.0 UG 20100 0 0 enp63s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlp2s0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp63s0
192.168.1.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp2s0
ie: the wired connection has a metric of 20100, which is 20000 larger than one would expect. Unsurprisingly given this, the system thinks the wireless connection is better, and continues to give it priority. In fact, during this time it seems to me the connection I get is actually worse than I usually get through wireless, although by definition I rarely use wireless in the specific room with the TB3 dock.
I first noticed this immediately after the upgrade on Friday morning, but by the afternoon it appeared to have resolved itself. What I saw then was that the same thing happened, but after a few seconds it corrected itself and set the wired connection's metric back down to 100, and the wireless connection's metric up to 20600 - again, the normal value plus 20000.
Then I didn't use it over the weekend. Today it's been consistently sticking to the behaviour I saw on Friday: The wired connection's metric being stuck at 20100.
I can override it by using, eg:
rachel@rainbow:~$ sudo ifmetric enp63s0 100
rachel@rainbow:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 100 0 0 enp63s0
0.0.0.0 192.168.1.254 0.0.0.0 UG 20600 0 0 wlp2s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlp2s0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp63s0
192.168.1.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp2s0
Then everything works fine (fast networking is restored, the wired network shows on the network manager, etc.) for the remainder of the session. ie: nothing tries to set it back again. And there was no apparent obstruction or failure of the wired networking interface itself.
But I do note that, after issuing that ifmetric command, again, the wifi connection's metric is set to 20600, similar to what it did that one time it decided to prefer the wired connection itself.
Twenty thousand doesn't seem like a random number to be added to a metric. It looks like a deliberate act by something to deprioritise that route with extreme prejudice, and it apparently started right after the upgrade of network-manager. I'm guessing this is the result of some NetworkManager heuristic to try to determine which route actually is the best? And that's getting it wrong in my case? That's certainly what it looked like that one time it corrected itself, like it had enabled wired, but there was a delay while it was testing it before committing to making it the preferred route, but it only did that the once.