No Ethernet Network Connection after Resume; very recent problem

Per this post & a couple subsequent, Ethernet connection issues after standby (e1000e), Kernel 4.17.9 , this morning i experimented with this 4.18 RC5 kernel. It did not help at all, ie, just like 4.17 & 4.16 now do [but did not used to !!!], there is no network connectivity post Resume after Suspend. Only by again reverting to 4.14 does the correct post-Resume functionality return.

This is just bonkers.

Hi @Kadee .

Could you do me a favour and try this workaround/fix.

nmcli r all off; sleep 5; nmcli r all on

The beauty of this method is that these commands do not require root. You can easily create a bash alias and do not have to enter your sudo password. To make things even easier you could simply ctreate a desktop file calling the commands via a one line script add add the desktop file to your start menu or dock. A very simple iconized one click solution to refresh Network Manager. It doesn't get much simpler than that. No systemd unit files to mess with, or complicated scripting. Give that a try and see if those commands work for you (if it's not too much trouble please).

I'm not sure if it will work for you, but it's worth testing to find out.

Thanks in advance.

Whilst per my previous posts i remain perplexed why i now suddenly have to do anything different [given this silly problem began without me making any relevant kernel or software change], i will nevertheless most happily try out your idea... & i sincerely thank you for it.

It's not convenient atm for me to do this test, so i will wait til my tomorrow morning's Resume [tonight before bed i will change the kernel back up to 4.17, reboot, then Suspend it for the night]. Can i just clarify how to do the initial test? Yes i understand about me making a simple bash script that i can run, but that's not necessary yet until it proves to workaround the silly problem. So, for the initial test:

  1. Is it sufficient that i literally just copy/paste your compound command into Konsole & run it there?
  2. I presume that i run the command post-Resume [when i see there's no network again], not pre-Suspend [when i already do have my network availability]?

Thanks, will let you know, tomorrow.


I'm not necessarily afraid of systemd, but as per one of my earlier posts, none of my attempts to Enable & Restart [nor Stop & Start] NetworkManager via systemctl succeeded in giving me back my network, with 4.16/.17/.18, post-Resume, since this annoying problem appeared 7 days ago.

Yes, you are totally correct.

Thank you for agreeing to give it a try.


OK, so you've now officially achieved Mayor of Crazytown status. :smiley:

Hi again

Sadly, it did not work. No error message ensued from the command, but after its Sleep timer ended & NM tried again to connect, it could not... same as has happened for the past 8 days. As "usual" nowadays on Tower since this dumb problem appeared, i had to reboot again before i had my network back, & i chose once more to boot into 4.14, since 4.16/.17/.18 contracted this weird illness of theirs.

Big. Sigh. [but many thanks for helping].

I kind of figured that would be a long shot. Those commands were less likely to work, but far easier to script. Thanks a lot.

I feel absolutely dirty for even asking this, as it's a very Windosy mindset, but...

Given that 4.16 & 4.17 used to Sleep-Resume-Network perfectly until 8 days ago, & given that 4.14 continues to do so, is there any value at all in trying this:

  1. Delete 4.16 & 4.17.
  2. Reboot.
  3. Reinstall 4.17.
  4. Reboot into 4.17, then test its behaviour again.


It couldnt hurt to try but first I would switch to the r8169 driver from the currently installed r8168. The 68 drivers have been causing some people a lot of trouble. The 69 drivers are already in the kernel.

This seems like a long shot to me. On the positive side, it is an easy test.

If you wish to do the uninstall reinstall route I would also do the same with the linux-fimware package and network manager.

I agree it's a long shot.

You've suggested that before, & i wanted to try it before, but i did not know how to do it. Reading your reply now i tried again, but still do not understand how to do it. I KNOW that you hate me posting images, & i'm sorry for this, but it's one of those examples i mentioned in that earlier thread where a pic is more efficient than any words i could throw together:


So if i cannot change the driver this way, do i have to do it in Konsole?

Sorry ... i imagine that me asking a question like this now reduces me to candidacy as a so-called help-vampire [a term i'd never heard of before this forum]. I'm going to check the Manjaro Wiki once more as soon as i post this.


I already agree with you both; i have almost no confidence in any success from it. However i am simply exasperated that such an irrational behavioural change occurred those 8 days ago. I mean, had there been a kernel update then, or a NetworkManager package version change then, i'd be totally OK with the explanation that they're incompatible with my HW, & i could simply downgrade them again. But to have this stupid change of behaviour with NO associated package change at the time, is simply nuts... & i've run out of productive ideas.

You are not a help vampire you are just verbose :smile:

Try unticking the right hand check box for the r8168 driver. I believe this will uninstall and automatically blacklist the r8168 driver. As I dont use this method I'm not 100% sure this is guaranteed , but I believe it should do the job for you. I will post the method to do it manually.

Reboot after the changes.

Thanks. Will try that, but fyi i just read & then discovered this:

mhwd -lh -d

11: PCI 200.0: 0200 Ethernet controller
  SysFS ID: /devices/pci0000:00/0000:00:1c.2/0000:02:00.0
  SysFS BusID: 0000:02:00.0
  Hardware Class: network
  Model: "Gigabyte Onboard Ethernet"
  Vendor: pci 0x10ec "Realtek Semiconductor Co., Ltd."
  Device: pci 0x8168 "RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller"
  SubVendor: pci 0x1458 "Gigabyte Technology Co., Ltd"
  SubDevice: pci 0xe000 "Onboard Ethernet"
  Revision: 0x0c
  Driver: "r8168"
  Driver Modules: "r8168"
  Device File: enp2s0
  I/O Ports: 0xe000-0xe0ff (rw)
  Memory Range: 0xf7c00000-0xf7c00fff (rw,non-prefetchable)
  Memory Range: 0xf0000000-0xf0003fff (ro,non-prefetchable)
  IRQ: 29 (4472061 events)
  HW Address: fc:aa:14:5c:74:10
  Permanent HW Address: fc:aa:14:5c:74:10
  Link detected: yes
  Module Alias: "pci:v000010ECd00008168sv00001458sd0000E000bc02sc00i00"
  Driver Info #0:
    Driver Status: r8169 is not active
    Driver Activation Cmd: "modprobe r8169"
  Driver Info #1:
    Driver Status: r8168 is active
    Driver Activation Cmd: "modprobe r8168"
  Attached to: #22 (PCI bridge)

Ie, it seems i merely need to do this in CLI:
modprobe r8169


No, you must unload the r8168 module first. I have never tested using this method before/after suspend. It does not survive a reboot,but I guess its ok for suspend?

If you merely want to check temporarily do this as a temporary test.

sudo modprobe -r r8168

sudo modprobe r8169

This is not as certain a method as blacklisting, but it can be used to test it temporarily. It does not survive a reboot.

Oh, ok, oh well, that reality was not evident on the Wiki page, so i'd not have known that info thanks.

Will close down my pgms now then try the GUI method. Thank goodness i have my Lappy here to get back online, if i am about to destroy my Tower's network connectivity, ha!

Oh dear, NOTHING happens, it refuses to untick.

EDIT: Oh hang on, right clicking it allows me to pick Remove. I'll do that.

1 Like

ok no big deal I will give you directions to blacklist the drivers.

post this:

find /etc/modprobe.d -type f -name "*.conf" -print -execdir cat '{}' \; -execdir echo \;

We cross-posted, i'd already acted on my edit whilst you were writing. So now in the GUI that r8168 is not installed any more... but no r8169 has magically appeared for me to select.

Forum kindly sponsored by