Sometimes you literally have to look outside the box. I'm sure you've already done the basic stuff like reset the router/broadband modem/whatever... Some routers have slow memory leaks that take months before they cause issues. It's also possible that your ISP upgraded their equipment or software and that is causing new problems. Maybe their DHCP leases are now very short. Every few years I find I have to replace my router, just because the outside world has changed too much! Do your other systems behave the same over ethernet or is the resident poltergeist just terrorizing one sleeping machine?
Ahem, an important necessary embarrassing reprise of some of my earlier words... blush. Previously as one part of my many tests over the past several days since this dumb new problem appeared out of nowhere, i definitely wanted to verify/discover if this fault occurred with not only my booted 4.17 kernel, so at that time i also tested my 4.16 kernel. The identical no-network post-Resume stupidity also manifested with this 4.16 kernel. Embarrassingly, in hindsight, i neglected to then also test my third installed kernel, 4.14. In this case it belatedly transpired that Meatloaf was wrong; Two Outa Three ARE Bad. Sigh, read on...
25/7/18: 11:11: UPDATE... I discovered that Kernel 4.14.56-1 DOES still happily Resume with normal network connectivity [why oh why lazily t'other day did i only test the two later kernels?]. Kernels 4.17.7-1 & 4.16.18-1 continue with their crazy recent problem of no network post-Resume... despite my Tower having successfully run with both the 4.17 & 4.16 series for several months, ever since they stopped being RC. What broke just recently?
11:45: Final reboot for today [???] after performing the latest Stable Update 2018-07-24 [which upgraded two of my three kernels], then repeated the Suspend-Resume tests. The new 4.17.9-1 still cannot reconnect to the network post-Resume. The new 4.14.57-1 still DOES reconnect to the network post-Resume.
So, now after 3.5 days of frustrating time-stealing shenanigans, Tower once more has network post-Resume [but ONLY if i run the 4.14 kernel]. Since my migration to Manjaro last year, this had never ever ever been a problem, regardless of what kernel i used... until something went down the toilet on 22/7. Weird.
Agreed, & i always strive for just this [me be a retired machinery diagnostics engineer who earned her daily bread doing logical troubleshooting diagnostics, so it's kinda habitual]. I won't bore you with details now, but none of the items you suggested here are applicable atm... various other tests & actions i did over the past several days [but was too lazy to document here] eliminated all of those. Thanks all the same.
Teehee, you got it in one! This is part of the reason i know that the weird recent fault is not my modem-router or upstream, but is restricted to my Terrorised Tower... both my Android phone & my Manjaro KDE Lappy have continued to have no problems connecting to my modem-router & hence internet anytime i want [including post-Resume in the case of Lappy]. Sigh.
Ha, machines were easy in comparison. They simply followed the laws of physics, thermodynamics, tribology & kinematics. Computers on the other hand seem to have a mind entirely their own, & obey nothing but voodoo black magic!
I would not be too concerned about this, personally. 4.14 is the current LTS kernel. It has happened to me from time-to-time on this mid-2014 Intel/Intel Dell laptop with various kernels. But since a few months from purchase, it has always seen the best overall results with the LTS kernel. Which is presently 4.14.
But if it drives you ■■■■■■■-crazy you can always bisect the non-functioning
kernel(s) and file a bugreport.
EDIT: If you choose to bisect, be sure to do so on the machine which gives you the related problems. Oh, and I note there was an upstream (Arch Stable) networkmanager update this morning.
Haha, hello there. Frankly, it does! My weird mind cannot cope with just accepting that "sh1t happens"... i believe in cause & effect over random arbitrariness, yet so far in this bonkers case it seems to be the latter that occurred. As my Timeline & my Pamac History data in my OP documented, afaik there had been NO applicable software change from Sat 21/7 to Sun 22/7, explicitly including no package update of any kernels or networkmanager. THAT's what has driven me nuts in trying to troubleshoot this... a BIG Tower behavioural change resulted from... NO discernible package change immediately prior. That's completely illogical.
It's harder & harder for me to reject @tbg's working hypothesis about my Tower...
PS: Another flawless Resume this morning; instant network, with the 4.14 kernel. Of course, a week ago, i would still have had a perfect Resume with the 4.17 kernel. Sigh.
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:
- Is it sufficient that i literally just copy/paste your compound command into Konsole & run it there?
- 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.
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:
- Delete 4.16 & 4.17.
- Reinstall 4.17.
- 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
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 https://wiki.manjaro.org/index.php?title=Mhwd & 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:
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.