Jayson Broughton

Introduction

Wait, a blog post on wake-on-lan(WoL)?  Really? As old as WoL is you would think that there would be some good information out there on just how and why you should implement it.  But surprisingly it’s very sparse.  So just why WoL?  Well, it appears with all of those ‘Kill-a-Watt’ meters out there, people are really starting to focus on their electric bills both at home and work.  What better way to clear up those large electric bills than to shut off your machine when you’re not using it, and wake it up remotely when you need to access it?  In a future blog post I’ll be talking about ACPI levels in linux and power savings by hibernation.  But for now, I’ll be focusing on WoL, how to setup and all that fun and exciting stuff.

There are a few reasons why a person at home or an IT Administrator might utilize WoL.  Not only can you save on your electric bill (and in my case AC bill during the summer months), but you can also wake the computer up remotely when you need to get access to files/software, then hibernate it when you have completed your task.

As long as WoL has been around (mid 90’s I believe), companies are just now starting to realize the power savings of putting desktops to sleep.  There is actually open-source software being developed to wake up a machine automatically, retrieve data and shut the machine off when the connection has been severed.  You would think after over 10 years someone would have thought ‘oh! what a great idea!’  But I digress, at least there is on-going development.

Capabilities
I’m not going to go into great detail of how WoL works, nor am I going to tell you it’s just magical.  I’ll settle for the in-between technical jargon.
Oh but wait! It is magical! And by magical, I don’t mean fairies flying to your computer and spreading pixie dust all over (that stuff gets EVERYWHERE!).  WoL utilizes the OSI layer 2 to receive a  ’magic packet’ destined to the computer.  The Magic Packet in question is a broadcast packet containing the receiving device MAC address, broadcasted 16x usually reserved for UDP port 7 or 9.  The UDP Port in question can actually be broadcast on any UDP Port but is usually standardized to 7(echo) and/or 9(discard).

Because WoL is broadcast to a device MAC address, the device itself is platform independent.  There is no need to have windows/linux/monkeyux installed on the device.  As a matter of fact, various custom OS devices will wake up to WoL packets (including some firewalls and routers) if the system board is set up  to accept WoL packets.  And that’s about as technical as I will be getting when it comes to OSI and Packets.

Now comes the fun part, hardware.  As I stated earlier, WoL is OS independent, which means it resides on the hardware of the device itself (whether you’re using an onboard network card or a PCI Network card).  Back when I first started experimenting with WoL (late 90′s) there was a cable that connected from your PCI Ethernet card to your motherboard.  If memory serves me correctly it was a red, green and black cable.  Nowadays either your Ethernet is built into the motherboard, or newer versions of PCI/BIOS has taken care of the need for a WoL cable.  But keep this in mind if you are trying to utilize WoL on an old NIC.

Security is another concern for devices that are set to WoL.  Because of this, WoL is inherently set to broadcast over a local subnet to find the MAC Address.  There are exceptions though, you can enable UDP Port 7/9 on a firewall and use a WoL client to send a broadcast to an ip address.   But here comes the ‘why would you?’.  First off, someone can accidentally (or purposefully) send WoL to an ip range, waking up devices that you might have on the inside of the network.  If said device has a port being forwarded through the firewall, that gives the person access to the application that was previously sleeping.  And secondly, if (like me) your computers are located in a close proximity of your bedroom, do you really want to be woken up at 3am in the morning by the sound of jet turbines as a server powers up because someone accidentally sent a broadcast WoL packet to the wrong ip address?  From experience, I know that will only last once before your other half threatens to stick that loud fan in a nice quiet place before retiring back to bed.

But there is some relief for you truly paranoid types.  Some Network Cards (re: Intel off the top of my head) have the ability to encrypt a password on the NIC.  This requires the WoL client to send not only the 14 magic packets, but the password as well to start the machine.  I say some, because I have seen the option in WoL clients, but have yet to see a Network Card that supports encrypted passwords.

