R8168 - Wake on Lan disabled at boot

Hello,
I have been trying to setup wol on my main Desktop for a long time now.
For some reason every time i restart my computer the wol setting reverts back to disabled.
Here is my output of sudo ethtool enp24s0

Settings for enp24s0:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Half 1000baseT/Full 
	Link partner advertised pause frame use: No
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	MDI-X: Unknown
	Supports Wake-on: pumbg
	Wake-on: d
	Current message level: 0x00000033 (51)
			       drv probe ifdown ifup
	Link detected: yes

I have followed the instructions or the arch wiki https://wiki.archlinux.org/index.php/Wake-on-LAN
When the instructions for making the wol setting permanent did not work ( i have tried all of them) i tried a what a post from the manjaro forum for a ARM distro of manjaro(Wake on Lan). This then lead me to try setting up a systemd service myself akkording to this tutorial. It only worked direktly after setting it up and after reboot it does not anymore.
Also i tried writing a small script, that i put in my startup programs, but also this did not work. The skript itself works fine.

#!/bin/bash                                                                                                             
  2 sudo ethtool -s enp24s0 wol g 

my system specs are as follows (inxi -Fxz output)

System:    Host: BlueBehemoth Kernel: 5.4.2-1-MANJARO x86_64 bits: 64 compiler: gcc v: 9.2.0 Desktop: Cinnamon 4.4.3 
           Distro: Manjaro Linux 
Machine:   Type: Desktop Mobo: Micro-Star model: B450 GAMING PLUS (MS-7B86) v: 1.0 serial: <filter> UEFI: American Megatrends 
           v: 1.70 date: 03/06/2019 
CPU:       Topology: 6-Core model: AMD Ryzen 5 2600 bits: 64 type: MT MCP arch: Zen+ rev: 2 L2 cache: 3072 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 81616 
           Speed: 1378 MHz min/max: 1550/3400 MHz Core speeds (MHz): 1: 1380 2: 1378 3: 1388 4: 1549 5: 1471 6: 1379 7: 1379 
           8: 1552 9: 1393 10: 1479 11: 1393 12: 1476 
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] vendor: XFX Pine 
           driver: amdgpu v: kernel bus ID: 1c:00.0 
           Display: x11 server: X.Org 1.20.6 driver: amdgpu,ati unloaded: modesetting resolution: 2560x1080~60Hz 
           OpenGL: renderer: Radeon RX 590 Series (POLARIS10 DRM 3.35.0 5.4.2-1-MANJARO LLVM 9.0.0) v: 4.5 Mesa 19.2.7 
           direct render: Yes 
Audio:     Device-1: AMD Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590] vendor: XFX Pine driver: snd_hda_intel 
           v: kernel bus ID: 1c:00.1 
           Device-2: Advanced Micro Devices [AMD] Family 17h HD Audio vendor: Micro-Star MSI driver: snd_hda_intel v: kernel 
           bus ID: 1e:00.3 
           Sound Server: ALSA v: k5.4.2-1-MANJARO 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Micro-Star MSI driver: r8168 
           v: 8.047.05-NAPI port: f000 bus ID: 18:00.0 
           IF: enp24s0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
Drives:    Local Storage: total: 2.04 TiB used: 925.80 GiB (44.4%) 
           ID-1: /dev/sda vendor: Kingston model: SV300S37A240G size: 223.57 GiB 
           ID-2: /dev/sdb vendor: Seagate model: ST1000DM010-2EP102 size: 931.51 GiB 
           ID-3: /dev/sdc vendor: Seagate model: ST1000LM014-1EJ164 size: 931.51 GiB 
Partition: ID-1: / size: 201.80 GiB used: 134.72 GiB (66.8%) fs: ext4 dev: /dev/sda2 
           ID-2: swap-1 size: 17.24 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda3 
Sensors:   System Temperatures: cpu: 39.1 C mobo: N/A gpu: amdgpu temp: 38 C 
           Fan Speeds (RPM): N/A gpu: amdgpu fan: 844 
Info:      Processes: 304 Uptime: 15m Memory: 15.65 GiB used: 2.01 GiB (12.8%) Init: systemd Compilers: gcc: 9.2.0 
           clang: 9.0.0 Shell: zsh v: 5.7.1 inxi: 3.0.37 

I hope some of you might have an idea, how i might be able to get wol working on my desktop!
Thanks in advance!

Uhhh... you are using the r8168 driver. You need to be using the r8169 kernel module. R8168 has a bug in the WOL feature.

 sudo mhwd -r pci network-r8168 

Reboot.

Be sure you have no blacklist left on the r8169 module in /etc/modprobe.d after uninstalling the r8168 driver if your connection is not working.

This might sound stupid, but where do i find this module?

the mhwd does not show it, the only thin i find is in pacman the package r8169aspm-dkms v4.15.3-2
Would that be the right package to install?

The r8169 module is included in all recent kernels. You do not need to install it. You simply need to uninstall the r8168 driver with the command I provided and then reboot.

If your NIC is not working after the reboot then you have a blacklist on r8169 module leftover that must be deleted (as I've already stated). Blacklists are located in:

/etc/modprobe.d

So i now have r8169 running, but my wol service keeps being deactivated after reboot.
What should i do now?
And how exactly should i set this up, to make the changes permanent and hopefully be able to try using wol?

It was working in March with r8169.

This would probably have been on kernel 4.19, so I would test that first. Try other kernels as well if no luck.

Interesting....
I just tried a few things:

  1. through wireshark i tested, if my magic packets arrive: Yes they do
  2. i shut down my system and tried waking it up again: Failed
  3. i suspended my system and tried waking it up: also failed...

Am i correct in assuming, that somehow the disabling of the feature happens before suspend and shutdown?

Would an older kernel maybe do the trick?

Oh! Just read that. Will try it now!

So. the 4.19 kernel does not seem to do the trick...

It stil remains deactivated after suspend

Try 4.14 as well as one of the real time kernels. After that you might have to start trying older linux-firmware packages because this was obviously working earlier in the year.

Do you have a WOL option in your bios, make sure it is activated.

Yes i have one and it is activated. But for some reason my lan port does not flash or have any lights blinking, when my computer is in suspend...

Are you dual booting Windows?

No. the only windows thing in my computer is an old hard drive, that only has the name windows. the rest should be clean.

Your computer is quite new?

Jup. Built it myself this summer.

4.14 is unbootable and 4.19rt does not seem to fix the problem.

Try the r8169aspm-dkms package from AUR.

The following command will install the linux-headers automatically for all installed kernels:

sudo pacman -S $(pacman -Qsq "^linux" | grep "^linux[0-9]*[-rt]*$" | awk '{print $1"-headers"}' ORS=' ')

*credit @dalto for the command

Install the headers on kernel 4.19 then install the driver.

Try 4.19 first then test the other installed kernels to see if the new drivers function on any other kernels.

After you have installed r8169aspm-dkms and rebooted please post:

lsmod | grep r816

This driver will likely not work on kernels above 4.19.

so after installing i tried waking up from suspend on all kernels and none worked.

r8169                  94208  0
libphy                102400  2 r8169,realtek

Well then I guess I'd recommend Uninstalling the AUR driver and return to the stock r8169 module.

The only other thing that might work is testing older firmware versions on perhaps kernel 4.19.

Older firmware versions of what?
I never actually played around with firmwares.

Forum kindly sponsored by