Updated to 19.04 and NO ETHERNET now

18,187

Solution 1

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:

[ifupdown]
managed=true

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.

Solution 2

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:
*-network
     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).

Solution 3

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
network:
  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)
Share:
18,187

Related videos on Youtube

once_a_NoOb_always_a
Author by

once_a_NoOb_always_a

Updated on September 18, 2022

Comments

  • once_a_NoOb_always_a
    once_a_NoOb_always_a almost 2 years

    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 4.18.0.17 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.

    • FedKad
      FedKad about 5 years
      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?
    • Mario
      Mario over 4 years
      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).
  • once_a_NoOb_always_a
    once_a_NoOb_always_a about 5 years
    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
    once_a_NoOb_always_a about 5 years
    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
    once_a_NoOb_always_a about 5 years
    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
    once_a_NoOb_always_a about 5 years
    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.
  • FedKad
    FedKad about 5 years
    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.
  • FedKad
    FedKad about 5 years
    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.
  • FedKad
    FedKad about 5 years
    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.
  • Andrew
    Andrew about 5 years
    Could you add instructions on how to do that?
  • FedKad
    FedKad about 5 years
    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...
  • Andrew
    Andrew about 5 years
    Could you give instructions on how to do that?
  • Bast1aan
    Bast1aan about 5 years
    Updated with instructions
  • Andrew
    Andrew about 5 years
    Installed r8168-dkms, did not work for me
  • Andrew
    Andrew about 5 years
    Tried this way, it didn't work and the option to connect to a wired network disappeared altogether
  • Bast1aan
    Bast1aan about 5 years
    can you specify how the option disappeared? have you checked if your wired interface actually did or did not get an IP address?
  • Andrew
    Andrew about 5 years
    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.
  • Bast1aan
    Bast1aan about 5 years
    That's correct, because this is meant to remove wired connectivity from NetworkManager. It should now be handled by ifplugd, it should automaticaly connect to wired once the cable is plugged in, and disable when plugged out. You can check this by opening a console and running (non-root) /sbin/ip addr show or /sbin/ifconfig, your wired interface should be shown and should have an IP address when connected.
  • crip659
    crip659 about 5 years
    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
    crip659 about 5 years
    When I was using 16.04, a couple of times had this problem after an update and found 3 or 4 reboots would fix it.
  • FedKad
    FedKad almost 5 years
    The command sudo ethtool --set-eee enp3s0f1 eee off is not supported in my configuration: Cannot get EEE settings: Operation not supported
  • Sufian
    Sufian almost 5 years
    My current solution is to open Settings > Network and toggle off then on the wired connection. If usually needs to be done after I boot in my system, but not the only time. I've added a key binding to run gnome-control-center network (to open the Network tab) for the time being.
  • FedKad
    FedKad almost 5 years
    This does not work me @Sufian :(
  • Sufian
    Sufian almost 5 years
    @FedonKadifeli then how do you make it work? (btw I'm on Debian Buster (stable) with Gnome 3.30.2, kernel 4.19.0-6-amd64)
  • FedKad
    FedKad almost 5 years
    As I explained: During hard boot (power on) ethernet works. It does not work only during soft reboot (Linux reboot).
  • FedKad
    FedKad over 4 years
    This problem seems to have been solved in Ubuntu 19.10.
  • Sufian
    Sufian over 4 years
    @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. :)
  • rüff0
    rüff0 over 4 years
    this works for me on ubuntu18.04 after rebooting.
  • rharriso
    rharriso about 4 years
    This also worked for me after upgrading to 20.04