Why Wake-on-LAN Uses UDP Broadcast Packets

Wake-on-LAN (WoL) relies on User Datagram Protocol (UDP) broadcast packets because powered-off or sleeping computers lack the active operating system and network stack required for complex, connection-oriented protocols. By using a lightweight, connectionless UDP broadcast, the WoL “Magic Packet” can be delivered across a local network segment directly to a low-power Network Interface Card (NIC) without needing an active IP address, an established handshake, or persistent switch address tables.

The Absence of an Active Operating System

When a computer is in a low-power state (such as ACPI states S3, S4, or S5), the operating system is not running, and the standard TCP/IP network stack is completely shut down. The main processor and system memory are inactive, leaving only auxiliary power supplied to the NIC. In this state, the NIC firmware is only capable of simple pattern matching at the hardware level and cannot participate in complex network conversations.

Why UDP Is Chosen Over TCP

TCP (Transmission Control Protocol) is connection-oriented and requires a three-way handshake (SYN, SYN-ACK, ACK) to establish communication. A sleeping machine cannot generate a response to initiate or acknowledge a TCP session.

UDP, by contrast, is a connectionless protocol: * No Handshake: Packets are sent without establishing a prior connection or verifying the recipient’s readiness. * Low Overhead: UDP headers are minimal and simple, allowing the basic firmware on a low-power NIC to parse the payload without needing full protocol decoding. * Fire-and-Forget Delivery: The sender simply transmits the data, making it ideal for triggering an action where receipt confirmation is unnecessary until the machine is fully powered on.

While the Magic Packet can technically be encapsulated in any protocol or sent directly as a raw Layer 2 Ethernet frame (EtherType 0x0842), UDP is the most widely adopted transport layer choice because standard network APIs allow applications to send UDP packets easily without requiring administrative or raw socket permissions. Typically, UDP ports 7 or 9 are used.

Why Broadcast Delivery Is Essential

Unicast network traffic is addressed to a specific IP and MAC address, relying on network switches and routers to forward the packet directly to the destination port. However, unicast delivery fails when a computer is asleep for two primary reasons:

  1. Lack of an Active IP Address: A powered-down machine usually releases its IP configuration. Even if it retains an assigned IP via a static mapping or DHCP lease, the machine cannot reply to Address Resolution Protocol (ARP) requests.
  2. ARP Cache and Switch Table Expiration: Network switches maintain dynamic tables mapping MAC addresses to specific physical switch ports. Over time, these entries expire. If a device has been asleep for several minutes, the switch no longer knows which port connects to the target machine and will drop unicast traffic intended for it.

Broadcast addresses (such as 255.255.255.255 for local broadcasts or a subnet-directed broadcast address) solve this by forcing the switch to flood the packet out of every active port on the local subnet. This guarantees that the target computer’s NIC receives the frame, regardless of how long the machine has been asleep.

Processing the Magic Packet

Once the broadcast packet arrives at all listening interfaces on the network: 1. The auxiliary-powered NIC captures the incoming frame. 2. The hardware scans the packet payload for the Magic Packet signature: a synchronization stream of 6 bytes of all ones (FF FF FF FF FF FF) followed immediately by 16 continuous repetitions of the target NIC’s specific 48-bit MAC address. 3. If the sequence matches the card’s burned-in hardware address, the NIC signals the computer’s power supply or motherboard (via PCIe or a WAKE line) to initiate the system boot sequence. All other machines on the subnet simply discard the packet.