Public bug reported:
Actually this might be a heisenbug. I've had an issue with this all
morning since network-manager got an update this morning, but just now
*while this bug was being submitted* it decided to correct itself.
What I was getting was, on a machine (Dell XPS 13 9370) with WiFi and a
(Caldigit) Thunderbolt 3 dock with an ethernet port: After the network-
manager update I noticed everything was slower than I was used to, and
in gnome-shell the network icon showing was the WiFi one, not the wired
one.
Looking at the output of route, or route -n for simplicity, I would see
this:
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
So the metric on the default route on enp63s0 had 20,000 mysteriously
added to it, which would obviously make it extremely low-priority. The
system was choosing the wifi connection instead, which isn't that great
in my office, hence observable slowness.
Now, this morning, this seemed to be the sticky situation. It didn't
show any sign of changing, whatever I did, after restarts of network-
manager, undock/redock, reboots, etc. I could change it manually with
ifmetric (and it would work), but that was about it.
I would have reported the bug then, but I had to go out. When I got back
I plugged in and initially saw the same thing again (that's where the
above snippet was pasted from). But *while* the ubuntu-bug network-
manager command was running, I noticed the gnome-shell network icon
switch to wired, checked again, and saw:
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
So now the wifi connection has 20,000 added to it, which may still be
wrong? But I wouldn't otherwise have noticed it because the system is
again *behaving* as expected.
This all seemed to happen after the network-manager upgrade (from
1.12.6-0ubuntu4 to 1.15.2-0ubuntu1) this morning. I can't say if these
metric+20,000 values were present before then, because I didn't have any
cause to go looking at it, it always just worked. Could it be some issue
with how the newer network-manager, or one of its associated packages,
is figuring out the metrics on new connections? Like it's running some
new heuristic to determine which one should really be the preferred? If
it's like it was just now, when it fixed itself after a minute or so,
that's not really a problem, but if it's like it was this morning when
it just seemed to be stuck with the ethernet connection at 20100, it is.
ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: network-manager 1.15.2-0ubuntu1
ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
Uname: Linux 4.18.0-13-generic x86_64
ApportVersion: 2.20.10-0ubuntu19
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Fri Feb 1 13:15:06 2019
IfupdownConfig:
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
InstallationDate: Installed on 2018-09-11 (142 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
IpRoute:
default via 192.168.1.254 dev wlp2s0 proto dhcp metric 600
default via 192.168.1.254 dev enp63s0 proto dhcp metric 20100
169.254.0.0/16 dev wlp2s0 scope link metric 1000
192.168.1.0/24 dev enp63s0 proto kernel scope link src 192.168.1.106 metric
100
192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.101 metric 600
NetworkManager.state:
[main]
NetworkingEnabled=true
WirelessEnabled=true
WWANEnabled=true
RfKill:
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
SourcePackage: network-manager
UpgradeStatus: Upgraded to disco on 2019-01-13 (18 days ago)
nmcli-dev:
DEVICE TYPE STATE IP4-CONNECTIVITY IP6-CONNECTIVITY DBUS-PATH
CONNECTION CON-UUID
CON-PATH
wlp2s0 wifi connected full limited
/org/freedesktop/NetworkManager/Devices/2 Strange Noises
ae544444-3c3d-4714-8bf5-7e56bb7249c6
/org/freedesktop/NetworkManager/ActiveConnection/2
enp63s0 ethernet connected limited limited
/org/freedesktop/NetworkManager/Devices/4 enp63s0
7d394ed8-72c6-4081-9dac-18e320acdafd
/org/freedesktop/NetworkManager/ActiveConnection/3
lo loopback unmanaged unknown unknown
/org/freedesktop/NetworkManager/Devices/1 -- --
--
nmcli-nm:
RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI
WWAN-HW WWAN
running 1.15.2 connected started full enabled enabled
enabled enabled enabled
** Affects: network-manager (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug disco
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1814262
Title:
Wired interface gets impossibly high metric 20100
Status in network-manager package in Ubuntu:
New
Bug description:
Actually this might be a heisenbug. I've had an issue with this all
morning since network-manager got an update this morning, but just now
*while this bug was being submitted* it decided to correct itself.
What I was getting was, on a machine (Dell XPS 13 9370) with WiFi and
a (Caldigit) Thunderbolt 3 dock with an ethernet port: After the
network-manager update I noticed everything was slower than I was used
to, and in gnome-shell the network icon showing was the WiFi one, not
the wired one.
Looking at the output of route, or route -n for simplicity, I would
see this:
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
So the metric on the default route on enp63s0 had 20,000 mysteriously
added to it, which would obviously make it extremely low-priority. The
system was choosing the wifi connection instead, which isn't that
great in my office, hence observable slowness.
Now, this morning, this seemed to be the sticky situation. It didn't
show any sign of changing, whatever I did, after restarts of network-
manager, undock/redock, reboots, etc. I could change it manually with
ifmetric (and it would work), but that was about it.
I would have reported the bug then, but I had to go out. When I got
back I plugged in and initially saw the same thing again (that's where
the above snippet was pasted from). But *while* the ubuntu-bug
network-manager command was running, I noticed the gnome-shell network
icon switch to wired, checked again, and saw:
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
So now the wifi connection has 20,000 added to it, which may still be
wrong? But I wouldn't otherwise have noticed it because the system is
again *behaving* as expected.
This all seemed to happen after the network-manager upgrade (from
1.12.6-0ubuntu4 to 1.15.2-0ubuntu1) this morning. I can't say if these
metric+20,000 values were present before then, because I didn't have
any cause to go looking at it, it always just worked. Could it be some
issue with how the newer network-manager, or one of its associated
packages, is figuring out the metrics on new connections? Like it's
running some new heuristic to determine which one should really be the
preferred? If it's like it was just now, when it fixed itself after a
minute or so, that's not really a problem, but if it's like it was
this morning when it just seemed to be stuck with the ethernet
connection at 20100, it is.
ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: network-manager 1.15.2-0ubuntu1
ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
Uname: Linux 4.18.0-13-generic x86_64
ApportVersion: 2.20.10-0ubuntu19
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Fri Feb 1 13:15:06 2019
IfupdownConfig:
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
InstallationDate: Installed on 2018-09-11 (142 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
IpRoute:
default via 192.168.1.254 dev wlp2s0 proto dhcp metric 600
default via 192.168.1.254 dev enp63s0 proto dhcp metric 20100
169.254.0.0/16 dev wlp2s0 scope link metric 1000
192.168.1.0/24 dev enp63s0 proto kernel scope link src 192.168.1.106 metric
100
192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.101 metric
600
NetworkManager.state:
[main]
NetworkingEnabled=true
WirelessEnabled=true
WWANEnabled=true
RfKill:
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
SourcePackage: network-manager
UpgradeStatus: Upgraded to disco on 2019-01-13 (18 days ago)
nmcli-dev:
DEVICE TYPE STATE IP4-CONNECTIVITY IP6-CONNECTIVITY DBUS-PATH
CONNECTION CON-UUID
CON-PATH
wlp2s0 wifi connected full limited
/org/freedesktop/NetworkManager/Devices/2 Strange Noises
ae544444-3c3d-4714-8bf5-7e56bb7249c6
/org/freedesktop/NetworkManager/ActiveConnection/2
enp63s0 ethernet connected limited limited
/org/freedesktop/NetworkManager/Devices/4 enp63s0
7d394ed8-72c6-4081-9dac-18e320acdafd
/org/freedesktop/NetworkManager/ActiveConnection/3
lo loopback unmanaged unknown unknown
/org/freedesktop/NetworkManager/Devices/1 -- --
--
nmcli-nm:
RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW
WIFI WWAN-HW WWAN
running 1.15.2 connected started full enabled enabled
enabled enabled enabled
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1814262/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
