No Ethernet Network Connection after Resume; very recent problem

This may sound silly, but try switching back to the r8168 drivers to see if things are better again. The kernel and drivers are constantly being "improved" with this card so hiccups with this card unfortunately can be expected.

Just change the blacklist file entry back to r8169 and reboot. Good luck.

On a similar note, a Bluetooth case I helped with was fixed by the use of a systemd file was broken recently by a kernel update. A few weeks later, another update fixed things again. So, it's a bit of a roller coaster ride if you want to be on the cutting edge.

Ta, & not at all wanting to sound like an infantile ingrate, but noooo, i'm soooooo over this ■■■■ completely now. It's cumulatively burned up so much of my time, & hence also given the utter randomness of it [i repeat, **there was NO software or settings changes** since yesterday morn's good Resume], i now choose to eschew further unhappy blood-pressure rises by doing yet more chasing of this ephemera. Me being me, & my luck being what it is, i won't be at all surprised if The Dark Forces are even now marshalling themselves to also ruin my 4.14 kernel, in which case i'll be forced to once again fight this fight... but until then, uh uh, i'm just Over It.

Many many thanks all the same :slightly_smiling_face:

I understand. The LTS kernel is just fine. You don't always need to be on the latest and greatest. Cheers.

1 Like

Sage advice. @Kadee, it's just not uncommon at all for any machine to 'prefer' one kernel over another, and the LTS kernel is a great go-to kernel that many users, myself included, run full time. Even then, I also run the current stable kernel, just in case of breakage or heck--maybe the newest current will finally cure my BT speakers latency--who knows. :wink:

You could always try bisecting whatever recalcitrant kernel is problematic for you, which is always of use to the kernel developers. That can be a somewhat lengthy, involved process that most users try to avoid by using a kernel that supports their hardware's needs. Like the LTS kernel in many cases.

4.19 will become the next LTS kernel, just FYI.

When I purchased this laptop new in mid-2014 the first thing I did was slap Manajro unto it. The LTS kernel did not work--the machine was too new--but the current kernel did. But since then the LTS kernel has always given the best performance, across all distributions I have bothered trialing.

LTS is a great overall kernel! :smiley:

regards

1 Like

Because i'm a stubborn dope, today i decided to have another crack at this infernal problem. Clarification: since i last posted, nothing new has gone wrong, ie, so long as i stayed with the 4.14 LTS kernel, all Suspend-Resumes have behaved just fine re networking. It's just that i decided today to have another try with the latest [Stable branch] kernel; atm = 4.19.0-1 [rc4].

Once booted into 4.19.0-1 [rc4] tonight then relying on those previously-created /etc/systemd/system/network-suspend.service & /etc/systemd/system/network-resume.service files, i Suspended then a bit later Resumed, & saw as expected that i had NO connectivity. Ie, those services somehow broke back on 9 Sept [No Ethernet Network Connection after Resume; very recent problem]. I repeated this test a few more times, with 100% failure.

After another reboot, this time i decided to revert to @tbg's manual commands [No Ethernet Network Connection after Resume; very recent problem]. These succeeded... ie, post-Resume [after said manually-run commands] i have my network .. no reboot needed... & this is with 4.19.

Finding this happy success i've now semi-kinda-sorta-almost-automated it, a bit, by making 2 bash scripts i execute, one before Suspending, then later the other after Resuming. I verified with another test that these are also working fine.

Summary

Stop_NetworkManager_service_BEFORE_Tower_Suspend.sh

#!/bin/bash

### kdemeoz 4/10/18:   Manually execute this bash script immediately BEFORE i Suspend Tower, to perform an orderly closure of NetworkManager such that post-Resume, NM can be correctly restarted. 
# 
# Necessary in Tower [not Lappy] coz so far inexplicably, all kernels later than 4.18.3 have a broken NetworkManager post-Resume, if having done a bog-standard Suspend before. When that occurs, there's no alternative but to Reboot, in order to regain connectivity. 
#
sudo systemctl stop NetworkManager.service
sudo ip link set enp2s0 down
sudo modprobe -r r8169

Start_NetworkManager_service_AFTER_Tower_Resume.sh

#!/bin/bash

### kdemeoz 4/10/18:   Manually execute this bash script 15 seconds AFTER i Resume Tower, to perform an orderly launch of NetworkManager such that post-Resume, network connectivity is regained. For this to succeed, prior to Suspend i MUST *first* have run "Stop_NetworkManager_service_BEFORE_Tower_Suspend.sh". 
# 
# Necessary in Tower [not Lappy] coz so far inexplicably, all kernels later than 4.18.3 have a broken NetworkManager post-Resume, if having done a bog-standard Suspend before. When that occurs, there's no alternative but to Reboot, in order to regain connectivity. 
#
sudo modprobe r8169
sudo ip link set enp2s0 up
sudo systemctl start NetworkManager.service

So, this seems to be a nice step forward, allowing me to again use later kernels, & still benefit from the Suspend-Resume convenience [which i much prefer compared to having to SD each night then reboot each morning] without losing network ... so long as i ensure i remember to run those scripts appropriately.

I wonder why those actual systemd service files did work correctly, for a little while, then broke [3 Sept - 9 Sept]?

Try this before suspend to disable networking completely:

nmcli networking off      

Enable networking:

nmcli networking on           

These commands are a little different than the ones you tried before. This command disables all networking. If this command works, then see this post for a new systemd service you could amend yours to use.

Ha Ha. You just couldnt let it be eh Oz. Thats good because I need a new Guinea pig to test my scripts. I wrote a couple new services a day and a half ago on that thread and the dude hasn't even given me the courtesy of replying back even though hes been online. Not like you, you are always most pleasant and courteous.

1 Like

Teehee. Am happy to do so, but fyi won't be getting back to you for a few hours [about to have dinner, & hey, that Netflix isn't gonna watch itself, ya know!].

