No network via ethernet after resume from suspend

Hi, everyone!

After installing Ubuntu Mate 16.04, I’ve faced the following problem.
When resuming from suspend, there is no connection to my router 192.168.1.1 and the internet via ethernet. Specifically, the network manager shows that “Wired connection 1” is connected, but I have no internet, see the ping results:
$ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. From 192.168.1.107 icmp_seq=1 Destination Host Unreachable From 192.168.1.107 icmp_seq=2 Destination Host Unreachable From 192.168.1.107 icmp_seq=3 Destination Host Unreachable From 192.168.1.107 icmp_seq=4 Destination Host Unreachable From 192.168.1.107 icmp_seq=5 Destination Host Unreachable From 192.168.1.107 icmp_seq=6 Destination Host Unreachable ^C --- 192.168.1.1 ping statistics --- 7 packets transmitted, 0 received, +6 errors, 100% packet loss, time 6031ms pipe 3

Then I tried restart the network manager as advised in that post:
sudo systemctl restart NetworkManager
and the other options in the links from it:
sudo systemctl restart NetworkManager.service sudo service networking restart sudo service network-manager restart sudo /etc/init.d/networking restart sudo /etc/init.d/network-manager restart sudo systemctl restart networking sudo systemctl restart network-manager
No one helps.

Then I compared “lshw -c network” and “ifconfig -a” before and after the suspend. The results were identical and it looks like that all right, but I have no internet.
$ sudo lshw -c network *-network DISABLED description: Wireless interface product: Centrino Wireless-N 2230 vendor: Intel Corporation physical id: 0 bus info: pci@0000:01:00.0 logical name: wlp1s0 version: c4 serial: 68:5d:43:e7:53:15 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless configuration: broadcast=yes driver=iwlwifi driverversion=4.4.0-31-generic firmware=18.168.6.1 latency=0 link=no multicast=yes wireless=IEEE 802.11bgn resources: irq:30 memory:d0500000-d0501fff *-network description: Ethernet interface product: RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller vendor: Realtek Semiconductor Co., Ltd. physical id: 0 bus info: pci@0000:02:00.0 logical name: enp2s0 version: 05 serial: 5c:f9:dd:45:01:5e size: 100Mbit/s capacity: 100Mbit/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 autonegotiation configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full firmware=rtl_nic/rtl8105e-1.fw ip=192.168.1.107 latency=0 link=yes multicast=yes port=MII speed=100Mbit/s resources: irq:26 ioport:2000(size=256) memory:d0404000-d0404fff memory:d0400000-d0403fff

$ ifconfig -a enp2s0 Link encap:Ethernet HWaddr 5c:f9:dd:45:01:5e inet addr:192.168.1.107 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::8676:d828:6d10:175d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6774 errors:0 dropped:0 overruns:0 frame:0 TX packets:6196 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4777353 (4.7 MB) TX bytes:1005656 (1.0 MB)

lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:1230 errors:0 dropped:0 overruns:0 frame:0 TX packets:1230 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:117631 (117.6 KB) TX bytes:117631 (117.6 KB)

wlp1s0 Link encap:Ethernet HWaddr 68:5d:43:e7:53:15 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

I am completely puzzled where I would search for the solution.
Please help!


UPD: The script restoring the connection you can find in post #18.

Hi
Can you please provide the output of:

route -n

when the bug is occuring

Also try:

sudo ifdown eth0
sudo ifup eth0

Is it normal that your interfaces are not using predictable interface names?
Is this a fresh install of 16.04?

And for the sake of completeness (because someone will ask if I don’t): is your system fully up to date?

I’ve seen something similar happen on a machine a while back but there’s no bug report anywhere.

Cheers

1 Like

Thanks for your reply!

Is it normal that your interfaces are not using predictable interface names?

Yes, I changed the names by adding "net.ifnames=0" to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub. It was a part of my digging the problem. Now I’ve returned to the default names and edited the previous post (now interfaces is enp2s0 and wlp1s0). The problem is in the both cases.

Can you please provide the output of: route -n

The output is identical before and after suspend:
$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 enp2s0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp2s0 192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp2s0

Is this a fresh install of 16.04?
And for the sake of completeness (because someone will ask if I don’t): is your system fully up to date?

Yes and yes. I installed Ubuntu mate 16.04 approximately in June and upgraded it regularly. And of course, I’ve upgraded it after discovering the problem.

Also try:
sudo ifdown eth0
sudo ifup eth0

The output is identical before and after suspend:
$ sudo ifdown enp2s0 Unknown interface enp2s0 $ sudo ifup enp2s0 Unknown interface enp2s0

Thank you in advance!

I’m not optimistic. I had no luck fixing that problem before and I don’t even know against which package one should file a bug report for something like that. Linux? Systemd? network-manager?

Can you also provide the output of:

