I use static IP for my wired connection controlled via Network Manager.

ip link show enp4s0

2: enp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq state DOWN mode DEFAULT group default qlen 1000

NO-CARRIER would seem to indicate a driver issue as I'm posting this on the same PC by selecting the prior kernel in grub. NetworkManager.service and avahi-daemon.service are both LOADED and ACTIVE.

But NetworkManager not happy as shown...

NetworkManager[1103]: <info>  [1555719488.0396] device (enp4s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
NetworkManager[1103]: <info>  [1555719488.0402] manager: NetworkManager state is now CONNECTED_LOCAL
NetworkManager[1103]: <info>  [1555719488.9594] manager: NetworkManager state is now CONNECTED_SITE
NetworkManager[1103]: <info>  [1555719488.9595] policy: set 'LaN' (enp4s0) as default for IPv4 routing and DNS
NetworkManager[1103]: <info>  [1555719488.9603] device (enp4s0): Activation: successful, device activated.
NetworkManager[1103]: <info>  [1555719488.9609] manager: NetworkManager state is now CONNECTED_GLOBAL
NetworkManager[1103]: <info>  [1555719488.9616] manager: startup complete
NetworkManager[1103]: <info>  [1555719495.0373] device (enp4s0): state change: activated -> unavailable (reason 'carrier-changed', sys-iface-state: 'managed')
NetworkManager[1103]: <info>  [1555719495.0583] manager: NetworkManager state is now DISCONNECTED
NetworkManager[1103]: <info>  [1555719505.6899] agent-manager: req[0x55c9724642a0, :1.63/org.freedesktop.nm-applet/1000]: agent registered

Could it be the wrong phy driver selected or Network Manager bug?

"ip link set enp4s0 up" doesn't help.

  • After a few weeks test, I am now confident that: (1) the problem does NOT occur after a cold boot (power cycle) (2) it always occurs after a soft boot (Linux reboot) (3) even after a soft boot, when I first enter BIOS setup, exit with no changes and allow Ubuntu to boot normally, the problem does NOT occur. Can you verify this? – FedonKadifeli May 17 '19 at 11:21
  • For me, a reboot works to at least get rid of the NO-CARRIER status. I'm on Ubuntu 19.10 with a USB ethernet adapter (Dell DA200, with Realtek RTL8153 device). – Mario Jan 10 '20 at 13:25

I had a similar issue (no wired ethernet after upgrade to 19.10). I lived with that for a while and just used ifup in .bashrc. But when I took a deeper look into this problem, I got directed by Google to this page.

However, none of solutions above solved my problem. Apparently, I found the solution when tried to change from ifup to netplan. At that moment, I realized that there is a parameter in NetworkManager config (/etc/NetworkManager/NetworkManager.conf) that allows the NetworkManager to control interfaces. I had managed=false there.

Simply changing it to:


creating an empty file:

sudo touch /etc/NetworkManager/conf.d/10-globally-managed-devices.conf

and restarting NetworkManager:

sudo systemctl restart NetworkManager 

solved my issues.

  • this works for me on ubuntu18.04 after rebooting. – rüff0 Mar 9 '20 at 21:46
  • This also worked for me after upgrading to 20.04 – rharriso Apr 28 '20 at 4:02

UPDATE: After upgrading my notebook from Ubuntu 19.04 to Ubuntu 19.10, I no longer have this problem. I did not have it in version 18.10 either. So, it seems that this is only present in version 19.04.

I am just posting my observations here as an answer. I hope I will eventually come to a solution, so I will be able to update this answer appropriately.

I am having the exact problem:

During power on this problem does not occur. But, it occurs always after an OS restart (soft reboot).

So far, the only solution is this: Unplug the ethernet cable; boot your machine; plug back the cable after boot is complete. Ethernet connection will never work if the network cable is plugged during boot!

I followed the suggestions in https://ubuntu-mate.community/t/19-04-ethernet-wired-connection-refuses-to-connect-when-plugged-in-before-boot/19333/8 and as the original poster there, I had no improvement. Here are my observations and I am requesting you (once_a_NoOb_always_a) to verify them:

  1. This problem started after the upgrade from Ubuntu 18.10 to 19.04. Initially (during the first reboot after the upgrade) the problem did not occur. But, later (after the second reboot) it started to occur persistently.

  2. If you start the machine with the ethernet cable disconnected and connect it after it boots, the problem does not occur.

  3. In any case, the link level connection is successful (even after you disconnect and reconnect the cable or after your do ip link set enp3s0f1 down and ip link set enp3s0f1 up). I can see from my router that the relevant ethernet port is up and packets travel in both directions. However, there is something very strange happening: I am using static IP addresses for my Wired and Wireless connection in my Ubuntu box; these end with 14 and 15 respectively. When I enable the ethernet (wired) interface my router sees the same IP address ending with 14 in both of the Ubuntu box interfaces.

My provisional deduction is that the network stack somehow mixes the MAC addresses of the two interfaces. (Please note, that normally my Wireless interface is hardware-disabled when I boot and use my computer; normally I only used the Wired connection. However, even in such a scenario my upgraded Ubuntu box does not connect to the ethernet network. To only solution seems to physically disconnect the ethernet cable while booting and connecting it after the boot.)

  1. I deleted the Wired (Ethernet) connection completely using nm-connection-editor (with root user) and then re-created the connection, this time using DHCP instead of a static IP address. When I try to bring the interface up, my router does give an IP address to my interface (enp3s0f1), but Ubuntu does not show this IP. Hardware info for the ethernet interface is like this:
     description: Ethernet interface
     product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
     vendor: Realtek Semiconductor Co., Ltd.
     physical id: 0.1
     bus info: pci@0000:03:00.1
     logical name: enp3s0f1
     version: 12
     serial: b0:25:aa:2d:91:22
     size: 1Gbit/s
     capacity: 1Gbit/s
     width: 64 bits
     clock: 33MHz
     capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
     configuration: autonegotiation=on broadcast=yes driver=r8169 duplex=full firmware=rtl8411-2_0.0.1 07/08/13 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
     resources: irq:18 ioport:3000(size=256) memory:a5c14000-a5c14fff memory:a5c10000-a5c13fff

It seems to me that the new kernel 5.0.0-13 has some buggy software for this card (RTL8411B) :(

@drblah : your suggestion did not work for me. The netplan commands you mentioned have no effect and the /etc/netplan/01-network-manager-all.yaml file is not updated (file date stays in 18-Oct-2018 with the same contents).

  • Tried the cable disconnect on boot trick, it briefly said it was connected after initially connecting the cable but without warning it dropped back to no-carrier. – once_a_NoOb_always_a Apr 22 '19 at 22:32
  • Also as I suspected you also have an Realtek nic using the same r8169 driver. So I suspect the problem is with the driver in the kernel somehow being incompatible with NetworkManager. looking at the kernel's config file in /boot shows CONFIG_NET_VENDOR_REALTEK=y. So it does seem to load it. – once_a_NoOb_always_a Apr 22 '19 at 22:40
  • Yes. My config file has also CONFIG_NET_VENDOR_REALTEK=y line. However, the "cable disconnect on boot" trick works always and reliably. I think, during startup the driver does some wrong initializations when the cable is connected (physical network is available). When it is not connected during boot time, but connected later, maybe a separate and different code runs to do the initialization, which is always successful. – FedonKadifeli Apr 23 '19 at 9:21
  • I am having same problem, but one downside of this fix is that computer connectors usually don't last long if being plug in/out often. Might be okay if only needs to be done once every few weeks, but daily use will probably wear/break connector in time. Hope we can find better fix. – crip659 May 29 '19 at 11:00
  • 2
    @FedonKadifeli good for both of us then. I noticed that my problem is also gone somewhere during last 2 weeks. I no longer need to toggle off then on my wired connection everytime I boot again. It may have been fixed with the kernel updates. :) – Sufian Nov 16 '19 at 7:53

I ran into the same issue as you. The workaround I found was to make netplan re-generate the network configuration:

sudo netplan generate
sudo netplan apply

After running the two commands you should be able to configure the network with your usual configuration tools.

By default, netplan will have a configuration file called: /etc/netplan/01-network-manager-all.yaml with the following contents:

# Let NetworkManager manage all devices on this system
  version: 2
  renderer: NetworkManager

This will simply tell the system to let all interfaces be controlled by network manager. I don't know exactly why this worked for me, because netplan was already supposed to be managing the network interface.

For reference the output of lspci for my ethernet controller is:

$ lspci | grep -i ether
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
  • 1
    Didn't work for me either, and my file maintains it's 2017 date.Yaml files are scripts commonly used by the likes of Ansible, so it must be writing the netplan somewhere else. – once_a_NoOb_always_a Apr 22 '19 at 22:44
  • As I had the foresight to create a backup using timeshift before I upgraded I was able to go back to 18.10. The nic wasn't the only problem with the update there were several others including Virtualbox not loading vm's likely because no nic detected. I did back up the 1904 build so I can do more testing if needed but I think I will wait to try updating again until they perhaps release a 19.04.1. – once_a_NoOb_always_a Apr 22 '19 at 22:51
  • When I find time, I will try to boot from USB in with live 19.04 image and test to see if the same problem occurs during a clean 19.04 startup. – FedonKadifeli Apr 23 '19 at 9:24
  • I am sorry to say that I was not able to boot and test from USB live 19.04 (I had no such problem previously with 18.10). The system hangs after the boot. – FedonKadifeli Apr 24 '19 at 18:23

Solved it for me by installing dkms for driver for r8168. True, under kernel 4.18 the NIC operated under r8169 just fine, but not under the "improved" version of kernel 5.0 used with kubuntu 19.04.

  • 1
    Could you add instructions on how to do that? – Andrew May 2 '19 at 17:49
  • I have the following ethtool output for my ethernet interface. # ethtool -i enp3s0f1 driver: r8169 version: firmware-version: rtl8411-2_0.0.1 07/08/13 expansion-rom-version: bus-info: 0000:03:00.1 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: yes supports-priv-flags: no Does this mean that the driver you specified is active? Lately I do no seem to have this problem. However, I do not remember, doing any specific for it... – FedonKadifeli May 4 '19 at 10:50
  • Installed r8168-dkms, did not work for me – Andrew May 6 '19 at 0:04

Same bug here it seems. The problem is I think caused by NetworkManager that performs an incorrect dhclient procedure, and triggering IP conflicts in the switch of my network, causing the connection be dead for about 30 minutes. See also this bug: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1793763

UPDATE: To work arround this problem, you can use ifplugd together with ifupdown to handle ethernet connections, while still using NetworkManager for the wireless connections. To do this:

Install ifupdown and resolvconf:

apt install ifupdown resolvconf

disable systemd-resolved

systemctl stop systemd-resolved
systemctl disable systemd-resolved.service

edit /etc/NetworkManager/NetworkManager.conf to leave ifupdown devices alone, and use resolvconf to update /etc/resolv.conf, and use plain DNS servers from the dhcp server instead of systemd-resolved service.

# don't manage devices configured in /etc/network/interfaces
# pass nameserver dhcp config to resolvconf
# use plain nameservers directly from DHCP server instead of intermediate resolved


Next add following lines to /etc/network/interfaces to define the ethernet device (in my case enp0s25)

iface enp0s25 inet dhcp
iface enp0s25 inet6 auto

Make sure there are no auto enp0s25 lines in the file, because ifup should not be executed automatically on boot, but by ifplugd when plugging in an ethernet connection.

So next install ifplugd and configure it so the enp0s25 device is being listend on for correct connecting/deconnecting triggers

apt install ifplugd

Also, make the file /etc/dhcp/dhclient-enter-hooks.d/resolved empty, because else resolvconf will never work from ifupdown:

echo "" > /etc/dhcp/dhclient-enter-hooks.d/resolved

also don't remove this file or it will be re-installed by next system update.

Finally, start and enable ifplugd, restart NetworkManager for updated configuration.

systemctl restart NetworkManager
systemctl enable ifplugd
systemctl start ifplugd

and/or reboot to check if everything's set up correctly.

Disclaimer 1: I haven't replayed this script on a fresh ubuntu install to verify if it is completely correct (however I've checked bash_history ;). Please reply if something doesn't work.
Disclaimer 2 this works for Ubuntu LTS 18.04
Disclaimer 3: Maybe this can also work with systemd-resolved or even DNSMasq or unbound but I don't know how exactly and I personally don't want it.

  • 1
    Could you give instructions on how to do that? – Andrew May 4 '19 at 21:55
  • Updated with instructions – Bast1aan May 5 '19 at 16:52
  • Tried this way, it didn't work and the option to connect to a wired network disappeared altogether – Andrew May 6 '19 at 0:05
  • can you specify how the option disappeared? have you checked if your wired interface actually did or did not get an IP address? – Bast1aan May 6 '19 at 8:44
  • When you go to the GUI options for the wired connection, above the place where it says "VPN" there is now nothing there. Also at the top right of the screen in the popup there was no mention of anything to do with the Wired connection like usual. It probably didn't get an IP address as I couldn't connect to the internet. This is all on 19.04 btw, like the question asks. – Andrew May 6 '19 at 18:32

