Using Wake on LAN (WOL) across the Internet

Quick Start

Do not be intimidated by the length of this article: if you know your way around networks, you can jump straight to the implementation instructions.

Pre-flight Checklist

While intended to be as accessible as possible, this article requires you have a moderate amount of technical know-how. A background understanding of these topics will make reading this article easier:

• IP address
• TCP & UDP
• Packet of data
• Network interface, e.g. "eth0" or "en1" on Mac & Linux or "Local Area Connection X" on Windows

Topics we'll learn about as we go:

• MAC address
• Port forwarding

• Address Resolution Protocol (ARP)

You'll also need a home router capable of running DD-WRT. You might want to check their supported devices list before you get started. (If your router can't run DD-WRT, you may still be able to adapt the techniques used here to your router with some perseverance.) Also, do be aware that Wake on LAN does not work over wireless networks - you'll need a hard wired connection for this to work. [a]

Introduction: The History

A long time ago (1995), one of the world's largest enterprises, the federal government of the United States, started to develop an Information Technology problem: as their fleet of computers grew, they needed to do more night-time maintenance over the network on large numbers of desktop systems. This meant the computers needed to be on, but the Energy Star program was (smartly) recommending federal employees shut down their computers after work to conserve power. Visiting individual PCs in person to flip them on was not a scalable solution for the government. Advanced Micro Devices (AMD) saw an opportunity and proposed an idea: they would work with PC vendors to add a feature to network cards and motherboards that would let government IT employees wake up any system at any time remotely, which would in turn let them patch and repair the computers at will. [1]

