Could it be a driver issue? Maybe Unraid 6.7 is using a different driver?

Seems relate, but I haven't Realtek 8111.

Edited May 24, 20197 yr by Benson

7 minutes ago, Jonathan Vella said:

Could it be a driver issue? Maybe Unraid 6.7 is using a different driver?

Could you try port-down the ethernet port in GUI network section then powerdown by power button, after that verify WOL work or not.

 

In next reboot, it will up as usual.

Edited May 24, 20197 yr by Benson

3 hours ago, Benson said:

Could you try port-down the ethernet port in GUI network section then powerdown by power button, after that verify WOL work or not.

 

In next reboot, it will up as usual.

Not so sure I understand your ask - I went to Settings -> Network Settings; from where can I try "port-down" ?

For me WOL does not work on 6.7. So i'm back to 6.6.7 and it works.

 

The network.cfg is the same for both.

 

# Generated network settings
USE_DHCP="yes"
IPADDR=
NETMASK=
GATEWAY=
BONDING="yes"
BRIDGING="yes"

 

1 hour ago, Jonathan Vella said:

Not so sure I understand your ask - I went to Settings -> Network Settings; from where can I try "port-down" ?

 

Just note ETH0 no this option.

 

Edited May 24, 20197 yr by Benson

14 minutes ago, OOmatrixOO said:

For me WOL does not work on 6.7. So i'm back to 6.6.7 and it works.

NIC controller is what band / model ?

Edited May 24, 20197 yr by Benson

3 minutes ago, Benson said:

NIC controller is what band / model ?

1x Gb LAN (Realtek RTL8111GR)

can you check the driver info with "ethtool -i eth0", please?

 

On my rig running unRAID-6.7, that is having the issue, I get:

driver: r8169
version: 
firmware-version: rtl8168f-1_0.0.5 06/18/12
expansion-rom-version: 
bus-info: 0000:04:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

...in my other rig, running a mor recent board (chip rev. 15, instead of rev.9) but unRAID v6.5.3, I get:

driver: r8169
version: 2.3LK-NAPI
firmware-version: rtl8168h-2_0.0.2 02/26/15
expansion-rom-version:
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

...so, clearly a different version.

...and  I am totally confused, based on the numbers given, which one is newer or more recent.

Edited May 24, 20197 yr by Ford Prefect

I have a MSI Z370-A PRO Motherboard with a Realtek RTL8111H.  After upgrading to 6.7 WOL stopped working.  The "ethtool -s eth0 wol g" command temporarily fixed the issue, would work with sleep wake cycles but rebooting the system brought the WOL problem back.

 

driver: r8169
version: 
firmware-version: rtl8168h-2_0.0.2 02/26/15
expansion-rom-version: 
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

Edited May 25, 20197 yr by carolina9

9 hours ago, carolina9 said:

I have a MSI Z370-A PRO Motherboard with a Realtek RTL8111H.  After upgrading to 6.7 WOL stopped working.  The "ethtool -s eth0 wol g" command temporarily fixed the issue, would work with sleep wake cycles but rebooting the system brought the WOL problem back.

 

driver: r8169
version: 
firmware-version: rtl8168h-2_0.0.2 02/26/15
expansion-rom-version: 
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

A workaround until the cause and fix are identified would be to run this command via the User Scripts plugin.  That way it would be re-run if the system is ever rebooted.

A workaround until the cause and fix are identified would be to run this command via the User Scripts plugin.  That way it would be re-run if the system is ever rebooted.

Thanks, I'll give it a try during the weekend.
But as a first thought: when checking the interface with "ethertool eth0", the wol parameter is already reported as being set to "g"...same from the sleep-plugin.
So why re-set it again??

Gesendet von meinem SM-G930F mit Tapatalk

I tested the Dynamix S3 Sleep plugin with "Set WOL options before sleep" set to "g" this did not fix the issue.  Entering the "ethtool -s eth0 wol g" command into the "Custom commands before sleep" field does allow for WOL to work when the system goes to sleep due to the plugin.

1 hour ago, carolina9 said:

I tested the Dynamix S3 Sleep plugin with "Set WOL options before sleep" set to "g" this did not fix the issue.  Entering the "ethtool -s eth0 wol g" command into the "Custom commands before sleep" field does allow for WOL to work when the system goes to sleep due to the plugin.

I think Ethtool method could be ignore.

 

In fact Unraid never say support or provide any setting for WOL. May be Unraid just simple not touch anything, if HW be config WOL, then it just keep work until you shutdown, but this time just not.

 

Hope LT could fix ASAP, WOL problem always happen and happen again in Linux/Windows.

Edited May 25, 20197 yr by Benson

43 minutes ago, Benson said:

Hope LT could fix ASAP, WOL

WoL is not officially supported by Unraid. There is just too much hardware dependencies to guarantee correct functioning for each and every system (including the system proceedings after waking up).

 

It seems only RealTek NICs are affected, hopefully Realtek releases an updated driver for the Linux kernel soon(tm).  

5 minutes ago, bonienl said:



It seems only RealTek NICs are affected,

Yes and only 8111, I haven't got problem on realtek 8168, Intel i211/i219.

 

I like your word (tm) 🤣

Edited May 25, 20197 yr by Benson

21 hours ago, carolina9 said:

I tested the Dynamix S3 Sleep plugin with "Set WOL options before sleep" set to "g" this did not fix the issue.  Entering the "ethtool -s eth0 wol g" command into the "Custom commands before sleep" field does allow for WOL to work when the system goes to sleep due to the plugin.

...so, it appears that this script/plugin feature is broken now, not the driver-

Thanks for pointing that out...

 

Edit: ...and it does now work flawlessly again, with the solution to use and configure the S3-Sleep plugin (Dynamix V6) as pointed out by @carolina9. Thanks again for that!

 

Regards,

Ford

Edited May 26, 20197 yr by Ford Prefect
confirm solution that solves the issue for me

On 5/25/2019 at 8:34 PM, Ford Prefect said:

...so, it appears that this script/plugin feature is broken now, not the driver-

Thanks for pointing that out...

 

Edit: ...and it does now work flawlessly again, with the solution to use and configure the S3-Sleep plugin (Dynamix V6) as pointed out by @carolina9. Thanks again for that!

 

Regards,

Ford

Hi.

Does this only work for sleep or also for shutdown?

With 6.6.7 i use shutdown in the  S3-Sleep plugin and WOL works. 

...never used shutdown with the S3-sleep plugin, only sleep/WOL

Ok thanks. I think I also switch to sleep. How do you use it? Let unraid going to sleep at night? 

Basically, I am sending the rig to sleep 30mins after all is "silent", meaning all disks spun-down, no network traffic etc...

It`s the large storage, with media and stuff, only used when there is a need, which occurs to 99% at weekends only..

The day-2-day workload is covered my a smaller unRAID, idling at 10W which does not go to sleep as it also powers the main router VM.

On 6/4/2019 at 2:18 AM, OOmatrixOO said:

Hi.

Does this only work for sleep or also for shutdown?

With 6.6.7 i use shutdown in the  S3-Sleep plugin and WOL works. 

For me this solution works for both sleep and shutdown state. Currently I have the following controller from Tp-Link:

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

 

Very strangely but maybe just pure coincidence, soon after upgrading to 6.7.2 my Intel pro 1000 CT which was fine for about three years suddenly started dropping out, giving errors like "hardware not found", about 30-60 minutes after system booting. This made me go out and buy the Tp-link with Realtek chipset and of course afterwards I came across the WOL issue... A great combo of annoyance... Of course I will test the Intel NIC again when I find the time.