Network Manager unable to connect to network (Debian 10 / Kernel 4.19)

Question

I switched my whole desktop-setup from windows to GNU/Linux + Debian 10. I am able to run the debian netinstaller and connect the mainboard for internet-software-updates.

But whenever I got the full setup up and running, Debian is not able to connect to the network via ethernet. Immediately after login the interface states, that the network is disconnected. After a motherboard change, I am fairly certain, that this is some kind of a software/driver problem.

My hardware setup consists of:

• Asus ROG Crosshair Hero VI
• Nvidia GTX 670 in PCI1
• Nvidia GTX 970 in PCI2 (aim is to passthrough in to a VM)
• Ryzen 7 2700X
• Samsung EVO SSD with encrypted LVM, no further partitions

This question is similar to https://askubuntu.com/questions/1135412/updated-to-19-04-and-no-ethernet-now, but my setup is different and research on stackexchange etc. brought no help.

Output of systemctl status NetworkManager:

device (enp4s0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')  
device (enp4s0): state change: config -> ip-config (reason 'none', sys-iface-state:'managed')  
dhcp4 (enp4s0): activation: beginning transaction (timeout in 45 seconds)
DHCPrequests  
dhcp4 (enp4s0): dhclient started with pid 1334
device (enp4s0): state change: ip-config -> unavailable (reason 'carrier-changed', sys-iface-state: 'managed')  
dhcp4 (enp4s0): canceled DHCP transaction, DHCP client pid 1334  
dhcp4 (enp4s0): state changed unknown -> done  
manager: NetworkManager state is now DISCONNECTED

Output of lspci | grep Ethernet:

Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)

/etc/network/interfaces remained unchanged, changing it to hotplug or static IP-addresses doesn't help. Same for setting up static network settings in nmcli.

Output of nmcli device show enp4s0:

GENERAL.DEVICE: enp4s0
GENERAL.TYPE: ethernet
GENERAL.HWADDR: 04:92:26:DA:16:CC
GENERAL.MTU: 1500
GENERAL.STATE: 20 (unavailable)

Output of uname -a:

Linux NAMEOFPC 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19) x86_64 GNU/Linux

Output of Dmesg | grep enp4s0:

    1.054338] igb 0000:04:00.0 enp4s0: renamed from eth0
[   56.832109] IPv6: ADDRCONF(NETDEV_UP): enp4s0: link is not ready
[   56.857033] IPv6: ADDRCONF(NETDEV_UP): enp4s0: link is not ready
[   59.608583] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
[   59.608829] IPv6: ADDRCONF(NETDEV_CHANGE): enp4s0: link becomes ready
[   83.708581] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
[  147.966461] IPv6: ADDRCONF(NETDEV_UP): enp4s0: link is not ready
[  320.546500] IPv6: ADDRCONF(NETDEV_UP): enp4s0: link is not ready
[  323.280590] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
[  323.280831] IPv6: ADDRCONF(NETDEV_CHANGE): enp4s0: link becomes ready
[  326.168592] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX

Physically disconnecting is no solution, NetworkManager immediately notifies, that the physical connection is not down again. The only solution seems to be ip link set enp4s0 down followed by ip link set enp4s0 up. It would be ps

I added nonfree repositorys as well - to no avail. The only solution I didn't try was the propietary intel I211 driver. But I don't know if this is the solution, since the mentioned askubuntu-post uses Kernel 5.x and a Realtek network card - with the same problems.

Edit: Furthermore, this problem seems to be seldomly metioned and I assume you would find more posts regarding this problem, if the only solution is to compile a new driver into the kernelspace. Additionally, Intel states, that the IGP-linux driver for the I211 is made for Kernels 2.x and 3.x...

Output of cat /sys/class/net/enp4s0/device/power/control:

"on"

A direct connection to the router enables a network connection immediately. Furthermore, the switch is indeed limited to 100mbps. I didn't have the time to install ethtool, yet. I will update when I had the time to do so.

Are there any solutions to this problem?

Maybe it is the message of NetworkManager "reason 'carrier-changed', sys-iface-state: 'managed'", which can give some hint to the problem? Maybe it is the fact, that encrypted LVMs remain in some kind of hibernating status after shudown? That's what the CLI tells you when shutting down and booting (e.g. resuming from hibernation).

Answer 1

Your integrated Intel NIC most likely supports Energy Efficient Ethernet (EEE): if a link is inactive for a while, it will drop to a lower speed level until there is traffic again. This is mostly important for gigabit links, but according to the messages, the interface is negotiating only a 100Mbps link, so perhaps the other end of the link does not support gigabit speeds and EEE.

Or if the other end should definitely be gigabit-capable, then the fact that only a 100Mbps link is being negotiated indicates that the remote end might be getting confused by rapid switches between 100Mbps and gigabit modes caused by EEE. An unexpected or too slow switch from one mode to another might cause NetworkManager's carrier-changed state.

So you might try switching EEE off:

ethtool --set-eee enp4s0 eee off

Or it might be similar to this bug: what does this command say?

cat /sys/class/net/enp4s0/device/power/control

If it says auto, try this:

echo "on" > /sys/class/net/enp4s0/device/power/control

That tells the kernel to keep the PCIe side of the network interface powered up, instead of possibly powering it down whenever the NIC seems to be not configured for use.

Worst case, it might be a hardware compatibility issue between the NIC in your new motherboard and whatever is at the other end of the network cable. I once had a 8-port DLink 10/100Mbps switch that refused to work with some new gigabit NICs.

Answer 2

I note you have "carrier-changed" disconnections in the log.

I had "carrier-changed" errors, frequently disconnecting my ethernet, and after trying every solution in multiple forums, I finally upgraded the CAT5 cable to a CAT7 cable (10 meter run - cheap on ebay) which cured the problem. Apparently, the old CAT5 cable couldn't handle my ISP's upgraded speeds (Virgin Media, UK). The new CAT7 cable has not only stopped the dropouts, but also now allows the speed to auto-configure from 100Mb/s to 1000Mb/s. Hope that helps anyone looking to fix "carrier-changed" problems.