Software
There are some decent WoL clients out there.  I will be going over one for each Operating system.  I won’t be going over too much of the details here, as the software is self explanatory.  For windows, I use the Java WoL utility from sourceforge (it’s java, thus it will work as a GUI for both linux and windows).  You can download ‘Gui Java WakeOnLan’ here: http://sourceforge.net/projects/guijavawol/
Once you have downloaded and extracted the WoL gui, double-click on GuiWakeOnLan.jar.  This will open up a nice fancy graphical interface, allowing you to add various WoL clients you have on the network.  On the Right-Hand side of the interface, click ‘Add’.  From there you can add the IP Address of the client, MAC address, A label (ex: HomeComputer), and what UDP port to send the Magic Packet on.  Once the client has been added, it’as a simple as highlighting the label of the machine you want to wake up, and clicking ‘Awake’.  Tada!  Now your remote machine should be waking up.  This is a nice, simple graphical interface for waking up remote machines.
If you want to run guiWakeOnLan.jar from the commandline:

1. Open up a command terminal (start->run->cmd)

2. Navigate to the location you extracted the files to

3. execute: java GuiWakeOnLan.jar

Now for linux, there’s a commandline utility that will send your WoL magic packet.  As I use Debian for testing purposes, your mileage may vary when it comes to installing packages.

From debian execute:

apt-get install etherwake

The Same application should be available in redhats repoistory:

yum install etherwake

The etherwake package contains two applications; a binary executable called ‘etherwake’, and a perl script called ‘wakeonlan’.  Now there are some subtle differences between the two.  Etherwake allows you to use a password (-p switch) to send a password along with the Magic Packets, to a NIC that supports password-based WoL, and it allows you to specify another ethernet device to send the packets out.
Wakeonlan doesn’t have a switch to send password; but it does have some other useful switches up it’s sleeve that etherwake doesn’t have.  Wakeonlan allows you to specify a file with a list of MAC addresses to wake up, a different UDP port, and multiple MAC addresses on the same line.
To use Etherwake:

etherwake macaddress

Etherwake has some useful switches.  Below is a short description of what you can do with etherwake switches:

-b :send wakeup packet to broadcast address (eg: 255.255.255.0)
-D increase debug level
-i   Use interface name instead of eth0.  Useful if you have 2
     ethernet  addresses that point to different internal/external
     subnets.
-p   This is what I explained earlier, the use of a password.
      If a NIC allows for a password entry, you would specify
      it after the -p switch

To use wakeonlan:

wakeonlan macaddress

Useful switches for wakeonlan.

-i  broadcast ip address (eg: 192.168.2.255)
-p destination UDP port (default is 9)
-f file containing MAC addresses and source broadcast address

Enabling WoL
Now before I get too much into Enabling WoL, I’ll briefly talk about ACPI levels and just what you can and cannot do when waking up a ‘sleeping’ device.   There are 2 levels that allow for WoL from a ‘sleeping’ state.
ACPI S3 – commonly referred to in many operating system as ‘sleep’ or ‘standby’.  When a computer is placed in S3, data is written and saved to RAM.  ‘Waking up’ a computer in S3, results in an average of 10-20 seconds before everything is returned to normal.  Removing power to a machine in S3 will result in all data lost and the computer will boot as if it was never put to sleep.
ACPI S4 – Commonly referred to in many operating systems as ‘hibernation’. When a computer is placed into S4, or ‘hibernation’.  All information that would have been placed in RAM if the machine was put to sleep; is instead, written to non-volatile storage, such as a hard disk, file or partition.  The computer essentially saves everything to disk and ‘turns off’ in all aspects of the word.  A small amount of power resides on the motherboard (thanks to the power supply) that keeps enough power to the NIC in order for it to wake up from a WoL Packet.
The main difference between S3 and S4 is that while a computer is in S3, information is saved to RAM, which allows the machine to ‘wake up’ quicker than in S4.  While a computer is in S4, information is saved to the hard disk.  When a machine is ‘woken up’ from S4, information saved to the hard disk is usually written to RAM in order to wake the machine up.  Thus it may take longer for the machine to wake up in S4 vs S3.  Because information is stored on the Hard Drive in S4, there is a bigger savings in power, vs an S3 state where power still runs to critical components to keep information stored in RAM.  In a later blogpost I will be talking about ACPI power levels and energy savings between the various power levels.  But for now, that’s your quick and dirty introduction to S3/S4.