To the best of my ability to research the matter, this is how Wake on LAN was initially developed. (IBM and Intel would quickly adopt AMD's open Wake on LAN specification into their enterprise desktop management software [2] [b], ensuring wide deployment of WOL.) While originally targeted at enterprises wanting to perform night-time maintenance, it quickly became apparent that the technology would also be useful to individuals and small businesses who wanted to remotely access files without leaving their computers on 24/7. In 1998, the engineering techniques that made Wake on LAN possible were built into the 2.2 revision of the PCI bus specification, which was universally used to define how peripherals were connected to PCs, ensuring most consumer systems built after that time would be capable of WOL. [c]

But Wake on LAN had, and continues to have, a problem. While the design of the technology is fundamentally sound, actually implementing it is very difficult. Doing so requires a detailed understanding of computer networks, and an uncommon amount of patience. It has gotten easier, though, as the bugs in routers that prevented Wake on LAN from working have largely disappeared, and many web sites have cropped up that let you easily send the specially-crafted message needed to wake a computer up.

At this point, Wake on LAN is fairly manageable for a networking-savvy person to implement for use inside a network (i.e. waking up one computer from another computer in your house.) Things get a lot harder when you want to take Wake on LAN to the next level: waking up the computer on your desk from any computer attached to the Internet. [d] Or from your phone.

This article first tries to guide you through setting up Wake on LAN inside a network, and then moves on to show you one way to make it work between networks. If you need them, there are many other tutorials available online to help you get a grasp of the networking concepts involved and accomplish that first stage. [Appendix] As you read through this, please send me whatever feedback you have: I welcome it all, even the bobcat you're going to put in the mail.

Introduction: Why You Would Bother

Why not leave your system on all the time? Two reasons: Money and carbon.

On the financial front, you'll save a nice chunk of change just from lowering the amount of electricity you use. If you have an average desktop, and you use your computer about 50 hours a week, you'll save a little shy of $100 per year by putting it to sleep when you aren't using it. [Appendix]

Johnny Automatic here saved $100 last year because he slept his computer when he wasn't using it.

Also, by sleeping your computer you'll reduce the wear on its parts, making it last longer and lowering the potential of having to replace it due to hardware failure. [e]

On the environmental front, keeping your computer off will put less carbon in the atmosphere. While you may be able to stomach the cost of the electricity that powers your computer, generating it is expensive to the environment. Most electricity in America comes from coal, an extremely dirty energy source. An average kilowatt-hour generates 1.35 pounds of carbon dioxide in America [3]. If you use an average computer for 50 hours a week (implying you don't use it 118 hours per week), then you are generating about half a ton of carbon dioxide by leaving it on:



To get a sense of how much that is, we can use publicly available information about the amount of carbon dioxide that forest can sequester [4], and determine how much forest it would theoretically take to clean up after your inactive computer (please note this is a loose calculation and is very approximate, but should give the right order of magnitude).



It takes about a third of an acre of forest to compensate for your idle computer.

That's about the amount of land that one or two average suburban American homes sits on. [f]

It takes between one and two homesteads worth of forest to sequester the excess carbon dioxide generated from keeping your computer on around the clock.

The point is, every step you can take to reduce your energy consumption will cause nature to love you slightly more, and probably buy you dinner from time to time. Also, it will help keep climate change at bay.

Introduction: The Technology

Wake on LAN is fairly simple to explain. When your computer goes to sleep, it keeps power running to the network card. It's actually a fairly apt analogy to say the network card is half-asleep: it doesn't carefully analyze the data it receives in the usual way, but it does lazily watch for anyone blurting at it with a special "wake up" message. It's just like a person sleeping: you sleep through small night time noises in your house, but your alarm clock makes a sound specifically designed to wake you up.

This special message is called a "magic packet," and is looks like this: It's a single UDP/IP packet with a payload of 48 one bits, followed by the target network card's MAC address repeated 8 times. (The MAC address is a universally-unique ID number assigned to the network card; no two cards on the planet have the same MAC address. A typical address looks like 0E:F3:B2:86:9E:11, written in hexadecimal. MAC addresses are often written with dashes ("-") as the delimiter instead of colons.) A full typical magic packet would look like this:

The magic packet is designed this way because it's very easy for the network card to watch for on almost no power -- for the most part, all it needs to do is watch for an improbable number of sequential 1 bits coming across the wire, represented above in hexadecimal as a series of 'F's. (In computer science terms, this is a very simple "state machine" to implement.) If it sees that, it starts counting the number of times it sees its own address, and if that figure hits eight [g] (almost impossible to happen accidentally), the network card sends a message to the computer's power management unit to wake the system up. [c]

(Techy aside: For those wondering what headers needs to be included in the magic packet, the answer is that it does not matter at all. Wake on LAN is completely oblivious to everything above the link layer (Ethernet) in the OSI model -- this is explained in more detail in "Stage 2: Understanding the Network Issues.")

Stage 1: Getting Wake on LAN working inside a network

To start off, we need to get Wake on LAN working inside your home network. You'll need at least two devices to set this up.

If you have only one computer, you're in something of a bind, since you generally want to be able to test waking one computer up with another. You have a couple of options:

• Go straight for the endgame. Skip to getting Wake on LAN working over the Internet, and bypass getting it working on your local network.
  
• Borrow a computer from someone else and follow along with this tutorial normally.

Part I. Configuring your operating system and BIOS

First, confirm your target computer has Wake on LAN capability built into its hardware. You'll need to do this in your system's BIOS. Since each BIOS is different, I can't cover all permutations, but generally the steps are going to be as follows.

Windows / Linux:

• Restart your system, and push F2, Delete, Space, Escape, or F1 to get into your BIOS
• Rifle around in the options using the on-screen instructions until you find Wake on LAN (common abbreviations are WOL and WoLAN, and sometimes this feature has an entirely different but similar-sounding name)
• Activate Wake on LAN and commit the BIOS changes.

Sample BIOS settings window [5]

Mac: Your system has Wake on LAN, and it's always enabled on a hardware level.

With that done, you need to configure your operating system to permit Wake on LAN.

• Mac: System Preferences > Energy Saver > Power Adapter> "Wake for Ethernet network administrator access"
• Windows XP: Control Panel > System > Hardware tab > Device Manager > Network Cards > right-click Your Ethernet network card > Properties > Power Management > "Allow this device to bring the computer out of standby" & "Only allow management stations to bring the computer out of standby."
• Windows Vista: Please follow the steps in this Microsoft Knowledge Base article.
  
• Linux: You're on your own. But that's why you chose Linux, right?

Mac OS X WOL setting

Windows XP WOL setting

Part II. Sending the magic packet

Sending the magic packet from inside your network will be the most straightforward if you download one of the many small desktop software tools dedicated to the purpose. Later on in the tutorial, after we have WOL packets traveling across networks, we'll switch to using one of the many web sites that send magic packets.

For Windows, I recommend Anil Rhemtulla's Magic Packet Sender. For Mac OS X, I recommend ReadPixel's WakeOnLan app.

ReadPixel's WakeOnLan app

Anil Rhemtulla's Magic Packet Sender

(You can also send the Wake on LAN packet from your router, if you already have custom firmware installed. In DD-WRT, go to Administration > WOL. If you don't know what this means, don't worry, ignore it.)

In order to send the magic packet, you need two pieces of information: your subnet's broadcast address, and the target computer's MAC address. Some programs that send magic packets ask for a transport layer (e.g. UDP, TCP) and target port number as well. You'll need to chose UDP for Wake on LAN to work, but the port number is completely up to you - just remember what you chose so you can set up your router later.  Tradition calls for using UDP port 9, though you may see 7 occasionally.

To find the subnet broadcast address of your home network, simply take your computer's IP address and exchange the last octet for 255. For example, if your IP address is 192.168.1.23, the broadcast address is 192.168.1.255. When you send a message to your subnet's broadcast address, your router will deliver it to all hosts on your network. The target computer's MAC address can be found as follows:

Mac Leopard: System Preferences > Network > Ethernet service > Advanced... button > Ethernet tab > Ethernet ID

Windows XP & Vista: Start > Run... > "cmd" > ipconfig /all. Alternatively, you can open Start > All Programs > Accessories > System Tools > System Information > Components > Network > Adapter.

(Windows users: Both the software tool I recommend, Magic Packet Sender, and its more popular colleague, Depicus Wake on Lan, have a slightly different idea of what they want for input. Both ask you for the target computer's IP address, and a subnet mask with which the software can calculate the subnet's broadcast address. Magic Packet Sender's interface is slightly more clear in this regard, and its interface should help you through the subnet math if that's a topic you're not already familiar with.)

At this point you should be able to get Wake on LAN working within your network.

Stage 2: Understanding the network issues involved in getting Wake on LAN working across networks

Now that we have Wake on LAN working on a single subnet, we need to transition to getting it to work across subnets. The first step in doing so is to understand why this is harder than simply pointing the magic packet at a computer on a remote network.

Traditionally, to access a particular computer on a remote network, you set up port forwarding on that network's router. This means you tell the router "please direct all incoming traffic on port X to computer Y." As an example, you might direct all incoming TCP traffic on port 3389 (used for Windows Remote Desktop) to the IP address 192.168.1.10. Let's say your router has a public address of 69.23.153.12. Then, no matter where you are on the Internet, you can Remote Desktop to 69.23.153.12 and you'll be looking at your home computer's screen.

Why does this not work for Wake on LAN? Because shortly after your computer goes to sleep, it loses its IP address. This is the crux of this entire article, and something many other Wake on LAN tutorials neglect to mention. Even if a few minutes earlier your computer had address 192.168.1.10, your router will suddenly become clueless as to where to send packets with that destination. (Typical ARP timeouts on routers are in the order of 5-20 minutes.)

So the question is: How do you get an IP packet delivered to a computer with no IP address?

This is, admittedly, where things get complicated. Also, there is more than one way to solve this problem: what I propose here is, I feel, the most reliable, linearly explained answer.

Part I. What You Were Doing Before, and Why It Doesn't Mean Jack Now

In a single subnet situation, you sent the Wake on LAN magic packet as part of a broadcast IP packet. Behind the scenes, you were actually pulling some clever network trickery to deliver that Wake on LAN message to your target computer. The truth is, though, we will need entirely different clever trickery to get the Wake on LAN magic packet to the target computer when we want to do it across networks. In fact, the technique is so different that if you want to just get Wake on LAN working, and don't really care about understanding why you sent a broadcast packet, you can skip to Part II. What To Do Now.

First, I want to crystallize the mechanism that makes Wake on LAN work, so you can keep all this clever networking in perspective: your one and only goal is to get the Wake on LAN payload to the network card of your target host. Remember, the payload looks like this:

FFFFFFFF0123456789ab0123456789a
b0123456789ab0123456789ab012345
6789ab0123456789ab0123456789ab0
123456789ab

The way you get that to the network card, in terms of what protocols you use or how you route it there, does not matter. [h]

So why did you send the magic packet as part of a broadcast IP packet? Because it was the easiest way to guarantee delivery to the target computer, even if it was off. When you sent the broadcast packet, your router checked its routing table to see where it should go.

root@House:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         c-68-33-207-1.h 0.0.0.0         UG    0      0        0 vlan1

These are the internal rules for how the router handles IP traffic. That first line of data told the router the packet (which was sent to 192.168.1.255) should go out on br0. br0 stands for Bridge 0, which is the router's shorthand for "all of the physical Ethernet ports and the WiFi antenna." (Slightly more technically, br0 is a bridge consisting of interfaces en1 and vlan0, the latter being the physical Ethernet ports. [i]) Once the packet was put on br0, the internal circuitry of the router delivered it to every physical port on which it detected any kind of link - a property of the way Ethernet works. (One might imagine the router would only deliver the packet to physical ports on which it knew something about the host connected to that port, but you took advantage of the fact that Ethernet doesn't limit delivery in that way.) [j] And once the packet had been sent across the link - voilà - your computer saw the magic packet's payload and woke up.

Part II. What To Do Now

Unfortunately there are a couple problems with transitioning the broadcast packet technique to use across networks. First, you can't send a broadcast packet into a network from the outside - if routers allowed this, it would be trivial to overwhelm a network with traffic. [k] So, in the search for a way to get an IP packet to a computer that's off, you're limited to sending a packet directed at a particular host (called a "unicast" packet).

With port forwarding, you can definitely get a unicast IP packet into a network - but what then? You don't have an IP address to forward it on to. Even if you choose something sensible - say, the IP address your computer normally has when awake - the router will drop the packet while your computer is asleep, because its destination is unrecognized.

Our new trick is to make the router never forget what to do with a packet sent to your computer's IP address, even if your computer is off. Typically, when a router gets a unicast packet destined for a computer on one of its interfaces, it checks a table known as the Address Resolution Protocol (ARP) [l] table to confirm the host exists and determine what MAC address to assign the packet before delivering it. A typical ARP table will look like this:

192.168.1.1 at 00:24:b2:06:08:1a on br0
192.168.1.103 at 00:16:cf:67:f1:e5 on br0
192.168.1.126 at 00:1e:c2:ba:9e:52 on br0
192.168.1.145 at 00:14:a5:78:9b:78 on br0

If an IP packet's destination is unrecognized (not in the table), the router drops the packet. Generally this is reasonable to do: computers are supposed to send ARP announcements when they join a network, thereby registering themselves as valid destinations. Dropping packets to unknown destinations is a way routers can cut down on the amount of time they spend handling spurious traffic. Unfortunately our slumbering computer hasn't been in touch for a while and its ARP entry has been removed.

Under normal circumstances, this table changes gradually over time, as hosts join and leave the network. Thankfully, we are allowed to manipulate the table manually, as it's just stored in the router's active memory. We'll go over the exact process in the next section, but the basic idea is that we'll insert a permanent entry for the target of your Wake on LAN efforts.

192.168.1.103 at 00:16:cf:67:f1:e5 PERM on br0

That way, when your router gets the unicast packet destined for your computer's IP address, it will put the packet on the br0 interface. Once there, the router's circuitry will deliver it to the target host's network card. If everything goes according to plan, your computer will spring to life.

The various routes packets take in the Wake on LAN attempts described in this article. The route we are creating is highlighted in green.

Stage 3: Getting Wake on LAN working across networks

Part I. Getting DD-WRT installed

In order to accomplish this bit of network trickery, you'll need a slightly more capable router than the one you pulled out of the vendor's box. To get that, you don't need to spend a dime: you can simply replace your router's firmware with a (free and) more capable one: DD-WRT. DD-WRT lets your router do amazing things, including jump through rings of fire. Follow the installation instructions on the DD-WRT website to get it installed on your router. Any "size" (mini, standard, mega, etc) should do.

(I prefer DD-WRT, but if you're already running a different custom firmware, it shouldn't be hard to adapt these instructions.)

Part II. Configuring DD-WRT

Once you have DD-WRT installed and working, you don't have much further to get Wake on LAN working.

1. Retrieve your MAC address

Your MAC address should look something like 00:16:cf:67:f1:e5.

Mac Leopard: System Preferences > Network > Ethernet service > Advanced... button > Ethernet tab > Ethernet ID

Windows XP & Vista: Start > Run... > "cmd" > ipconfig /all. Alternatively, you can open Start > All Programs > Accessories > System Tools > System Information > Components > Network > Adapter.

2. Set a permanent DHCP lease on an IP address

You'll need a static IP address for your computer so you can create the permanent ARP entry. This is best done by specifying a static DHCP lease on the router (as opposed to a static IP on your computer), so that you can leave your computer on DHCP and roam to other networks.

DD-WRT > Services tab > Services sub-tab > DHCP Server box > Static Leases bar. Click Add. Add your MAC address (using colon separators), host name, and desired IP address (up to you, though it obviously has to be within your network, such as 192.168.1.15). Scroll to bottom and click Save.


3. Make a permanent ARP table entry

DD-WRT > Administration tab > Commands sub-tab > Command Shell box. Enter:

arp -s <ip address> <MAC address with colon separators>

Click Save Startup. The -s switch tells the router you'd like to create a static entry that shouldn't disappear even if it doesn't hear from your computer for a while.


4. Set up port forwarding

DD-WRT > NAT / QoS tab > Port Forwarding sub-tab.

Enter a new line:

• Application: "WOL" (or something else of your choosing)
  
• Port from: 9
  
• Protocol: UDP
• IP Address: <IP chosen for static lease above>
• Port to: 9
• Enable: Checked

Click Save.

5. Reboot your router

DD-WRT > Administration tab > Management sub-tab > Click "Reboot Router" at the bottom. Wait while the process completes.

Stage 4: Firing the Magic Packet

Time to pull the trigger. First, put your computer in the right kind of sleep. On Mac, you can just use regular Sleep from the Apple menu. On Windows XP, you need to "Hibernate" - in the Shutdown dialog, push Shift and you'll see the "Stand By" option change to "Hibernate." (Windows Vista - please see this guide on how to access Hibernate - http://www.howtogeek.com/howto/windows-vista/re-enable-hibernate-option-in-windows-vista/).

Next, visit DSL Reports' Wake on LAN utility and send your system a magic packet. (Or possibly have a friend do it if you're working with only a single computer.) Leave out the separator on the MAC address for their interface.

Congratulations! You've got Wake on LAN working!

I hope.

If it doesn't work, here are some tips to start diagnosing the problem. First, you'll want to set up SSH access into your router, so you can monkey around with its internals. This can be done under Administration tab > Management sub-tab > Remote Access box. The SSH username is root.

With SSH active, you can use the full line of ARP command switches to examine your ARP table. arp -a will list ARP entries. You should see one that has the word "PERM" on it, which is the one you set up. Do be aware that your problem may not be with ARP: Check that port forwarding is working, and try turning off any firewalls you have active (Security tab > Firewall sub-tab). Also, this shouldn't matter, but just for good measure, restart your target computer to make the new DHCP lease kicks in.

Although I can't help you resolve individual technical problems, do get in touch if any part of this tutorial is unclear or you feel stuck somewhere.

Appendix: Bonus Round (or: Funny 'What If?' Questions That Will Help You Understand the Networking)

If you're asking yourself questions (due to your enviable, insane curiosity) about what's going on in the network during all this, here are a few tests (and results) you might perform:

Q. If I send a TCP packet instead of a UDP packet, will the computer wake up? A. No.

Discussion: TCP requires the receiving computer to acknowledge the connection attempt before any data is sent. Since the receiving computer is off, it won't be able to set up the connection.

Q. If I could port forward to an internal broadcast address, and did, would my computer wake up? A. Yes.

Discussion: Some routers have an option to let you do this, and it may be simpler to implement, if less secure.

Q. If I put in the permanent ARP entry correctly, but send a WOL packet with the wrong MAC address in the data segment, will my computer wake up? A. No.

Q. If I put a random MAC address in the router's ARP table (but the target's correct MAC in the payload), and send the unicast magic packet as described in this article, will the target computer wake up? A. Yes, and thanks for asking.

