No Ethernet Network Connection after Resume; very recent problem

Hello again. I'm just about to go beddybyes, so i ran those commands one by one before Suspending Tower. There were no error messages, indeed no Konsole responses at all. However clearly they did work at some level, coz they did stop the networking [even removing the icon from the SystemTray]. I then Suspended, as mentioned... but curiosity got the better of me so i Resumed after a few minutes rather than waiting til tomorrow morn. Post-Resume, there was no network, again. I had to reboot once more before getting the network back so i could post this reply.

I wonder what has gone wrong inside the code for 4.18.4 & .5, compared to .3. Per earlier post, .3 Resumes perfectly, yet those two incremental updates somehow are just lousy.

Tomorrow, unless you, @philm, or someone else has had a breakthrough on the problem overnight [my time], i shall re-downgrade to 4.18.3... i definitely would like to properly solve this, but otoh the testing is burning up time i kinda need to spend on other tasks. No pressure, teehee.

You need to run the second half of the commands after resuming (above). That is good news you had no errors. That means I just need to tweak the unit file. Try the second set of commands to see if your network returns after resuming.

Run both sets of pre and post suspend commands again. If they work correctly the service files I wrote should work to remedy your issues (once we correct one omission I made).

My apologies, I had not had much sleep yesterday, and I forgot one fundamental detail.

I was focused on writing the unit file, and totally forgot to assign the correct file permissions.

We must make both service files executable and owned by root.

sudo chown root:root /etc/systemd/system/network-suspend.service
sudo chmod +x /etc/systemd/system/network-suspend.service

Then enable the service (once more just to be sure):

sudo systemctl enable network-suspend.service
sudo chown root:root /etc/systemd/system/network-resume.service
sudo chmod +x /etc/systemd/system/network-resume.service

Then enable the service (once more just to be sure):

sudo systemctl enable network-resume.service

I will modify my earlier post and add the omitted details.

Hopefully that gets you fixed up.

Whoa! I had to go sit down & catch my breath when i read this. It came as a shock to me, coz never before had the concept of You & Sleep in a single sentence occurred to me; til now i assumed the two entities were mutually exclusive :stuck_out_tongue_winking_eye:

Sorry for my delay getting back to you; been off fighting other fires, but am now about to do the 2018-09-02 Stable Update on Tower, hence timing is good to also try again on your suggestions.

Dumb question / statement... i am struggling to understand when i should read consecutive posts of yours as being complementary to each other [ie, i should do what BOTH posts say], versus when the later post SUPERSEDES the preceding one. Case in point... your 2 posts directly prior to this reply of mine.

The posts regarding running the individual commands pre/post suspend will give you a better idea if the whole process will work. They really should have been run before I ever wrote the systemd units, but you were offline for a bit so I got ahead of myself and just did them up anyways.

As I said I have been getting more into writing systemd files, so I just went ahead and did them ahead of time. I've been researching their usage so I was glad for an opportunity to practice at it further. I was sort of putting the cart before the horse so to speak.

1 Like

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

Forum kindly sponsored by