Enabling WoL

In order for WoL to be of any use, it must be enabled on your machine.  WoL can be set enabled on the BIOS on most motherboards that are manufactured today (if you have a built-in network card).  However, both linux and windows can also set up Wake-On-Lan through their respective Operating Systems as a way to ‘double check’ that Wake-On-Lan is enabled.

Enabling WoL in Windows

I’ll use the example of Windows 7 to enable WoL once it’s been properly set in BIOS.

1. Start by going to control panel, clicking on ‘network and sharing center’ and select ‘Change Adaptor Settings’ on the left-hand side.

2. Right-Click on your network device and go to properties

3.  Under the device list, there should be a ‘configure’ button, click this and go to the ‘Power Management’ Tab

4. Make sure the settings for ‘allow this device to wake up the computer’ and ‘Only allow a magic packet to wake up this computer’ are checked, and click OK

Enabling WoL in linux with Ethtool

The beauty of Ethtool is that not only can you see what your network adapter’s speed is set to, but you can also see and set the status of WoL from the command line.  As root from the commandline, run:

ifconfig

This will show your available ethernet adaptors, and allow you to write down the MAC address of your device while your at it.

ethtool ethX (where x is your ethernet adaptor #)

This will show your current settings on your ethernet device, look for the letter after Wake-On:.  If the letter is d than WoL is disabled, if the letter is g then WoL is enabled.  If WoL is disabled than execute the following command to enable WoL on your device

ethtool -s ethX wol g

Run ethtool ethX again to double check that the settings took effect.  If it shows ‘Wake-On: g’ than we are ready to rock and roll.

Gathering MAC Addresses

This will be a quick and easy one.  You need the MAC address of your ethernet controller in order to ‘wake’ it up.  From windows command line run: ipconfig and look for ‘MAC Address’.  From linux run ifconfig ethX to get the MAC address of your ethernet controller that you want to use for WoL.

Testing

Aaah, now here comes the fun part.  We are going to put everything I have gone over to the test.  Before we actually wake up a desktop, I’ll briefly go over how to put a desktop to ‘sleep’.

Putting a Windows Desktop to Sleep

There are 3 ways to put a windows desktop to sleep: A remote desktop session, from another windows machine with admin rights to your remote machine, or from the actual machine itself.  The last two are pretty self-explanatory.  From either a remote desktop session, or the machine itself; go to Start -> Shutdown -> Sleep.  If, however you want to put a windows machine to sleep remotely (lets say a script that you have setup to wake the machine up for windows updates, then put it back to sleep after updates have completed).  For this, you need an application that should be in every Administrator’s bag of tricks,  Microsoft’s PsTools.  You can download PsTools from here: http://download.sysinternals.com/Files/PsTools.zip. Keep in mind though, this is a windows utility to shut down a windows machine, so you probably won’t be running this on your linux box.  PsTools comes with the PsShutdown Utility, which will allow you to remotely hibernate a windows machine.  More information on the PsShutdown utility, including various switches can be found here: http://technet.microsoft.com/en-us/sysinternals/bb897541.aspx.  So, to put a Windows machine to sleep from a remote commandline, you would execute the following:

psshutdown computername -u username -p password -h

So if I had a computer named happy, the administrator username was sleepy and the password was sneezy, than the output would look like this: psshutdown happy -u sleepy -p sneezy -h.

Putting a Linux Desktop to sleep

Well, as with everything else; it’s easier in linux .  Linux comes with ACPI & Power Management utilities that allow you to shut your machine off from the commandline. You can either put your desktop to sleep by using your desktop gui interface and clicking on sleep, or you can execute one of the 3 commands from the CLI to put your machine to sleep

/usr/sbin/pm-hibernate

/usr/sbin/pm-suspend

/usr/sbin/pm-suspend-hybrid

As previously discussed, this will either hibernate, suspend or hybrid suspend your machine.  A hybrid suspend is something relativly new that both windows 7 and linux supports.  A hybrid suspend mimics a hibernate state, but suspends instead.  This means that you get all of the power saving goodies of hibernate, but the machine wakes up quicker by suspending.

Now that you know the commandline utility, you can easily wrap this in a script, or execute the command securely from a remote machine via ssh.   For this blog post, I won’t be going into host-trust authentication between SSH clients (but I promise, this will be a post).  You can setup a central machine that allows host-based authentication to other machines on your network, not requiring a password.  From there you can have a central machine setup to execute sleep commands (or anything else) from a script without having to provide a password.  But, if you want to put a linux machine to sleep remotely, than you can execute the following command:

ssh -l username /usr/sbin/pm-suspend &

Tada! Remote sleeping Windows and Linux Computers.  Now that they are sleeping, it’s time to wake them up.  Previously in this post I discussed the various clients, from java to commandline, that you can use to wake up the machine.  Now’s your time to try these out.  From the GUI interface that I previously discussed, enter the MAC address of the device you want to wake up and click ‘wake up’.  If your using the command line utilities, it would be either: etherwake MACAddress or wakeonlan MACAddress.  If your following along, the machine that you previously put to sleep should now be ‘waking up’.  If however it failed to wake up, check the following:

1. Does your Ethernet Adaptor support WoL?

2. Did you enable WoL from BIOS?

3. For Windows: Did you enable WoL from Control Panel/Network Adaptors?

4. For linux: Did you check that WoL was enabled via the ethtool utility?

5. Are you on the same network as the device you are trying to wake up?

6. Do you have the correct MAC address of the remote machine?

If you said yes to all of the above, than you might need to whip out tcpdump (or wireshark, pick your poison) and sniff the line of the remote machine while you attempt to wake up. Set tcpdump to check for udp packets going to the server.  To test this, wake up the machine that you want to ‘wake up’ and run tcpdump:

tcpdump -i ethX (ethernet device you want to use WoL on) udp port 9

Then send a Magic Packet to the remote machine and see if it get’s through (remember to temporarily disable your software firewall for the test).

Conclusion

And there you have it, WoL with remote machines against multiple operating systems.  This isn’t the end though, but merely the beginning  in the quest for power savings.  From here, you can use the above scripts on a server (or router if your router has the capability re:DD-Wrt) to remotely wake up a group of machines prior to a scheduled event (backups, System updates, etc).  After your pre-determined project has completed execution, then you can have another script put the desktop back to sleep.

Where to go from here?  Well, personally I would keep an eye on Apples Bonjour mDNSResponder and SleepServer (http://mesl.ucsd.edu/yuvraj/research/sleepserver.html).  As of right now, Bonjour mDNSResponder is opensource software but seems to only be available for Macintosh’s.  The other solution is SleepServer, As of right now it’s a Proof-of-Concept.  SleepServer seems to be more of a research project, but states that eventually the sleep server software will be released for both linux, macintosh and windows machines.  What both of these projects will eventually accomplish, is the ability to wake on demand.  When a remote client wants to retrieve information (such as file or print sharing) from a machine that is asleep, the software will wake the machine up, allowing the user to preform whatever necessary task.  Once the person logs out of the machine (or the print job is complete) the software will put the machine back to sleep.  Eventually this will lead to machines that are only powered on to preform their necessary duties, saving on electricity for both the home and business.