No Ethernet Network Connection after Resume; very recent problem

Lovely, ta, no wukkas.

So, i am just about to do these things [those 2 new systemd files still exist here, but atm i am not doing the chowning etc stuff on them, til later per below]:

  1. sudo systemctl stop NetworkManager.service
  2. sudo ip link set enp2s0 down
  3. sudo modprobe -r r8169
  4. Suspend
  5. Make a cuppa, then Resume.
  6. Wait 15"
  7. sudo modprobe r8169
  8. sudo ip link set enp2s0 up
  9. sudo systemctl start NetworkManager.service
  10. Dance & whoop in joy as i see my network come back.
  11. Do your chown & chmod stuff, then try out another Suspend - Resume cycle.

Does this accurately summarise your advice; am i stuffing up my understanding?

You got it. :+1:

1 Like

Are you ready?

Can you withstand the anticipatory tension & suspense?

The results are...

Me be the one here dancing & whooping :dancing_women::joy:

:+1: do it.

It worked a treat. You're a genius good sir.

Confirmed successful with 4.18.5 & 4.19rc1.

Clarify... that's for Steps #1 - 10. Now gotta do the chown & chmod stuff.

EDIT: Have now done the chown & chmod stuff, & the re-enabling... no Konsole errors. Am still booted in 4.19, & am now about to do a "standard" Suspend-Resume [not with those earlier commands now]. Back soon...

Very nicely done, and thank you for the compliment.

1 Like

Yabber dabber doooooooooooooooooooooooooooo. All good.... Kernel 4.19rc1, post-Resume, network instantly available.

I am immensely grateful to you. Talk about a generous helpful Manjaroo! [even if maybe with slightly too much Sean Connery fondness]. Thanks so very much.

You are very welcome. I do not mind helping you in the least, as you are very capable and you make working on an issue easy.

I was just trying to help on a wifi thread and it was impossible. The user wouldn't listen, or post what I requested, and it all went down the drain quickly with major frustrations for all. Some users could give you a brain hemorrhage.

You thankfully are very pleasant and polite to deal with, so I am always extremely happy to help you. I'm so glad it's working properly now.

All the best Oz.

1 Like

Here's an utterly unwelcome status update, & my level of irritation at the Gods of Digitalis + my Pusillanimous Poltergeist will be evident from the frequency of censorship automatically applied by the forum software to my personal filenotes pasted in below. Gahhhhhhhhhh.

■■■■ it... inexplicably this morning the dreaded Tower no-network-after-Suspend-Resume bug returned. It's been Resuming fine [kernel 4.19rc1 & 4.18.5] every morning since implementing @tbg's 2/9/18 fix. It was fine yesterday morning, & i installed NO software nor updates yesterday, but despite having made NO discernible changes in the past 24 hours, this morning it was ■■■■■■ once again. ■■■■■■ with 4.19rc1, ■■■■■■ with 4.18.5. I confirmed that both /etc/systemd/system/network-suspend.service & /etc/systemd/system/network-resume.service still exist, are still enabled, are still owned by root, are still in group root, & still have permissions:

-rwxr-xr-x 1 root root  351 Sep  2 10:59 network-resume.service
-rwxr-xr-x 1 root root  330 Sep  2 10:56 network-suspend.service

Pissed off entirely, i finally booted back into 4.14(.67 atm], verified that's still good, & decided to abandon all further non-LTS kernels in Tower [despite them playing nice in Lappy, & having been good in Tower for the previous week]. I am so aggravated at this arbitrary electronic idiocy. ■■■■ it.

In some previous life i must have done some very bad things. Damn karma.

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:


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.



### 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


### 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 "". 
# 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:


This is just an example not tailored to your system.

#sudo systemctl enable kill-network.service
Description=Kill network at suspend

ExecStart=/bin/nmcli networking off

#sudo systemctl enable start-network.service
Description=Restart network at resume

ExecStart=/bin/sleep 15; nmcli networking on


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.

#sudo systemctl enable network-off.service
#sudo systemctl start network-off.service
#sudo systemctl status network-off.service
#sudo systemctl daemon-reload
Description=Turn network off at suspend

ExecStart=/usr/bin/systemctl stop NetworkManager
ExecStart=/usr/bin/ip link set enp2s0 down
ExecStart=/usr/bin/modprobe -r r8169


#sudo systemctl enable network-on.service
#sudo systemctl start network-on.service
#sudo systemctl status network-on.service
#sudo systemctl daemon-reload
Description=Turn network on at resume

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



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.


Forum kindly sponsored by