Translation(s): English - Brazilian Portuguese - Español - Français - Italiano - Русский
Some notes on getting the Wake On LAN (WOL) feature to work with a Debian system.
Contents
- Wake On LAN
Hardware
Your first step towards booting your computer from over the network is to make sure your Ethernet card and mother board support some type of Wake On LAN feature. Notably 3Com's -NM (non managed) cards do not support WOL while their -M (managed) cards do.
There are two main systems. The older method uses a Wake On LAN three pin connector between your Ethernet card and your main board. Both headers are usually labelled 'wol'. The newer system uses a Wake On LAN pin on the PCI bus, negating the need for the cable. Some main boards support both and only provide the header for backwards compatibility with Ethernet cards that don't support the PCI pin.
Configuring Wake-on-LAN is a simple process on Alpine Linux. First, check if your network card supports Wake-on-LAN (WOL): # apk add ethtool # ethtool eth0 grep -i wake Supports Wake-on: pumbg Wake-on: d Supports Wake-on: pumbg means that WOL is supported, Wake-on: d means that it is currently. Supports Wake-on: pumbg. We really only care to see that this line contains a 'g', indicating a that it will accept a 'magic packet' (the mechanism by which wake-on-LAN works). N.B.: If you don't see it, all hope is not lost, you may just need to enable 'Wake-On-LAN' in the BIOS. Use ethtool to set “Wake-on” option to “g” value And that’s all, then you put your server in suspend or hibernate mode and wake it up remotely. It works like a charm, but then you try a second time, you hibernate the server again and it doesn’t wake remotely. Supports Wake-on: pumbg. Current message level: 0x00000007 (7) drv probe link. Link detected: no. All forum topics.
The broadcom part identify link but the i210 does not, see ethtool response: Supported ports: FIBRE Supported link modes: 1000baseKX/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 1000bas.
Recent motherboards with onboard NICs support Wake On LAN without the need for any pins/cables.
Firmware / BIOS
In a nice BIOS under power management you will have a clear, intuitive option labeled 'Wake On LAN'. Unfortunately my system wasn't so clear and has a couple options available. One seems to always work, the other sometimes works. I built upon the information shared by Mark Ivey since I also have a Shuttle XPC SK41G and am using the 'PowerOn by PCI Card' option with success.1
Software
Interface setup
stretch
add this file
reboot. Check if it worked with
Wake-on: g means it worked
Squeeze
As of Squeezeethtool parameters can be set directly from /etc/network/interfaces. The above can be achieved like this:
The script /etc/network/if-up.d/ethtool will then take care of calling ethtool on ifup. See /usr/share/doc/ethtool/README.Debian for more information.
You can then power down your system, and prepare the other system to wake it.
Before squeeze
After activating Wake On LAN in hardware it is also necessary to activate it in software. This is done using ethtool, which tells the interface to respond to the magic packet. Replace eth0 with your network interface device name:
This can be automated by editing /etc/network/interfaces:
This runs ethtool after every time eth0 is brought up, and also after it is brought down, so WOL should work even if the network is not brought down correctly.
Sending WOL messages
I installed the etherwake package in the controlling system for the etherwake command to send the 'Magic Packet' to my computer to wake it up. The program must be run as root to send the packet (I use sudo to execute it).
wakeonlan is also available, a program that uses UDP packets not TCP, and hence does not need to be run as root. It is also slightly more configurable.
WOL Sensitivity
I found that I didn't want any of the Wake On LAN settings except Wake on 'Magic Packet' (g). I only wanted my machine to turn on when I specifically told it to, not on unicast messages (u), broadcast messages (b) or multicast messages (m).
However, if you do want Wake On LAN on any of these events (other than 'Magic Packet'), you may find conflicts with pm-utils2. At the time of writing, scripts in this package will set the wake option for all relevant interface cards to 'Magic Packet' only, (g). This will be a problem if you want your machine to wake 'on-demand', when it receives traffic (u), for example. The issue and a fix is discussed below.
WOL Persistence
Hardware looks up to spec, you think the BIOS is set right, but it still doesn't work without some tweaking using the software. According to the Wake On Lan client FAQ most Linux drivers disable the WOL feature on boot3, so we need to get it going.
Kernel 2.6
With a 2.6 kernel we're using /etc/modprobe.d. You may be using /etc/modprobe.conf, but if it's not including /etc/modprobe.d you're probably getting told about that each time you boot and some stuff may not be configured properly. I'm using /etc/modprobe.d and I added a file local.conf into the directory. It says:
ethtool comes from the ethtool package, so you'll need to install that unless your card supports a load option to set WOL. If that's the case I'd make an local.conf file with the appropriate options line, maybe something like:
If your kernel uses an initramfs image (eg. Debian stock kernels), also run update-initramfs -u (or update-initramfs -u -k all if necessary) to rebuild kernel initial ramdisk(s).
Testing on another machine with a C3905B-TXNM and a 3C905C-TXM that uses the 3c59x module to drive them both I found that ethtool was unable to query them or set the WOL setting, but that the enable_wol=1 setting did work and was required.
Supports Wake On Pumbg
While I was messing with these settings, I noticed that both 8139too and 8139cp were loading, but loading just 8139cp alone failed since my chipset isn't new enough so I blacklisted it.
Debugging state with ethtool
After an hour struggling with why my system still didn't work I started throwing in the ethtool query command all over the place to see what the deal was:
ifup
I found that (at least with my 8139too driver on Debian 3.1/Sarge) the install line was working when I'd modprobe 8139too, but ifup also resets the WOL setting, so I added an up line to /etc/network/interfaces under eth0:
I kept the ethtool command in /etc/modprobe.d/local.conf in case I boot and ifup isn't executed before shutting down.
PM-Utils Conflicts
The pm-utils package contains scripts that are run on suspend, hibernate and on resume of the system. There is one script, /usr/lib/pmutils/power.d/disable_wol, which sets the configuration for interfaces to only wake on 'Magic Packet' (g), regardless of the settings you may have configured in /etc/network/interfaces (or one of the files under /etc/network/interfaces.d, or manually using ethtool or in some other way). Look for lines in the file similar to the following:
Obviously, if you have set an interface to Wake on LAN in the event of a unicast packet or 'Magic Packet' (ug), then suspend using pm-suspend, for example, this script will set the interface to 'Magic Packet' only (g) as part of the suspension process.
You can detect the problem, once you know what you're looking for, by noticing through ethtool after a resume that the 'Wake-on' settings for interfaces have been set to 'g'.
A simple fix (that will not interfere with package updates) is to add a file with the same name, disable_wol to the local configuration directory, /etc/pm/power.d/. This overrides the script in /usr/lib/pm-utils/power.d/disable_wol.
This is my (somewhat verbose, and functionally trivial) /etc/pm/power.d/disable_wol:
Conclusion
Wake On LAN works on Debian and opens some new options up to me.
I can log into my gateway and boot my desktop, grab what I need and then power it back off remotely. I'm using DHCP with MAC-to-IP mappings so I can look in that file on my gateway system to know the MAC address of the system I wish to wake up. If I didn't have that I could keep a text file.
My next feat is to have non-essential systems power-off (not just halt) on a power outage to extend the battery runtime for the essential systems and then use WOL to power the other systems back on after power is restored and the battery has hit some specific charge level. I think some settings with halt or APM or ACPI are not right on those systems. See OffAndOnAgain.
External Links
Using Wake-On-LAN WOL/PME to power up your computer remotely
http://xlife.zuavra.net/index.php/60/ethtool(8)
etherwake(8)
wakeonlan(1)
pm-suspend(8)
CategoryNetwork | CategorySystemAdministration
Getting Wake-On-Lan to work with a Shuttle SK41G and Mandrake Linux 9.1 (1)
https://packages.debian.org/search?keywords=pm-utils (2)
http://ahh.sourceforge.net/wol/faq.html (3)
Introduction
The typical steps to make your Ubuntu server wake on LAN are:
- Find your network card interface name
- Check your network card capabilities
- Use ethtool to set “Wake-on” option to “g” value
And that’s all, then you put your server in suspend or hibernate mode and wake it up remotely. It works like a charm, but then you try a second time, you hibernate the server again and… it doesn’t wake remotely.
What happened, is that you didn’t repeat the third step to set again the “Wake-on” option to “g” value. The value you set for the network interface is volatile and you have to repeat the third step on each boot… unless you make it sticky.
Setup the network interface to work just once
1.- Find your network card interface name
In my case, the server has three interfaces:
1: lo (the local loopback)
Supports Wake-on D
2: enp3s0: one 100Mbps ethernet card (not being used)
3: eno1: one 1Gbs ethernet card (this is the one I want to use to wake the system remotely, as it is the one configured to connect to my LAN). I will copy two values:
Interface name: eno1 (be aware of one (1) and lowercase L (l)). Usually interface name ends with a number, not a letter.
MAC address: e8:94:f6:08:5a:60
Supports Wake On Lan Pumbg
Now we know the interface name, we will check the Wake-on capabilities:
Take a look at the last lines. We are looking for two different lines:
Supports Wake-on: pumbg
and
Wake-on: d
The “Wake-on” mode configured by default is “d”, which means that the network card will not switch on the server when it receives a magic packet but, as the network interface supports “g” mode (it is one the letters in pumbg) we can set the value of “Wake-on” to “g”.
We will use ethtool for this. If it is not already installed on your system, do it:
Now, if you repeat the step to check your network card capabilities (ethtool eno1) you shoud see the “Wake-on” option set to “g” value.
That means your server is ready to sleep and wake remotely.
Put the server into hibernation mode:
And now wake it remotely using one of the many available tools. Depending on the platform you will use an Android, Windows, Linux, … tool for this purpose and the only thing you will need is the MAC address you copied some steps above.
If everything went right, your server has woken, but what if you repeat the previous steps? (hibernate – remotely wake) It doesn’t work.
As I mentioned in the introduction, the value you configure in the “Wake-on” option of your network card is volatile. Each time you reboot your server it resets its value (usually to “d”).
Make your configuration sticky
We will create a system service to set the “Wake-on” value to “g” each time the server boots or restart.
There are a lot of recipes for these, but most of them didn’t work in my case. I’ll tell you one configuration line that did the trick for me.
1.- Create the .service file using your favourite editor
Now, copy the next content inside the file (change the name of the interface card and set the description you prefer):
Save the file (^O + ENTER + ^X)
Now we will start the service for the first time
And check its status
You will notice the service is dead or inactive. This is normal because it is not actually a service and it is not running like a daemon, it starts, do whatever it has to do and finishes.
If we restart the server now, our service entry will not run at startup because we haven’t enabled it. To do so:
Now, you can restart the server and it will wake remotely because “Wake-on: g” should be already set when it boots.
The explanation to “TRULY sticky”
But, why did I titled my post with a “TRULY sticky”?. Well, the reason is that all the recipes I’ve found to do this didn’t work. After rebooting, always the “d” value was set for the “Wake-on” option.
In fact it is not a problem of executing the configuration or not. Although the service entry run on every reboot, it was doing it before the network card was available to be configured.
So, the problem is when to run the network card configuration.
That’s the reason you should put this line in you .service file:
To make sure it configures the network card when it’s really available.
I hope it to work for you too.