I had the same problem occurring on Debian Buster with a wildly different hardware.

As Tomcat pointed out, NetworkManager tried to negotiate a 100mpbs connection but "timed out" and took the connection into power saving.

Try using ethtool --set-eee enpXsX eee off to turn off Energy Efficient Ethernet (EEE).

  • The command sudo ethtool --set-eee enp3s0f1 eee off is not supported in my configuration: Cannot get EEE settings: Operation not supported – FedonKadifeli Jul 30 '19 at 18:57

I have r8169 Ubuntu 19.10 and do not see r8169-dkms on repo

So I have solved by workaround: $ sudo systemctl edit --full rc-local

this enable rc.local Compatibility: $ sudo systemctl status rc-local

rc-local.service - /etc/rc.local Compatibility Loaded: loaded (/etc/systemd/system/rc-local.service; static; vendor preset: enabled) Drop-In: /lib/systemd/system/rc-local.service.d └─debian.conf Active: inactive (dead) Docs: man:systemd-rc-local-generator(8)

Then I create a /etc/rc.local (as root using sudo)

# rc.local
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
# In order to enable or disable this script just change the execution
# bits.
# By default this script does nothing.
sleep 55 && sudo systemctl restart network-manager.service
exit 0

This script run after network.target but is too early so I add the sleep 55: my system start up in 2 min and this script is not blocking ...

The restart make driver work.

do this:
$ sudo chmod 775 /etc/rc.local

Waiting r8169 work on ubuntu 19.10.

I hope that this help.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.