1 Like

If you feel like editing yours the important line to add to yours is:

RemainAfterExit=yes

This is just an example not tailored to your system.

#/etc/systemd/system/kill-network.service
#sudo systemctl enable kill-network.service
[Unit]
Description=Kill network at suspend
Before=sleep.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/nmcli networking off

[Install]
WantedBy=sleep.target
#/etc/systemd/system/start-network.service
#sudo systemctl enable start-network.service
[Unit]
Description=Restart network at resume
After=suspend.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sleep 15; nmcli networking on

[Install]
WantedBy=suspend.target

If the earlier commands worked for you, these services may fix you up again.

If you want to fiddle with yours I could walk you through it. If not Ill just experiment on my own system. :smile:

OK i've done that initial new test. Prior to Suspend [still kernel 4.19rc4] i ran:

...which behaved correctly in that it certainly disconnected the network. Then i Suspended for a few minutes, then Resumed, then after many seconds i ran:

...which sadly did not work... still no networkmanager. I had to reboot.

It's ok, i'm happy[ish] to keep using my 2 new scripts of your older commands, for before & after i Suspend - Resume.

Btw, i imagine it should now be ok for me to disable the 2 systemd services that we created back in Sept, then delete the 2 files? After all, they're apparently dead ducks anyway.

I'm a bit tired now, so shan't be doing any more tests or anything tonight, yeah i know, not a superhuman like you, haha. Thanks!

I wouldn't delete them just yet. I'm playing with my system to see what I can do to find the best options. Never say, never. :smile:

OK, I tested these files. Seems good, at least on my system. I added sleep commands. Without that the restart sequence will fail on some systems.

#/etc/systemd/system/network-off.service
#sudo systemctl enable network-off.service
#sudo systemctl start network-off.service
#sudo systemctl status network-off.service
#sudo systemctl daemon-reload
[Unit]
Description=Turn network off at suspend
Before=sleep.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/systemctl stop NetworkManager
ExecStart=/usr/bin/ip link set enp2s0 down
ExecStart=/usr/bin/modprobe -r r8169


[Install]
WantedBy=sleep.target

#/etc/systemd/system/network-on.service
#sudo systemctl enable network-on.service
#sudo systemctl start network-on.service
#sudo systemctl status network-on.service
#sudo systemctl daemon-reload
[Unit]
Description=Turn network on at resume
After=suspend.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/sleep 20
ExecStart=/usr/bin/modprobe r8169
ExecStart=/usr/bin/sleep 3
ExecStart=/usr/bin/ip link set enp2s0 up
ExecStart=/usr/bin/sleep 3
ExecStart=/usr/bin/systemctl start NetworkManager

[Install]
WantedBy=suspend.target

(edit)

These service files were written for the r8169 driver. If you are using the r8168 driver you must either switch to the 8169 driver, or alter the service units to load/unload the r8168 module instead.

Also, in the following lines:

ip link set enp2s0 up

ip link set enp2s0 down

You must substitute your own adapters ID for "enp2s0" in the above commands. You can not simply use "enp2s0" unless that is your own adapters designation.

The option RemainAfterExit=yes can sometimes cause problems on repeated suspend attempts. If the service does not work after repeated suspend attempts, then remove that line from the service file.

2 Likes

Good morning [here], oh Indefatigable One.

Ta a lot for your ongoing efforts... tis amazing.

Just writing here what i propose to do next, as a kind of reality-check if you see something here inappropriate:

  1. Rename current file /etc/systemd/system/network-suspend.service as /etc/systemd/system/network-suspend.service_v1 ... so that the systemd unit will not be able to find its target file & hence not run.
  2. Rename current file /etc/systemd/system/network-resume.service as /etc/systemd/system/network-resume.service_v1 ... same logic as above.
  3. Reboot Tower [still with 4.19rc4].
  4. Suspend Tower ... without running my bash script first ... logic here is to test this latest kernel & verify that with everything back to standard the problem still does exist, or was fixed in this kernel update [i expect the problem will still be present].
  5. Resume Tower ... if network still present, dance shriek & whoop. If network gone again, proceed...
  6. Duplicate fie /etc/systemd/system/network-suspend.service_v1 but rename this copy back to original name [ie, matching the systemd unit]. Preserve current ownership & permissions.
  7. Ditto /etc/systemd/system/network-resume.service_v1.
  8. Completely replace contents of /etc/systemd/system/network-suspend.service & /etc/systemd/system/network-resume.service with your latest commands per your latest post.
  9. Reboot Tower [still with 4.19rc4].
  10. Suspend Tower ... without running my bash script first.
  11. Resume Tower ... if network still present, dance shriek & whoop.

