No network after resuming from Hibernate

indianahorst · 2018-11-02 01:43:05

Hello,

I'm using netctl as network manager. I have configured a very simple DHCP config:

/etc/netctl/mydhcp

Description='A basic dhcp ethernet connection'
Interface=enp2s0
Connection=ethernet
IP=dhcp
DHCPClient=dhcpcd

This is directly copied from the example config files.

After starting the system, the netctl service runs without problems.

But: After hibernating and resuming there is no network access. This is the output of ip a after resuming:

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether d0:50:99:4a:9c:61 brd ff:ff:ff:ff:ff:ff

The following is the output of netctl status mydhcp after resuming:

 netctl@mydhcp.service - A basic dhcp ethernet connection
   Loaded: loaded (/usr/lib/systemd/system/netctl@.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/netctl@mydhcp.service.d
           └─profile.conf
   Active: active (exited) since Fri 2018-11-02 02:14:44 CET; 11min ago
     Docs: man:netctl.profile(5)
 Main PID: 1669 (code=exited, status=0/SUCCESS)
   Status: "online"
    Tasks: 1 (limit: 4248)
   Memory: 2.2M
   CGroup: /system.slice/system-netctl.slice/netctl@mydhcp.service
           └─1730 dhcpcd -4 -q -t 30 -L enp2s0

Nov 02 02:18:59 eos dhcpcd[1730]: enp2s0: carrier acquired
Nov 02 02:18:59 eos dhcpcd[1730]: enp2s0: IAID 99:4a:9c:61
Nov 02 02:18:59 eos dhcpcd[1730]: enp2s0: rebinding lease of 192.168.1.8
Nov 02 02:18:59 eos dhcpcd[1730]: enp2s0: probing address 192.168.1.8/24
Nov 02 02:19:04 eos dhcpcd[1730]: enp2s0: leased 192.168.1.8 for 864000 seconds
Nov 02 02:19:04 eos dhcpcd[1730]: enp2s0: adding route to 192.168.1.0/24
Nov 02 02:19:04 eos dhcpcd[1730]: enp2s0: adding default route via 192.168.1.1
Nov 02 02:24:55 eos dhcpcd[1730]: enp2s0: carrier lost
Nov 02 02:24:55 eos dhcpcd[1730]: enp2s0: deleting route to 192.168.1.0/24
Nov 02 02:24:55 eos dhcpcd[1730]: enp2s0: deleting default route via 192.168.1.1

I have already tried the static version in netctl, but I get exactly the same results.

After a manual netctl restart mydhcp the network is back, but... serious? It's 2018 and I have to plug in a keyboard on my HTPC to open a terminal?!

So, please tell me: how can such a buggy software ever be released?

And how do I get the network back after resuming from hibernation without interaction?

Last edited by indianahorst (2018-11-03 00:26:07)

ewaller · 2018-11-02 02:13:06

indianahorst wrote:

So, please tell me: how can such a buggy software ever be released?

Moving to Topics Going Nowhere.

ewaller · 2018-11-02 02:14:03

What is the output of find /etc/systemd/system?

seth · 2018-11-02 07:29:22

Please post a full journal. You're loosing the carrier, ie. this is not "buggy software" but buggy hardware, buggy UEFI, buggy firmware, a buggy kernel module - or because there's a second OS in hibernation… how many parallel windows versions do you have?

indianahorst · 2018-11-03 00:37:51

I have to apologize for my harsh words, I was very frustrated after hours of testing.

@ewaller: could you please transfer this thread back to the main forums?

I have tested different network managers (systemd-networkd and dhcpd) and got the same results (no carrier and no network) after resuming.

seth wrote:

Please post a full journal. You're loosing the carrier, ie. this is not "buggy software" but buggy hardware, buggy UEFI, buggy firmware, a buggy kernel module - or because there's a second OS in hibernation… how many parallel windows versions do you have?

There are no windows installations. There is only Arch Linux installed.
I assume that the network driver alx is the problem.

As in https://wiki.archlinux.org/index.php/Po … vice_files I tried to create a resume service file:

$ cat /etc/systemd/system/root-resume.service 
[Unit]
Description=Local system resume actions
After=suspend.target 
After=sleep.target 
After=hibernate.target
After=hybrid-sleep.target


[Service]
Type=oneshot
ExecStart=/usr/bin/netctl restart mydhcp

[Install]
WantedBy=multi-user.target 
WantedBy=suspend.target

The command

netctl restart mydhcp

works when executed manually in a terminal.

The resume file works when I execute it manually (systemctl start root-resume.service). But it isn't executed automatically after resuming from hibernation.

What am I doing wrong?

Last edited by indianahorst (2018-11-04 00:17:18)

ewaller · 2018-11-03 03:54:18

indianahorst wrote:

I have to apologize for my harsh words, I was very frustrated after hours of testing.
@ewaller: could you please transfer this thread back to the main forums?

Moved to Networking, Server and Protection.

seth · 2018-11-03 08:26:12

Did you enable the services?
(Personally I prefer https://wiki.archlinux.org/index.php/Po … tem-sleep)
Also this might be a timing issue (ie. the restart direct after the resume is too early and the interface has not properly initialized) - adding some debug out to figure whether the service/script has been invoked as well as your journal tail might be beneficial.

You should however not ignore the lost carrier (workarounds are good, but workarounds)
Did you try the lts kernel behavior?

tbg · 2018-11-04 10:32:20

What you need to do is write 2 different services.

Usually this procedure will solve this issue:

Before suspend service.

stop NetworkManager

put your adapter down

rmmod your network driver

After resume service.

modprobe your network driver

raise your adapter

start NetworkManager

Adding a sleep command before, and between each operation at resume is also sometimes helpful.

That usually fixes this problem.

Last edited by tbg (2018-11-04 10:35:12)

stueja · 2019-01-14 06:10:22

Indianahorst, did any of the provided hints work for you?

Pitmairen · 2019-01-21 16:43:02

I have the same problem. The network has been working without problems for years. But after I updated a 1-2 weeks ago the network does not work when resuming after suspend. I usually have to reboot to make it work again. I'm using a ethernet cable.

Pitmairen · 2019-01-22 06:24:23

Maybe related to this: https://bugzilla.redhat.com/show_bug.cgi?id=1650984 https://bugs.archlinux.org/task/60832

A temporary fix for me is to reload the r8169 module:

modprobe -r r8169
modprobe r8169

This make the network work again. If it works for you, you could maybe create a script that is run and reload the module after resume.

nyn · 2019-02-17 09:25:12

I experienced the same problem using systemd-networkd for network management and the e1000e kernel module. Carrier ist lost after suspend, removing and then adding the e1000e module fixed that for me, too.

wzrdtales · 2019-02-21 08:46:51

Same for me, lately, not sure yet which update broke this, I almost always need to restart the NetworkManager daemon to relogin into the wifi. The wlan module just disappears.

kemosabi · 2019-03-05 21:53:33

I've had similar issues for a while now. It began just after a system update as reported above. I'm betting it's a driver issue at present and since I have a workaround I'm not sweating it for the moment. If it doesn't resolve in enough time that I get fed up, I'll dig into the issue (it doesn't itch enough yet).

I've been using a different work-around from those above:

sudo ifconfig eth0 down
<pause>
sudo ifconfig eth0 up
<wait ~30-45 sec>

From some reason, that seems to mitigate issue for me.

Other notes, FWIW:
* I also use the e1000e module
* I'm resuming from a manual suspend that I've set up to occur when the battery is below a certain percent remaining
* It's a suspend, not a hibernate, in my case
* I generally plug in the laptop and resume soon after the system goes into suspend (think < 30min)
* I use wired ethernet with the wireless interface disabled most of the time
* I *do* see a carrier loss message in the journalctl output and it's pretty late (well into the resume)

Update on 11-March 2019:
I've updated recently and the problem may have gone away. I'm not sure because today was the first today since
I've started seeing this issue on which I resumed from sleep and then became distracted for more then 20-30 minutes.
I noticed that the network interface was up after that distraction. So either it would've come up anyway if I'd previously waited
long enough (maybe still longer than would be generally acceptable), or something changed when I updated last week. I'm
sorry to say I don't remember exactly when I updated last week, so here's hoping it wouldn't matter anyway.

Last edited by kemosabi (2019-03-11 20:57:34)

Arch Linux

#1 2018-11-02 01:43:05

No network after resuming from Hibernate

#2 2018-11-02 02:13:06

Re: No network after resuming from Hibernate

#3 2018-11-02 02:14:03

Re: No network after resuming from Hibernate

#4 2018-11-02 07:29:22

Re: No network after resuming from Hibernate

#5 2018-11-03 00:37:51

Re: No network after resuming from Hibernate

#6 2018-11-03 03:54:18

Re: No network after resuming from Hibernate

#7 2018-11-03 08:26:12

Re: No network after resuming from Hibernate

#8 2018-11-04 10:32:20

Re: No network after resuming from Hibernate

#9 2019-01-14 06:10:22

Re: No network after resuming from Hibernate

#10 2019-01-21 16:43:02

Re: No network after resuming from Hibernate

#11 2019-01-22 06:24:23

Re: No network after resuming from Hibernate

#12 2019-02-17 09:25:12

Re: No network after resuming from Hibernate

#13 2019-02-21 08:46:51

Re: No network after resuming from Hibernate

#14 2019-03-05 21:53:33

Re: No network after resuming from Hibernate

Board footer