The message is usually sent to the target computer by a program executed on a device connected to the same local area network, such as a smartphone. It is also possible to initiate the message from another network by using subnet directed broadcasts or a WOL gateway service. Equivalent terms include wake on WAN, remote wake-up, power on by LAN, power up by LAN, resume by LAN, resume on LAN and wake up on LAN. If the computer being awakened is communicating via Wi-Fi, a supplementary standard called Wake on Wireless LAN (WoWLAN) must be employed.
- 1 History
- 2 Principle of operation
- 3 Security considerations
- 4 Hardware requirements
- 5 Software requirements
- 6 Other machine states and LAN wakeup signals
- 7 Wake on Internet
- 8 See also
- 9 References
Principle of operation
Ethernet connections, including home and work networks, wireless data networks and the Internet itself, are based on frames sent between computers. Wake-on-LAN ("WOL") is implemented using a specially designed frame called a magic packet, which is sent to all computers in a network, among them the computer to be awakened. The magic packet contains the MAC address of the destination computer, an identifying number built into each network interface card ("NIC") or other ethernet device in a computer, that enables it to be uniquely recognized and addressed on a network. Powered-down or turned off computers capable of Wake-on-LAN will contain network devices able to "listen" to incoming packets in low-power mode while the system is powered down. If a magic packet is received that is directed to the device's MAC address, the NIC signals the computer's power supply or motherboard to initiate system wake-up, much in the same way as pressing the power button would do.
The magic packet is sent on the data link layer (layer 2 in the OSI model) and when sent, is broadcast to all attached devices on a given network, using the network broadcast address; the IP-address (layer 3 in the OSI model) is not used.
It is a common misconception that because Wake-on-LAN is built upon broadcast technology it can only be used within the current network subnet. While this is generally the case, there are some exceptions, and Wake-on-LAN can operate across any network in practice, given appropriate configuration and hardware, including remote wake-up across the Internet.
In order for Wake-on-LAN to work, parts of the network interface need to stay on. This consumes a small amount of standby power, much less than normal operating power. The link speed is usually reduced to the lowest possible speed to not waste power (e.g. a Gigabit Ethernet NIC maintains only a 10 Mbit/s link). Disabling wake-on-LAN when not needed, can very slightly reduce power consumption on computers that are switched off but still plugged into a power socket.
The magic packet is a broadcast frame containing anywhere within its payload 6 bytes of all 255 (FF FF FF FF FF FF in hexadecimal), followed by sixteen repetitions of the target computer's 48-bit MAC address, for a total of 102 bytes.
Since the magic packet is only scanned for the string above, and not actually parsed by a full protocol stack, it may be sent as any network- and transport-layer protocol, although it is typically sent as a UDP datagram to port 0, 7 or 9, or directly over Ethernet as EtherType 0x0842.
A standard magic packet has the following basic limitations:
- Requires destination computer MAC address (also may require a SecureOn password)
- Does not provide a delivery confirmation
- May not work outside of the local network
- Requires hardware support of Wake-On-LAN on destination computer
- Most 802.11 wireless interfaces do not maintain a link in low power states and cannot receive a magic packet
The Wake-on-LAN implementation is designed to be very simple and to be quickly processed by the circuitry present on the network interface card with minimal power requirement. Because Wake-on-LAN operates below the IP protocol layer, IP addresses and DNS names are meaningless and so the MAC address is required.
Subnet directed broadcasts
A principal limitation of standard broadcast wake-on-LAN is that broadcast packets are generally not routed. This prevents the technique being used in larger networks or over the Internet. Subnet directed broadcasts (SDB) may be used to overcome this limitation. SDB may require changes to intermediate router configuration. Subnet directed broadcasts are treated like unicast network packets until processed by the final (local) router. This router then broadcasts the packet using layer 2 broadcast. This technique allows a broadcast to be initiated on a remote network but requires all intervening routers to forward the SDB. When preparing a network to forward SDB packets, care must be taken to filter packets so that only desired (e.g. WoL) SDB packets are permitted — otherwise the network may become a participant in DDoS attacks such as the Smurf Attack.
Troubleshooting magic packets
Wake-on-LAN can be a difficult technology to implement, because it requires appropriate BIOS, network card and, sometimes, operating system and router support to function reliably. In some cases, hardware may wake from one low power state but not from others. This means that due to hardware issues the computer may be waking up from the "fully off state" (S5) but doesn't wake from sleep or hibernation or vice versa. Also, it is not always clear what kind of magic packet a NIC expects to see.
In that case, software tools like a packet analyzer can help with Wake-on-LAN troubleshooting as they allow confirming (while the PC is still on) that the magic packet is indeed visible to a particular computer's NIC. The same magic packet can then be used to find out if the computer powers up from an offline state. This allows networking issues to be isolated from other hardware issues. In some cases they also confirm that the packet was destined for a specific PC or sent to a broadcast address and they can additionally show the packet's internals.
In Windows Vista and higher, one can also determine how the OS was powered up. Running the powercfg.exe /lastwake command in a CMD prompt will list the "Wake Source". The Wake-on-LAN event should also be logged in the System event log.
Magic packets are sent via the data link or OSI-2 layer, which can be used or abused by anyone on the same LAN, unless the L2 LAN equipment is capable of (and configured for) filtering such traffic to match site-wide security requirements.
Firewalls may be used to prevent clients among the public WAN from accessing the broadcast addresses of inside LAN segments, or routers may be configured to ignore subnet-directed broadcasts (see above.)
Certain NICs support a security feature called "SecureOn". It allows users to store within the NIC a hexadecimal password of 6 bytes. Clients have to append this password to the magic packet. The NIC wakes the system only if the MAC address and password are correct. This security measure significantly decreases the risk of successful brute force attacks, by increasing the search space by 48 bits (6 bytes), up to 296 combinations if the MAC address is entirely unknown. However any network eavesdropping will expose the cleartext password. Still, only a few NIC and router manufacturers support such security features.
Abuse of the Wake-on-LAN feature only allows computers to be switched on; it does not in itself bypass password and other forms of security, and is unable to power off the machine once on. However, many client computers attempt booting from a PXE server when powered up by WoL. So, a combination of DHCP and PXE servers on the network can sometimes be used to start a computer with an attacker's boot image, bypassing any security of the installed operating system and granting access to unprotected, local disks over the network.
Interactions with network access control
The use of Wake-on-LAN technology on enterprise networks can sometimes conflict with network access control solutions such as 802.1x or MAC-based authentication, which may prevent magic packet delivery if a machine's WoL hardware has not been designed to maintain a live authentication session while in a sleep state. Configuration of these two features in tandem often requires tuning of timing parameters and thorough testing.
Some PCs include technology built into the chipset to improve security for Wake-on-LAN. For example, Intel AMT (a component of Intel vPro technology), includes Transport Layer Security (TLS), an industry-standard protocol that strengthens encryption.
AMT uses TLS encryption to secure an out-of-band communication tunnel to an AMT-based PC for remote management commands such as Wake-on-LAN. AMT secures the communication tunnel with Advanced Encryption Standard (AES) 128-bit encryption and RSA keys with modulus lengths of 2,048 bits. Because the encrypted communication is out-of-band, the PC’s hardware and firmware receive the magic packet before network traffic reaches the software stack for the operating system (OS). Since the encrypted communication occurs “below” the OS level, it is less vulnerable to attacks by viruses, worms, and other threats that typically target the OS level.
IT shops using Wake-on-LAN through the Intel AMT implementation can wake an AMT PC over network environments that require TLS-based security, such as IEEE 802.1x, Cisco Self Defending Network (SDN), and Microsoft Network Access Protection (NAP) environments. The Intel implementation also works for wireless networks.
Wake-on-LAN support is implemented on the motherboard of a computer and the network interface (firmware), and is consequently not dependent on the operating system running on the hardware. Some operating systems can control Wake-on-LAN behaviour via NIC drivers. With older motherboards, if the network interface is a plug-in card rather than being integrated into the motherboard, the card may need to be connected to the motherboard by an additional cable. Motherboards with an embedded Ethernet controller which supports Wake-on-LAN do not need a cable. The power supply must meet ATX 2.01 specifications.
Older motherboards must have a WAKEUP-LINK header onboard connected to the network card via a special 3-pin cable; however, systems supporting the PCI 2.2 standard and with a PCI 2.2 compliant network adapter card do not usually require a Wake-on-LAN cable as the required standby power is relayed through the PCI bus.
PCI version 2.2 supports PME (Power Management Events). PCI cards send and receive PME signals via the PCI socket directly, without the need for a Wake-on-LAN cable.
Wake-on-LAN usually needs to be enabled in the Power Management section of a PC motherboard's BIOS setup utility, although on some systems, such as Apple computers, it is enabled by default. On older systems the bios setting may be referred to as "WOL", on newer systems supporting PCI version 2.2, it may be referred to as "PME" (Power Management Events, which include WOL). It may also be necessary to configure the computer to reserve standby power for the network card when the system is shut down.
In addition, in order to get Wake-on-LAN to work enabling this feature on the network interface card or on-board silicon is sometimes required. Details of how to do this depend upon the operating system and the device driver.
Laptops powered by the Intel Centrino Processor Technology or newer (with explicit BIOS support) allow waking up the machine using wireless Wake on Wireless LAN (WoWLAN).
In most modern PCs, ACPI is notified of the "waking up" and take control of the Power up. In ACPI, OSPM must record the "wake source" or the device that is causing the power-up. The device being the "Soft" power switch, the NIC (via Wake-on-LAN), the cover being opened, a temperature change, etc.
The 3-pin WOL interface on the motherboard consist of pin-1 +5V DC (red), pin-2 Ground (black), pin-3 Wake signal (green or yellow). By supplying the pin-3 wake signal with +5V DC the computer will be triggered to power up provided WOL is enabled in the BIOS configuration.
Software which sends a WoL magic packet is referred to in different circles as both a "client" and a "server", which can be a source of confusion. While WoL hardware/firmware is arguably performing the role of a "server", web based interfaces which act as a gateway through which users can issue WoL packets without downloading a local client often become known as "The Wake On LAN Server" to users. Additionally, software that administers WoL capabilities from the host OS side may be carelessly referred to as a "client" on occasion, and of course, machines running WoL generally tend to be end-user desktops, and as such, are "clients" in modern IT parlance.
Create and send the Magic Packet
To create a Magic Packet you need to know the MAC address of the specific computer that will be turned on. Software to send WoL magic packets is available for all modern platforms, including Windows, Macintosh and Linux, plus many smart phones. Examples include: Wake On Lan Gui, Lan Helper, Magic Packet Utility, NetWaker for Windows, Nirsoft WakeMeOnLAN, WakeOnLANx, EMCO WOL, Aquila Tech Wake on Lan, ManageEngine WOL utility, FusionFenix and SolarWinds WOL Tool. There are also web sites that allow a Magic Packet to be sent online without charge. Example source code for a developer to add Wake-on-LAN to a program is readily available in many computer languages.
Ensure the Magic Packet travels from source to destination
If the sender is on the same subnet (local network, aka LAN) as the computer to be awakened there are generally no issues. When sending over the Internet, and in particular where a NAT (Network Address Translator) router, as typically deployed in most homes, is involved, special settings often need to be set. For example in the router, the computer to be controlled needs to have a dedicated IP address assigned (aka a DHCP reservation). Also, since the controlled computer will be "sleeping" except for some electricity on to part of its LAN card, typically it will not be registered at the router as having an active IP lease.
Further, the WoL protocol operates on a "deeper level" in the multi-layer networking architecture. To ensure the Magic Packet gets from source to destination, while the destination is sleeping, the ARP Binding (aka IP & MAC binding) must typically be set in a NAT Router. This allows the Router to forward the Magic Packet to the sleeping computer's MAC adapter at a networking layer below typical IP usage. In the NAT router ARP (aka MAC & IP) binding requires just a dedicated IP number and the MAC address of the destination computer. There are some security implications associated with ARP binding (see ARP spoofing) however as long as none of the computers connected to the LAN are compromised, an attacker must use a computer that is connected directly to the target LAN (plugged into the LAN via cable, or gains free access to the LAN by breaking through the WiFi connection security).
Most home routers are able to send magic packets to LAN, for example routers with the DD-WRT, Tomato or PfSense firmware have a built-in Wake On Lan client. The 3rd party FOSS project OpenWrt supports both Linux implementations for WoL etherwake and WoLs.
Respond to the Magic Packet and restore full power
Most WoL hardware functionally is typically blocked by default and needs to be enabled in using the system BIOS. Further configuration from the OS is required in some cases, for example, via Device Manager network card properties on Windows Operating systems. More below.
Modern versions of Microsoft Windows integrate WoL functionality into the Device Manager. This is available in the Power Management tab of each network device's driver properties. For full support of a device's WoL capabilities (such as the ability to wake from an ACPI S5 power off state), installation of the full driver suite from the network device manufacturer may be necessary, rather than the bare driver provided by Microsoft or the computer manufacturer. In most cases correct BIOS configuration is also required for WoL to function.
The ability to wake from a hybrid shutdown state (S4) or a fully powered off state (S5) is unsupported in Windows 8 and above, and Windows Server 2012 and above. This is because of a change in the OS behavior which causes network adapters to be explicitly not armed for WOL when shutdown to these states occurs. WOL from a sleep state (S3) or non-hybrid hibernation state (S4) is supported.
Mac hardware (OS X)
Modern Mac hardware supports WoL functionality when the computer is in a sleep state, but it is not possible to wake up a Mac computer from a powered-off state.
The feature is controlled via the OS X System Preferences Energy Saver panel, in the Options tab. Marking the Wake for network access checkbox enables Wake-on-LAN.
Apple's Apple Remote Desktop client management system can be used to send Wake-on-LAN packets, but there are also freeware and shareware Mac OS X applications available.
On Mac OS X Snow Leopard and later, the service is called Wake On Demand or Bonjour Sleep Proxy and is synonymous with the Sleep Proxy Service. It comes enabled out of the box, but for previous versions of the operating system, the service will need to be enabled under the Energy Saver pane of System Preferences. The network interface card may allow the service to function only on WiFi, only on Ethernet, or both.
Wake-on-LAN support may be changed using a subfunction of the ethtool command.
Other machine states and LAN wakeup signals
In the early days of Wake-on-LAN the situation was relatively simple: a machine was connected to power but switched off, and it was arranged that a special packet be sent to switch the machine on.
Since then many options have been added and standards agreed upon. A machine can be in 7 power states from S0 (fully on) through S5 (powered down but plugged in) and disconnected from power (G3, Mechanical Off), with names such as "sleep", "standby", and "hibernate". In some reduced-power modes the system state is stored in RAM and the machine can wake up very quickly; in others the state is saved to disk and the motherboard powered down, taking at least several seconds to wake up. The machine can be awakened from a reduced-power state by a variety of signals.
The machine's BIOS must be set to allow Wake-on-LAN. To allow wakeup from powered-down state S5, wakeup on PME (Power Management Event) is also required. The Intel adapter allows "Wake on Directed Packet", "Wake on Magic Packet", "Wake on Magic Packet from power off state", and "Wake on Link". Wake on Directed Packet is particularly useful as the machine will automatically come out of standby or hibernation when it is referenced, without the user or application needing to explicitly send a magic packet. Unfortunately in many networks waking on directed packet (any packet with the adapter's MAC address or IP address) or on link is likely to cause wakeup immediately after going to a low-power state. Details for any particular motherboard and network adapter are to be found in the relevant manuals; there is no general method. Knowledge of signals on the network may also be needed to prevent spurious wakening.
For a machine which is normally unattended, precautions need to be taken to make the Wake-on-LAN function as reliable as possible. For a machine procured to work in this way, Wake-on-LAN functionality is an important part of the purchase procedure.
Some machines do not support Wake-on-LAN after they have been disconnected from power (e.g., when power is restored after a power failure). Use of an uninterruptible power supply (UPS) will give protection against a short period without power, although the battery will discharge during a prolonged power cut.
Waking up without operator presence
If a machine that is not designed to support Wake-on-LAN is left powered down after power failure, it may be possible to set the BIOS to start it up automatically on restoration of power, so that it is never left in an unresponsive state. A typical BIOS setting is AC back function which may be on, off, or memory. On is the correct setting in this case; memory, which restores the machine to the state it was in when power was lost, may leave a machine which was hibernating in an unwakeable state.
Other problems can affect the ability to start or control the machine remotely: hardware failure of the machine or network, failure of the BIOS settings battery (the machine will halt when started before the network connection is made, displaying an error message and requiring a keypress), loss of control of the machine due to software problems (machine hang, termination of remote control or networking software, etc.), and virus infection or hard disk corruption. Therefore, the use of a reliable server-class machine with RAID drives, redundant power supplies, etc., will help to maximize availability. Additionally, a device which can switch the machine off and on again, controlled perhaps by a remote signal, can force a reboot which will clear problems due to misbehaving software.
For a machine not in constant use, energy can be conserved by putting the machine into low-power RAM standby after a short timeout period. If a connection delay of a minute or two is acceptable, the machine can timeout into hibernation, powered off with its state saved to disk.
Wake on Internet
The computer being awakened does not know whether the wakeup signal comes from another machine on the same network or from anywhere else. If the magic packet can be made to reach a computer, it can originate anywhere (e.g., from the Internet). This can be achieved by a virtual private network (VPN), which makes the remote computer appear to be a member of the local area network (LAN). In the absence of a VPN, a computer connected to a router can be awakened if a magic packet sent over the Internet is routed to it. This requires any firewall to be set up to allow entry of the Wake-on-LAN signal to a specified port. The port can be forwarded to the computer to be awakened; or some routers permit the packet to be broadcast to the entire LAN. However, some routers do not support this as they will not forward broadcast packets.
On routers that have this capability, the default TCP or UDP ports preconfigured to relay WOL requests are usually ports 7 (Echo Protocol) and/or 9 (Discard Protocol). However this proxy setting must be enabled in the router, and port forwarding rules may needed to be configured in its embedded firewall in order to accept magic packets coming from the Internet side to these restricted port numbers, and to allow rebroadcasting them on the local network (normally to the same ports and the same TCP or UDP protocol). Such routers may also be configurable to use different port numbers for this proxying service.
- Alert on LAN
- Alert Standard Format
- Desktop and mobile Architecture for System Hardware
- RTC Alarm
- Wake-on-Ring - Telephone line ring event
- Conventional PCI pinout - Power Management Event (PME#) signal
- Wired for Management
- von Nagy, Andrew (8 November 2010). "Wake on Wireless LAN". Revolution Wi-Fi Blog. Retrieved 28 October 2015.
- Fleishman, Glenn (28 August 2009). "Wake on Demand lets Snow Leopard sleep with one eye open". Macworld. Retrieved 15 September 2009.
How it works, Energy Saver preference pane
- Essick, Kristi (31 October 1996). "Intel, IBM strike deal to lower PC ownership costs". Computerworld. New Zealand. Retrieved 28 October 2015.
- "IBM Announces Universal Management - Industry's Most Comprehensive Tools to Lower Total Cost of Ownership". IBM News Room. 14 April 1998. Retrieved 28 October 2015.
- "Ethernet Tips & Tricks". Less Watts. Archived from the original on November 26, 2007.
- "Understanding Wake On LAN". LANdesk.com. Retrieved 28 October 2015.
- WakeOnLAN on Wireshark wiki.
- Stevens, W. Richard (2007). "Chapter 12. Broadcasting and Multicasting". TCP/IP Illustrated, Volume 1: The Protocols. Retrieved 28 October 2015.
- Haden, Rhys. "IP Addressing". Data Network Resource. Retrieved 28 October 2015.
- "Magic Packet Technology (White Paper, Publication# 20213, Rev: A Amendment/0)" (PDF). AMD. November 1995. Retrieved 28 October 2015.
- "About Subnet-Directed Broadcast Wake-Up Packets for Wake On LAN". Microsoft System Center Configuration Manager. 2007. Retrieved 28 October 2015.
- Marshall, Allen. "Powerpoint Presentation:ACPI In Windows Vista". WinHEC 2006, Microsoft Corporation.
- "Understanding 802.1X Authentication with Wake-on-LAN". Cisco Catalyst 6500 Release 12.2SX Software Configuration Guide.
- "Intel Centrino 2 with vPro technology and Intel Core2 processor with vPro technology" (PDF). Intel. Retrieved 7 August 2008.
- "Advanced Encryption Standard (AES) Instructions Set". Intel. Retrieved 6 April 2008.
- "Hardening Measures Built into Intel Active Management Technology". Intel. Retrieved 11 June 2008.
- "Xlife » Using Wake-On-LAN WOL/PME to power up your computer remotely". zuavra.net. Archived from the original on 8 March 2007. Retrieved 28 October 2015.
- "Intel® PRO/Wireless 3945ABG Network Connection – Overview". Intel.com. Retrieved 28 October 2015.
- "How to connect the UIRT2 B". skynet.be. Archived from the original on 21 January 2007. Retrieved 28 October 2015.
- p, Jessica. "Wake On Lan Tools". PCWDLD.com. Retrieved 9 September 2016.
- "'Wake on LAN' (WOL) behavior in Windows 8 and Windows 8.1". Microsoft. 2015. Retrieved 28 October 2015.
- "System Power States". Microsoft. Retrieved 28 October 2015.
- "HP Support document". Hewlett-Packard Support Center. Retrieved 28 October 2015.
- "About Wake on Demand and Bonjour Sleep Proxy". apple.com. Retrieved 28 October 2015.
- Brecht, Tim (2003). "Remote Wake-Up: Intel® Network Adapters User Guide". University of Waterloo. Retrieved 28 October 2015.
- "Router Port Forwarding Guides". portforward.com. Retrieved 28 October 2015.