Have i got it right / am i on the same page as you intended?

That should work.

After you have created the new files, run:

sudo systemctl daemon-reload

Restart.

Test your suspend/resume function. If it does not work correctly please post.

systemctl status network-suspend.service 
systemctl status network-resume.service

Good luck.

1 Like

Fabulous, you have solved it [again]. Gratitude much!

FYI:

Immediately before "final" Suspend:

Summary
[kdemeoz@GA-Z97-HD3-Tower ~]$ sudo systemctl --failed
[sudo] password for kdemeoz: 
0 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

[kdemeoz@GA-Z97-HD3-Tower ~]$ systemctl status network-suspend.service
● network-suspend.service - Turn network off at suspend
   Loaded: loaded (/etc/systemd/system/network-suspend.service; enabled; vendor preset: disabled)
   Active: inactive (dead)
   
[kdemeoz@GA-Z97-HD3-Tower ~]$ systemctl status network-resume.service
● network-resume.service - Turn network on at resume
   Loaded: loaded (/etc/systemd/system/network-resume.service; enabled; vendor preset: disabled)
   Active: inactive (dead)

After "final" Resume [+ after sleep-timer ended & NM successfully reconnected]:

Summary
[kdemeoz@GA-Z97-HD3-Tower ~]$ systemctl status network-suspend.service
● network-suspend.service - Turn network off at suspend
   Loaded: loaded (/etc/systemd/system/network-suspend.service; enabled; vendor preset: disabled)
   Active: active (exited) since Fri 2018-10-05 12:13:43 AEST; 2min 32s ago
  Process: 4693 ExecStart=/usr/bin/modprobe -r r8169 (code=exited, status=0/SUCCESS)
  Process: 4687 ExecStart=/usr/bin/ip link set enp2s0 down (code=exited, status=0/SUCCESS)
  Process: 4673 ExecStart=/usr/bin/systemctl stop NetworkManager (code=exited, status=0/SUCCESS)
 Main PID: 4693 (code=exited, status=0/SUCCESS)

 [kdemeoz@GA-Z97-HD3-Tower ~]$ systemctl status network-resume.service
● network-resume.service - Turn network on at resume
   Loaded: loaded (/etc/systemd/system/network-resume.service; enabled; vendor preset: disabled)
   Active: active (exited) since Fri 2018-10-05 12:15:46 AEST; 37s ago
  Process: 5455 ExecStart=/usr/bin/systemctl start NetworkManager (code=exited, status=0/SUCCESS)
  Process: 5411 ExecStart=/usr/bin/sleep 3 (code=exited, status=0/SUCCESS)
  Process: 5406 ExecStart=/usr/bin/ip link set enp2s0 up (code=exited, status=0/SUCCESS)
  Process: 5352 ExecStart=/usr/bin/sleep 3 (code=exited, status=0/SUCCESS)
  Process: 5344 ExecStart=/usr/bin/modprobe r8169 (code=exited, status=0/SUCCESS)
  Process: 4899 ExecStart=/usr/bin/sleep 20 (code=exited, status=0/SUCCESS)
 Main PID: 5455 (code=exited, status=0/SUCCESS)
[kdemeoz@GA-Z97-HD3-Tower ~]$ 

[kdemeoz@GA-Z97-HD3-Tower ~]$ sudo systemctl --failed
[sudo] password for kdemeoz: 
0 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
[kdemeoz@GA-Z97-HD3-Tower ~]$

I did two more Suspend - Resume cycles as well, & all three were good. Oh yeah baby!

The cynic in me wonders how many days the resident Poltergoose will tolerate this situation, before she once more rises up & smites down poor innocent Tower, yet again.

1 Like

Well maybe we need to find out the name of your poltergeist/demon. I have heard that you must know the foul creatures name to have it successfully exorcized. This critter needs exterminating before this thread breaks my all time post count of 130 for a network support thread. :smile:

Great news, glad its working again. :smile:

You're now my official test guinea pig for all systemd service files. Ha Ha. :wink:

And, you're welcome (again).

ps. Thanks for including the status output for both service files. That was a thing of beauty to read all the successes reported. It's great when a plan comes together.

You could also test reducing the sleep time from 20 if that is too annoyingly long. I picked a time I figured would work every time. Reducing the sleep intervals may lead to it intermittently failing. Just FYI.

1 Like

I found a bug report for this issue. This has been ongoing since March, and is still not resolved. 127 people have reported this bug so far on Ubuntu.

2 Likes

Nice work, well found!

Thought of you again this morning as i woke up Tower & watched your code do its magic once more. Tis such a relief to have it. Ongoing gratitude.

Based on that bug report you found, it would seem that my lil ole poltergoose is well advanced in her evil plans for Total World Domination.

1 Like

Thanks for the solution, work 98%.

1 Like

Did you try switching drivers as well.

Meaning?

1 Like

Forum kindly sponsored by