Discussion: The router will faithfully put the random MAC address in the packet header and try to deliver it to interface br0, because of your permanent entry in the router's ARP table. Not recognizing the MAC address, the router's circuitry will put it on all ports, including the one your target computer is connected to. The target computer will see its MAC address in the payload and wake up. (Note that no other traffic will get through because once your network card is fully awake, it will discard all the packets it starts receiving with that random MAC address in the header.)

Appendix: Wake on LAN from an iPhone

I recommend the iWOL application by Sergio Rodrigues for use from the iPhone -- I use it regularly to wake up and then SFTP into my computers.

Appendix: Other Wake on LAN Tutorials

Appendix: Calculating the Cost of an Idle Computer

The average cost of a kilowatt-hour for residential users in America is 11.59 cents [6]. Data on how much power is actually consumed by modern computers is hauntingly scarce. Data on theoretical consumption is abundant, but to get real-world data you must have measuring equipment, such as a Kill-A-Watt. (If you have such measuring equipment, please contribute your data to this new collection form.) The University of Pennsylvania has some data on systems from 2005-2008 [7]. Determining the average consumption of each manufacturer's computers, and then averaging those figures, gives 130 watts for desktops and 30 for notebooks. Arithmetic to determine cost follows:



The cost savings calculation for not using the computer is the same, with the figure for hours in use replaced by the hours avoided (168 hours per week minus 50 hours is 118 hours per week). This comes to $92.45, which I gallantly rounded up to $100 for memorability.

It should be noted laptops use far less electricity than desktops - on the order of 30 watts, instead of 130. Obviously, laptops will have a much lower impact on one's electricity bill, though due to their integrated designs and comparative expense to desktops, the concern over financial impact due to hardware failure is considerably greater.

Thanks to Mr. Electricity for pointing the way to the University of Pennsylvania data.

Footnotes

a. I've never seen Wake on LAN work over wifi (802.11), but it has apparently been possible since 1996, on systems with Intel Centrino Mobile chipsets. [8] ^

b. In doing research for this article, I found many old references to "IBM's Wake on LAN technology" (such as a 1996 ZDNet article titled "IBM, Intel push LAN management ticket", implying IBM came up with the idea, but the AMD proposal was definitely the earliest document proposing Wake on LAN. ^

c. How exactly does the network card wake the system? If you're asking that question, you must be hardcore, so delve into the specifications: PCI Local Bus version 2.2 introduced the feature necessary (Engineering Change Request "3.3 V Aux"), and the PCI Bus Power Management Interface Specification went on to enrapture computer engineers with implementation information. Both documents are dated December 18, 1998. ^