GNOME Bugzilla – Bug 797425
Wired connection stops working on resume from suspend (plasma-nm applet shows no connection)
Last modified: 2019-04-24 18:26:23 UTC
Created attachment 374195 [details] screenshot Bug was already reported in KDE tracker https://bugs.kde.org/show_bug.cgi?id=404345 Jan Grulich said there is some bug with networkmanager: "From the log it looks like a NM issue, your wired device goes into UNMANAGED state and later on into UNAVAILABLE. Please report this issue to NetworkManager." STEPS TO REPRODUCE 1. start KDE Plasma 2. connect to a wired connection 3. suspend and resume your system OBSERVED RESULT plasma notification indicates connection failure, plasma-nm applet shows no connection despite the wired connection is listed in plasma-nm editor and network manager service is running. See the screenshot. Wired connection only works again after reboot, restart plasma does not help. EXPECTED RESULT wired connection works SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.15.0 KDE Frameworks Version: 5.55.0 Qt Version: 5.12.1 Kernel Version: 4.20.7-arch1-1-ARCH
please attach a logfile with level=TRACE. see the hints at https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 Thanks!
Created attachment 374196 [details] nm log
bug persists on Arch Linux after update to nm 1.16
Bug persists on Arch Linux after update to nm 1.18.
in the attached log, you see that the device stays in state "unavailable". As you probably would also see in `nmcli device` output and `nmcli -f all device show enp4s0`. The reason why the device is "unavailable" is because it has no carrier (cable not plugged in). You see that for example here: [1550155921.9009] platform: signal: link changed: 2: enp4s0 <UP;broadcast,multicast,up> (it's "UP" but not "LOWER_UP"). You should see the same in `ip link` output. The attached log contains only a short part, but presuming that the relevant portion is there: - ensure the cable is plugged in :) - looks like a driver/firmware issue. that gives `ip -d link` when this occurs?
The cable is always plugged in. Just reboot the computer is enough to make the connection work again. Here is the output of 'ip -d link' 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 minmtu 0 maxmtu 0 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 2: enp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000 link/ether fc:aa:14:fc:4b:1b brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 60 maxmtu 9200 addrgenmode none numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
> 2: enp4s0: <NO-CARRIER, This is a driver/firmware/kernel issue. There is the "ignore-carrier" setting in NetworkManager.conf. But that's not gonna help, because without carrier you cannot do DHCP. I don't think NetworkManager can do anything about this.
Humm... I tested both r8168 and r8169 (kernel) drivers with both 5.0.9 and 4.19.36 kernels and the problem persists. Can it be some problem with my router?
It could be. The switch may disable the port. For example, it may do so if it detects a routing loop or some forbidden traffic. But in this case, that seems *not* the likely issue. I don't know.
I just solved the problem by resetting the BIOS settings on my motherboard. I think that was some problem related to power management settings. Thank you very much for your interest on this issue Thomas. Have a nice day.
Oh great. I am closing this bug. Please reopen if something's to add. Thank you!