F17 disabling wol

[TheNom]

Hi Guys,

My PC has worked fine with wol magic packets since i set it up a few years ago but since i went from F16 to F17 (fresh install due to GPT setup) it has not worked since.

I noticed that the link light dissapears when shut down but nothing has changed in the bios so i reset it to defaults and setup again just to be sure. I found a few posts saying to use 'ethtool -s p37p1 wol g' which works great and when i run 'ethtool p37p1' it show it has now been corrected. It now shows the link light when shut down and will boot on magic packet.... Once.

I know there has been a few posts previous regarding this but they all suggest either to use the 'ETHTOOL_OPTS="wol g"' option which doesn't seem to change the ethtool nic setting on network.service restart.

The other option that was suggested is to put the 'ethtool -s p37p1 wol g' in the /etc/rc.local which doesn't exist in F17. Can i just create this file and it work or are there other options.

Thanks in advance.

[DBelton]

Did you try to add the line: ETHTOOL_OPTS="wol g" to /etc/sysconfig/network-scripts/ifcfg-p37p1

[TheNom]

Hi DBelton,

Thanks for the reply, but i have tried this (i should have been a bit more clear in my previous post) but it doesn't seem to make any changes to the wol setting in 'ethtool p37p1'. I have actually sorted this problem by creating a simple init.d startup script in rc5.d and rc3.d that only has the startup section defined that just runs the 'ethtool -s p37p1 wol g'.

This script seems to work but i would rather the ETHTOOL_OPTS work as it seems a better way to go. When i set this up i couldn't find any log reporting if or why there was an issue when i ran ifdown\ifup or network.service restart.

any ideas?

Originally Posted by TheNom

I know there has been a few posts previous regarding this but they all suggest either to use the 'ETHTOOL_OPTS="wol g"' option which doesn't seem to change the ethtool nic setting on network.service restart.

[Doug G]

I never knew the os had anything to do with wol. I set up my lan once to let me power on wol-enabled workstations by magic packets but as I recall wol only required a BIOS setting in the computer to enable. I used wol with a number of different OS.

I don't normally use suspend or hibernate, is that an area where wol needs something from the OS?

[TheNom]

Hi Doug G,

I think the bios just sets up the initial hardware config for the nic as the mainboard needs to be able to supply power to the pci bus whilst the pc is off. The nic also has to be able to use the supply of power to keep the network link live and to be able to trigger the psu through the mainboard on receipt of a magic packet (the actual wol function). So I don't think it matters which state the PC is in (suspend, hibernate or fully off) when it does receive the packet.

I think my current issue is that the OS is disabling the on-nic wol function but the bios is still providing it power (which the nic is not using due to that wol function now being disabled).

I have never had this issue before with any OS either, even though the option in the OS to change the nic wol function has been available, I have never used them as I have always relied on the bios power to pci setting.

This is what has thrown me in this case as I don't seem to be able to find the case of it being disabled on every reboot.




Sorry about the waffle, I am explaining it to myself more than anything and don't mean to sound patronising :o

[Doug G]

Thanks TheNom, I never realized there was any OS function to disable wol on a NIC. Or perhaps the OS is able to put the NIC in some strange state where it's unable to properly decode the magic packet, which I guess would be the same as disabling wol.

I used a simple python script I'd found via google to generate the wake up packet for the computers. All I needed to do was pass the MAC address to the script and run it and the machine would wake up. I used mostly Dell hardware, probably around 10 machines, and I seem to recall there was one machine I could never get to wake up reliably..

I don't have any useful suggestions re your problem, sorry.

[TheNom]

P.s. If anyone is interested, here is my init.d script

File is called 'wolon' in /etc/init.d
chmod +x /etc/init.d/wolon
ln -s /etc/init.d/wolon /etc/rc5.d/S95wolon

Just remember to change 'p37p1' to your eth name that has the issue.

#!/bin/sh

start() {
    ethtool -s p37p1 wol g
    retval=$?
    return $retval
}

case "$1" in
    start)
	start
        $1
        ;;
    *)
        echo $"Usage: $0 {start}"
        exit 2
esac
exit $?

[timjaknz]

Hi - I also had this problem with a fresh install of Fedora 17. After lots of searching and experimentation I got mine working by setting the ethtool_opts in the ifcfg-eth0 file to ETHTOOL_OPTS="wol g" as per this Centos documentation and then crucially by turning off the NetworkManager.service and turning on network.service as per this post in the forums. It seems that NetworkManager uses a completely different method for managing the interfaces (which doesn't seem to be mentioned in the fedora 17 documentation at all). It took me awhile to figure out why the Fedora init processes weren't even looking at the network-scripts files. Also I had a minor problem with the gateway parameter being set incorrectly in the ifcfg-eth0 file by system-config-network.