Hi all,
I have my network connections managed by NetworkManager.
At the office, I usually connect my laptop to the docking station, which gives it a wired network connection. The laptop also automatically connects to the office wifi network.
When I am at the office I need to use to wired connection; this has never been a problem: the wired connection has a higher priority (-100 vs 0 for wifi) in NetworkManager, so even if the laptop automatically connects to the wifi network, all connections go through the wired one.
Well, that was until some time ago. Now I am forced to disable the wifi connection because as soon as it connects it “takes over”.
Moreover, when I try to change the priority of the wired connection, I see that the “Apply” button is not automatically enabled. In fact, even if I change it and click on “OK”, when I reopen the configuration dialog I see the priority has not changed.
On the other hand, the wifi connection priority behaves normally.
Thank you Deano!
Your reply is very appreciated, although I’d still like to know if something has changed in the way NetworkManager handles priority or if it’s a problem/misconfiguration on my part.
ip route
default via 192.168.1.1 dev eth0 proto static metric 100
default via 192.168.9.1 dev wlan0 proto static metric 600
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.49 metric 100
192.168.9.0/24 dev wlan0 proto kernel scope link src 192.168.9.8 metric 600
The ‘autoconnect-priority’ settings only set the order preference for a given connection type AFAIU eg ordering a preferred wireless AP. If you have wired and wireless connections set to auto-connect, both can do so concurrently. It’s the ‘route-metric’ that determines which gateway is preferred (and by default it will be via the wired interface).
Hi Deano,
this is what I get on my laptop (first is with wired only, second is with wifi enabled and connected):
cristiano@xmper8q3 ~]**$** ip route
default via 172.24.252.1 dev enp0s25 proto static metric 20100
172.24.252.0/22 dev enp0s25 proto kernel scope link src 172.24.253.121 metric 100
cristiano@xmper8q3 ~]**$** ip route
default via 10.232.0.1 dev wlp3s0 proto static metric 600
default via 172.24.252.1 dev enp0s25 proto static metric 20100
10.232.0.0/23 dev wlp3s0 proto kernel scope link src 10.232.0.153 metric 600
172.24.252.0/22 dev enp0s25 proto kernel scope link src 172.24.253.121 metric 100
Thank you Deano!! So I was wrong assuming that the priority affected the preferred connection.
There is something wrong in my metric, as you can see in my previous post, but I don’t know where that comes from.
I’ll see if I can locate the problem.
Yesterday I did some test, but even after following your instructions and restarting the connection, I still had that strange 20100 metric on the Default route.
The “nmcli connection show” command correctly showed 100, which was the value I set it to.
Have you ever seen something like this? I don’t get where that 20100 comes from.
No, I’m not sure why NM is behaving like that. However, following a quick search I did find this thread (different topic though) where similar values are evident…
That looks as expected. I’m trying to understand whether this is server-defined or not…I wouldn’t have thought so though. (FWIW, Windows DHCP servers and clients support the default router metric base option, but I’m not aware of any such thing being supported by dhclient/dhcpcd.) What does the lease file look like?
cat /var/lib/dhcp/dhclient.leases
I’m still wondering why the specify ‘route-metric’ value is not get applied to the connection’s default route as expected. Maybe it is a bug. It does work for me using openSUSE Leap 42.3, NM 1.0.12 though.
Looking at other threads on Google (like the one you posted a few messages ago) I am starting to suspect that the problem is not that the wired default route has a 20100 metric, but that the wifi default route should have a 20600 metric instead of 600.
Still don’t understand where those metrics come from… :
Something has clearly changed since a few weeks but don’t know what.
Hmmm…is dhclient even in use? That’s a very old timestamp! Maybe NM is using a different DHCP client. Apparently it has its own internal client that can be used. That can be checked with
cat /etc/NetworkManager/NetworkManager.conf
*If not specified then dhclient is used by default AFAIU.
Yes, it’s definitely something in the internal NM logic involved here. It would be useful for other TW users with wired and wifi connections to chime in with the metric values for comparison.
However, changing the wifi metric to 20600 fixed my problem.
Here are my routes now:
cristiano@xmper8q3 ~]**$** ip route
default via 172.24.252.1 dev enp0s25 proto static metric 20100
default via 10.232.0.1 dev wlp3s0 proto static metric 20600
10.232.0.0/23 dev wlp3s0 proto kernel scope link src 10.232.0.153 metric 20600
172.24.252.0/22 dev enp0s25 proto kernel scope link src 172.24.253.121 metric 100
The problem is being caused by the rp_filter that tries to work out the best route based on connectivity. If you work for exact does not have outside world access, or that access is a extra step, this can cause exactly the problems you see.
The solution tell the kernal to turn off (0) or loosen (1) the rp_filter for your wired connection.
To see the seetinsg for your networks use…
grep . /proc/sys/net/ipv4/conf/*/rp_filter
to ‘loosen’ say the enp0x25 device as your route shows…
now when you connect it should not add the 20000 value to that device due to connectivity test failure (it uses the libcurl library for that test, though I don’t know the details)