sudo iptables -L

When the bug is happening?

Can you also provide the output of: sudo iptables -L

The output is identical before and after suspend:
$ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination

Chain FORWARD (policy ACCEPT) target prot opt source destination

Chain OUTPUT (policy ACCEPT) target prot opt source destination

When the bug is happening?

The bug is happening after each suspend.

Additional information (maybe useful):
The bug is happening for the ethernet connection. After resume from suspend I can use the wireless.

If you change the kernel do you have the same problem?

@APolihron
Hi!

If you change the kernel do you have the same problem?

Now I have Installed (after upgrade) 4.4.0-21, 4.4.0-24, and 4.4.0-31. All these versions have the problem.
Maybe I should prefer another version?


@ouroumov

UPD: Today I’ve tested the hibernate and the bug was not reproduced. Then I edit my previous posts:

The bug is happening after each suspend.

Try to reload the driver next time the bug is happening:

sudo modprobe r8169

I think you should start considering filing a bug report on launchpad, I’d just like to know against what package. :/

HI @stasap,

firstly I recommend not using suspend as it has been a major thorn in Ubuntu’s side for a long time now!, simply log out if you want privacy which is what I do!.

Secondly, try changing your software sources download location and updating again using a different download server!:

This terminal command (Ctrl + Alt + t) might make it work again?:

sudo restart network-manager

See also( a tad old but should still work?):

Yes go to the last version of 4.6.x or 4.7

Hi @wolfman
Have to disagree with you here: suspend is a legitimate feature of any decent operating system.
@stasap should be able to use it if only because of the power savings.
Suspend instead of logout :arrow_right: save the planet.

@ouroumov @wolfman

Indeed, I use suspend on the laptop because of the power savings, and restarting due to the disconnect is very annoying.

@wolfman

sudo restart network-manager

I’ve done it, see previous posts.

@APolihron

Tested 4.6.5 and 4.7.0. The problem persists. Alas!

Did you try that?
I’ve seen a very similar thing happen just yesterday on a new machine running Ubuntu 16.04 LTS 64Bits.
The modprobe didn’t work but the problem was even nastier: it wasn’t working at all even after a fresh boot, with same “Destination Host Unreachable”

The card in question used the same driver (specs gathered from lshw):

RTL8111/8168/84
driver: r8169 / Version: 2.3LK-NAPI
firmware: rtl8168e-3_0.0.4

Sorry, just overlooked your earlier post.
Yes, I did. It didn’t help.

Now, I doubt I’ll find enough time to do that. Honestly, I’ve never before reported bugs at all.
But I’m concerned with fixing the problem, so please let me know, if it is something that I can do.

Hi,

try changing your software sources download location to a different location and then run the following terminal command (Ctrl + Alt + t):

sudo apt-get update && sudo apt-get dist-upgrade -f

See also:

Found this:

https://bugzilla.redhat.com/show_bug.cgi?id=1312006

Last comment is interesting, can you check if r8168 driver is loaded?

lsmod | grep r8168[quote=“stasap, post:14, topic:7909”]
sudo modprobe r8169
Did you try that?

Sorry, just overlooked your earlier post. Yes, I did. It didn’t help.
[/quote]

I think I made a mistake there, assumed it would reload when it did not.
Try:

sudo modprobe -r r8169
sudo modprobe r8169

4 Likes

Hi @ouroumov!

Your solution works!!! Thank you very much!

It appears that r8169 driver is loaded before and after suspend:
$ lsmod | grep r8169 r8169 81920 0 mii 16384 1 r8169

When after suspend I do[quote=“ouroumov, post:16, topic:7909”]
sudo modprobe -r r8169
sudo modprobe r8169
[/quote]
network reconnects!

Thank you again!
The problem solved!

2 Likes

Maybe someone with the same problem will be interested:

To automatically reconnecting after suspend, I’ve added the script that runs each resume and restores connection (based on this post).

  1. Go to
    cd /lib/systemd/system-sleep/
    and create the script file
    sudo pluma restore_connection
    with the following content

#!/bin/sh case $1/$2 in post/*) modprobe -r r8169 modprobe r8169 ;; esac

  1. Make the script executable
    sudo chmod a+x restore_connection

  2. Now after suspend the connection should be restored.

Thanks to everyone and particularly to @ouroumov !

5 Likes

Outstanding job @ouroumov and @stasap

However, your skills might be of further help.
I can confirm that doing

sudo modprobe -r drivername
sudo modprobe drivername

actually WORKS 100% of time.
In my case tho, the script you provided, with the appropriate driver name (asix), isn’t actually working.
Before when resuming from suspension i had to pull out and back in the usb adpater, right now I can put the command in terminal, which is, however faster and more comfortable than stressing the usb port.
Any suggestions how to workaround this little hiccup?
Thank you in advance!
:slight_smile: