Wake-on-LAN still does the same job it did two decades ago: one small network packet tells a sleeping or powered-off PC to start. As of October 24, 2026, nothing about the protocol has changed. Dell’s current troubleshooting guide still tells users to switch WoL on in BIOS/UEFI first, enable the wake options on the Windows 11 network adapter second, and send a correctly addressed magic packet third. This wake on LAN Windows 11 tutorial walks through all three layers and then builds a small working tool around them.
You will finish with a machine that wakes on command from your phone, a script, or a cron job. The project is called wolctl: a Python CLI of about 100 lines, a token-protected HTTP endpoint, and a systemd service you can park on a Raspberry Pi, a mini PC, or a NAS. Budget about 40 minutes for the full wake on LAN setup if your hardware cooperates, plus extra time if your BIOS hides the option under a strange name.
The target audience is anyone who runs a home lab, a media server, a remote-work desktop, or a gaming rig that streams to other screens. If the last one is you, our guide on pairing a PS5 DualSense to a PC covers the controller side, while this article covers getting the PC awake in the first place. Every command below targets Windows 11 on the machine being woken and a plain Python 3 install on the machine doing the waking.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
How Wake on LAN Works in 2026 (and Why It Fails So Often)
A Wake-on-LAN magic packet is a payload made of six bytes of 0xFF followed by the target network adapter’s MAC address repeated 16 times. That gives 6 + 96 = 102 bytes, which our test script in Step 7 confirms. The packet usually travels as a UDP broadcast, although the protocol cares only about the payload and not the transport. When a network card is armed for wake, it keeps listening in a low-power state, scans incoming frames for that exact pattern, and signals the motherboard to power up when it finds one.
Three separate layers have to agree for that to work. The firmware must leave power flowing to the network card. The operating system must arm the card before it goes to sleep or shuts down. The network must deliver the packet to the card’s segment. A failure in any layer looks identical from the outside, which is why people spend hours on this. The PC simply does not wake, and nothing tells you why.
Intel’s Ethernet adapter documentation still lists Wake-on-LAN as a supported remote-wake feature, and Intel updated its WoL options page on October 24, 2026, according to our research for this article. The recent documentation churn is about wording and support pages, not a protocol change. Dell’s guidance also notes that support depends on the device, that not every computer supports WoL, and that Deep Sleep may need to be disabled.
Power state matters as much as configuration. Dell states that WoL support can require the system to be in S0 (Modern Standby), S3, S4, or S5. The table below translates those labels into plain terms and sets realistic expectations.
| Power state | Everyday name | Typical WoL behavior | What usually breaks it |
|---|---|---|---|
| S0 (Modern Standby) | Sleep on newer laptops and some desktops | Works on hardware that supports it, often needs AC power | Battery power, Wi-Fi-only wake, driver limits |
| S3 | Classic Sleep (suspend to RAM) | Most reliable state for wake | Adapter not armed, Deep Sleep or ErP options in firmware |
| S4 | Hibernate | Works on most desktops once armed | Fast Startup confusion, firmware power-saving modes |
| S5 | Full shutdown | Works only if firmware keeps standby power to the NIC | Fast Startup, Energy-Efficient Ethernet, ErP/Deep Sleep settings |
Treat the table as a testing order. Prove wake from Sleep first, then Hibernate, then a full shutdown. That sequence isolates the layer that is failing, and Steps 8 and 9 follow it.
Prerequisites: Hardware, Windows 11 Version, and Software
Wake on LAN is a wired-Ethernet feature in practice. Wireless wake, where it exists, is manufacturer- and chipset-specific and is generally called Wake on Wireless LAN, not standard WoL, so do not plan a build around it. Use a cable for the first test, even if you intend to move the machine later.
| Component | Requirement | Notes |
|---|---|---|
| Target PC | Wired Ethernet port, WoL-capable motherboard or laptop dock | Check the manual for Wake on LAN, Wake on PME, Power On By PCI-E, or Resume by LAN |
| Target OS | Windows 11, version 26H2 (the 2026 Update) or 25H2 | Microsoft reported full availability of 26H2 on October 21, 2026. 24H2 Home and Pro reached end of updates on October 13, 2026, so move those PCs forward |
| Sender device | Any always-on LAN device with Python 3 | A Raspberry Pi, mini PC, or NAS that can run scripts |
| Network | Sender and target on the same subnet for the first test | Avoid VLANs, guest networks, and client isolation until the basics work |
| Access | Local administrator on the target, shell access on the sender | BIOS access with a keyboard and monitor for Step 2 |
| Tools | PowerShell 5.1 or newer, powercfg, Device Manager | All ship with Windows 11 |
Three scope notes will save you grief. First, Windows 11 Enterprise and Education 24H2 editions remain supported through October 12, 2027, but that is irrelevant to WoL because the steps do not change between releases. Second, Microsoft Surface documentation, as summarized in our October 2026 research, says supported Surface devices can use WoL from Modern Standby, but only on AC power with a Surface Ethernet adapter or dock on a wired network. Third, a firmware update does not turn remote wake on by itself, so do not assume a fresh BIOS fixes anything.
On the tooling side, you do not need a third-party app because wolctl replaces one. Still, good ready-made options exist, such as the WakeMeOnLAN site for Windows, which reportedly lists version 1.96 as its current public version. Use it as a cross-check when you suspect your own packets are wrong.
Step 1: Find the MAC Address and Adapter Name for Wake on LAN
Every magic packet carries the MAC address of the adapter you want to wake, so collect it before touching any settings. Open PowerShell on the target PC and list the physical adapters that are connected right now.
Get-NetAdapter -Physical |
Where-Object Status -eq 'Up' |
Select-Object Name, InterfaceDescription, MacAddress, LinkSpeedThe output has one row per connected port. The values below are placeholders, so your adapter name and MAC will differ.
Name InterfaceDescription MacAddress LinkSpeed
---- -------------------- ---------- ---------
Ethernet Realtek PCIe 2.5GbE Family Controller AA-BB-CC-11-22-33 2.5 GbpsWrite down the Name (you will pass it to PowerShell in Step 4), the MacAddress, and the machine’s IP address from ipconfig. Also note whether the machine has two ports. Laptops with a docking station and desktops with two onboard NICs often wake from only one of them, and picking the wrong MAC is the number one reason a correct setup appears dead.
Reserve the IP address in your router so it never changes. A DHCP reservation keeps your inventory file honest, and it lets the wait-for-boot check in Step 10 probe the right address. Most home routers expose this under DHCP or LAN settings as a static lease or address reservation.
Common pitfall: copying the MAC from a virtual adapter. If you run Hyper-V, WSL 2, or a VPN client, Windows lists virtual adapters with their own MAC addresses. The -Physical flag above filters most of them out, but double-check that the description names real silicon.
Steps 2 and 3: Enable Wake on LAN in BIOS/UEFI and Disable Deep Sleep
Reboot the target PC and enter firmware setup using the key your vendor prints at boot. The relevant switch hides under different names, which is the first trap. Dell’s dated guidance says to open System Management, then Wake on LAN, select the option you want, then apply and exit. Other vendors use their own labels.
| Label you may see | Where it usually lives | What to set |
|---|---|---|
| Wake on LAN | Power management or System Management | Enabled, or LAN Only |
| Wake on PME / PME Event Wake Up | Advanced, Power | Enabled |
| Power On By PCI-E / PCI | Power Management, APM | Enabled |
| Resume by LAN | Power Management Setup | Enabled |
| ErP / EuP Ready | Advanced, Power | Disabled (it cuts standby power to the NIC) |
| Deep Sleep / Deep S4/S5 | Power | Disabled |
| Energy-Efficient Ethernet | Network or Advanced | Disabled where offered |
Set the first four rows to Enabled, whichever one your board provides, and switch off the last three if they exist. Dell specifically recommends disabling Energy-Efficient Ethernet where available because it can prevent wake events, and it adds that Deep Sleep may need to be turned off. If your board offers a mode like Wake on LAN from S5 as a separate toggle, enable that too, otherwise only Sleep will work.
While you are in firmware, check the storage mode if you changed it for an array. A board configured for RAID or Intel VMD behaves the same for WoL, but a stray reset of firmware defaults can silently disable the wake option along with everything else. If you recently rebuilt an array, our NVMe RAID 0 setup guide shows which firmware pages you touched, and it is worth re-visiting the power page afterward.
Save and exit. Boot into Windows and confirm nothing else changed. If your BIOS has no recognizable WoL option at all, do not give up yet. Some business-class and mini-PC firmware enables wake whenever the NIC wake setting is on in the OS, and Beelink, for one, publishes a WoL guide for its mini PCs. That guide does not establish model-specific support, so verify your exact model before trusting it.
Common pitfall: changing a setting but forgetting to power-cycle completely. After saving firmware changes, shut the PC down, unplug it for ten seconds, and plug it back in. That clears stale standby state that can survive a normal reboot.
Steps 4 and 5: Configure the Wake on LAN Windows 11 Adapter and Turn Off Fast Startup
Firmware keeps the NIC powered, but Windows must arm it before the machine sleeps. Open Device Manager, expand Network adapters, double-click your Ethernet controller, and go to the Power Management tab. Dell’s guidance for Windows 11 asks for two boxes there: Allow this device to wake the computer and Only allow a magic packet to wake the computer. Tick both.
Next, open the Advanced tab and look for a property called Wake on Magic Packet and set it to Enabled. Some drivers also expose Wake on Pattern Match, so check how your driver describes it. Dell’s guidance pairs this with the Power Management option Only allow a magic packet to wake the computer, which keeps ordinary traffic from waking the PC. If your driver offers Energy Efficient Ethernet or Green Ethernet here, disable it for the same reason as in firmware.
The GUI is fine for one machine, but PowerShell is easier to repeat and audit. Run an elevated PowerShell window and set the same behavior by name, using the adapter name from Step 1.
# Show the current wake settings
Get-NetAdapterPowerManagement -Name "Ethernet"
# Magic packet only, no pattern wake
Set-NetAdapterPowerManagement -Name "Ethernet" `
-WakeOnMagicPacket Enabled `
-WakeOnPattern DisabledRun the first command again afterward and confirm that WakeOnMagicPacket reads Enabled. If the cmdlet reports that the property is not supported, the driver does not expose it, and you should install the manufacturer’s current LAN driver rather than the generic one that Windows Update picked.
Turn off Fast Startup so shutdown really shuts down
Fast Startup is the quiet saboteur. It turns a normal shutdown into a partial hibernate, and Windows may not arm the adapter correctly in that state. Windows Fast Startup or hybrid shutdown was still being documented as a common cause of failure in October 2026, and Dell recommends turning it off. Disable it from an elevated prompt.
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled /t REG_DWORD /d 0 /fYou can also reach the same setting in Control Panel under Power Options, Choose what the power buttons do, then Change settings that are currently unavailable, then clear Turn on fast startup. Either route works. Run powercfg /a afterward to list the sleep states your hardware reports, because it tells you whether S3 is available or whether the machine only offers Modern Standby.
Windows 11 ships with several security and virtualization defaults that interact with power states. Memory integrity, for example, changes driver loading behavior, and our test notes on Windows 11 Memory Integrity and gaming performance explain how to check it. If an old LAN driver refuses to load after you enable such a feature, the symptom can be a missing Power Management tab, so keep that in mind if the tab vanishes.
Step 6: Verify the PC Is Armed for Wake Before You Test
Windows can tell you whether the adapter is armed for wake, so check before you start sending packets. This takes ten seconds and saves a lot of guessing. Open an elevated Command Prompt and ask for the devices currently allowed to wake the system.
powercfg /devicequery wake_armedA healthy wake on LAN Windows 11 setup lists your Ethernet controller here. If it prints nothing for the NIC, Windows has not armed it, which means the Power Management tab or the PowerShell setting from Step 4 did not take effect.
Realtek PCIe 2.5GbE Family ControllerYou can also arm a device from the command line, which is useful for scripted rollouts across several PCs. Use the exact device name from the previous output.
powercfg /deviceenablewake "Realtek PCIe 2.5GbE Family Controller"
powercfg /devicequery wake_armed
powercfg /lastwakeThe last command shows what woke the machine most recently, which becomes useful in Steps 8 and 9. After a successful test, powercfg /lastwake should name your network adapter. If it names a mouse, a keyboard, or a timer instead, then your packet did nothing and something else woke the PC.
Also look at the lock-and-link behavior of the hardware. With the PC shut down and the adapter armed, most NICs keep their link light on, and the switch port usually stays up. If the light dies the moment the PC powers off, the firmware is cutting standby power to the card. Go back to Step 3 and look again for ErP, EuP, or Deep Sleep settings.
Common pitfall: testing before the machine has fully slept. Windows needs a few seconds to enter Sleep. If you fire the packet while the display is still dimming, the machine is awake and ignores it, then you conclude that WoL failed. Wait 30 seconds after the fans stop.
Step 7: Build the Magic Packet Sender in Python
Now the sending side. On the always-on device, create a folder called wolctl. The core of the tool builds the packet, broadcasts it a few times, and probes a TCP port to find out when the target answers. Save the following as wolctl.py.
#!/usr/bin/env python3
"""wolctl: wake machines listed in hosts.json and wait until they answer."""
import argparse
import json
import re
import socket
import sys
import time
from pathlib import Path
HOSTS_FILE = Path(__file__).with_name("hosts.json")
def load_hosts():
return json.loads(HOSTS_FILE.read_text())
def magic_packet(mac):
clean = re.sub(r"[^0-9A-Fa-f]", "", mac)
if len(clean) != 12:
raise ValueError(f"not a valid MAC address: {mac}")
return b"\xff" * 6 + bytes.fromhex(clean) * 16
def send_magic(mac, broadcast="255.255.255.255", port=9, repeat=3, gap=0.25):
packet = magic_packet(mac)
with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as sock:
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
for _ in range(repeat):
sock.sendto(packet, (broadcast, port))
time.sleep(gap)
return len(packet)
def is_up(ip, port, timeout=1.0):
try:
with socket.create_connection((ip, port), timeout=timeout):
return True
except OSError:
return False
def wait_until_up(ip, port, limit):
start = time.monotonic()
while time.monotonic() - start < limit:
if is_up(ip, port):
return time.monotonic() - start
time.sleep(2)
return None
def wake(name, hosts, wait=True):
host = hosts[name]
broadcast = host.get("broadcast", "255.255.255.255")
size = send_magic(host["mac"], broadcast, host.get("port", 9))
print(f"[wolctl] sent {size}-byte magic packet for {name} ({host['mac']}) to {broadcast}")
if not wait:
return 0
took = wait_until_up(host["ip"], host.get("check_port", 3389), host.get("timeout", 120))
if took is None:
print(f"[wolctl] {name} did not answer on port {host.get('check_port', 3389)} in time")
return 1
print(f"[wolctl] {name} is up after {took:.1f}s")
return 0
def main():
parser = argparse.ArgumentParser(description="Wake hosts from hosts.json")
sub = parser.add_subparsers(dest="cmd", required=True)
sub.add_parser("list", help="show known hosts")
status = sub.add_parser("status", help="check whether a host answers")
status.add_argument("name")
wake_cmd = sub.add_parser("wake", help="send a magic packet")
wake_cmd.add_argument("name")
wake_cmd.add_argument("--no-wait", action="store_true")
args = parser.parse_args()
hosts = load_hosts()
if args.cmd == "list":
for name, host in sorted(hosts.items()):
print(f"{name:<10} {host['mac']} {host['ip']}")
return 0
if args.name not in hosts:
print(f"unknown host: {args.name}", file=sys.stderr)
return 2
if args.cmd == "status":
host = hosts[args.name]
up = is_up(host["ip"], host.get("check_port", 3389))
print(f"{args.name}: {'up' if up else 'down'}")
return 0 if up else 1
return wake(args.name, hosts, wait=not args.no_wait)
if __name__ == "__main__":
sys.exit(main())A few design choices deserve explanation. The packet goes out three times with a 250 millisecond gap, because a single UDP broadcast can drop on a busy switch or a flaky Wi-Fi access point that bridges to your LAN. The sender uses the subnet broadcast address from the inventory, such as 192.168.1.255, instead of 255.255.255.255, since many operating systems and routers handle the directed form more predictably. Port 9 is the common default, and port 7 also appears in the wild, but the NIC reacts to the payload and not the port, so either works if the packet arrives.
Now describe your machines in hosts.json next to the script. Replace each MAC and IP with the values from Step 1. The check_port tells wolctl which TCP service proves the machine is fully up, such as Remote Desktop, SSH, or SMB.
{
"desk": {
"mac": "AA:BB:CC:11:22:33",
"ip": "192.168.1.50",
"broadcast": "192.168.1.255",
"check_port": 3389,
"timeout": 120
},
"nas": {
"mac": "AA:BB:CC:44:55:66",
"ip": "192.168.1.60",
"broadcast": "192.168.1.255",
"check_port": 22,
"timeout": 180
}
}Before sending anything to real hardware, verify the packet itself. This one-liner builds a packet for a sample MAC and checks its length and header. I ran it on the finished file and it printed the 102 bytes the format requires.
python3 - <<'PY'
import wolctl
packet = wolctl.magic_packet("AA:BB:CC:11:22:33")
print(len(packet), packet[:12].hex())
PY102 ffffffffffffaabbcc112233The first six bytes are all FF and the next six are the MAC address, exactly as the format demands. If you would rather not trust a script you just wrote, send the same MAC with a mature tool such as WakeMeOnLAN and compare the results. Keep that comparison in mind for the troubleshooting section, because it cleanly separates a bad packet from a bad target.
Steps 8 and 9: Test Wake From Sleep, Hibernate, and Full Shutdown
Test in the order from the power state table, starting with the easiest state. Put the target PC to sleep from the Start menu and wait until the fans and lights settle. Then, from the sender device, run the wake command.
python3 wolctl.py wake deskA successful run sends the packet, polls the check port every two seconds, and reports how long the machine took to answer. The output below is an example of what the console looks like. Your timing depends entirely on your hardware.
[wolctl] sent 102-byte magic packet for desk (AA:BB:CC:11:22:33) to 192.168.1.255
[wolctl] desk is up after 14.2sBack on the target, run powercfg /lastwake and confirm the network adapter is named as the wake source. That is your proof that the packet, not a stray mouse bump, did the job. If Sleep works, you have validated the packet format, the network path, and the adapter settings in one go.
Step 9 repeats the test for the two deeper states. First hibernate the machine with shutdown /h, wait for it to power down, and send the packet again. Then do a full shutdown with shutdown /s /t 0 and repeat. Hibernate usually works whenever Sleep does. A full shutdown is where firmware settings and Fast Startup show their effect, so a failure only in this state points straight back to Steps 3 and 5.
shutdown /h # hibernate (S4)
shutdown /s /t 0 # full shutdown (S5)Write down which states pass. Many people discover that their desktop wakes from all three while their laptop wakes only from Sleep and needs AC power. That is normal and not a bug in your setup. Design your routine around the deepest state that works, and tell yourself that a machine which wakes only from Sleep is still a perfectly useful remote desktop if you configure it to sleep instead of shutting down.
Finally, run a negative test. Send a packet with a wrong MAC, such as changing the last digit, and confirm that nothing happens. That proves the adapter is not waking on random traffic, which is the symptom of Wake on Pattern being left on. If the machine wakes with the wrong MAC, go back to Step 4 and disable pattern wake.
Steps 10 and 11: Add an Inventory, Boot Detection, and a Web Endpoint
The CLI already reads the inventory and waits for the machine to answer, so Step 10 is mostly about using it well. List your hosts and check status without waking anything. The status command exits with code 0 when the host answers and 1 when it does not, which makes it easy to use in shell scripts and cron jobs.
python3 wolctl.py list
python3 wolctl.py status desk
python3 wolctl.py wake nas --no-waitdesk AA:BB:CC:11:22:33 192.168.1.50
nas AA:BB:CC:44:55:66 192.168.1.60
desk: downThe –no-wait flag matters for NAS boxes and servers that take several minutes to come up. Fire the packet, return immediately, and let another job poll for readiness later. For desktops that you want to connect to right away, leave waiting on and chain the connection command afterward, for example python3 wolctl.py wake desk && mstsc /v:192.168.1.50 from a Windows sender.
Step 11 puts a small HTTP face on the tool so a phone shortcut or a home dashboard can trigger a wake. Save the next file as wolweb.py in the same folder. It uses only the Python standard library, requires a secret token in a header, compares the token in constant time, and offers three routes: a host list, a status check, and a wake call.
#!/usr/bin/env python3
"""wolweb: a small token-protected HTTP endpoint around wolctl."""
import hmac
import json
import os
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
import wolctl
TOKEN = os.environ["WOL_TOKEN"].encode()
BIND = os.environ.get("WOL_BIND", "127.0.0.1")
PORT = int(os.environ.get("WOL_PORT", "8099"))
class Handler(BaseHTTPRequestHandler):
def _reply(self, code, body):
data = json.dumps(body).encode()
self.send_response(code)
self.send_header("Content-Type", "application/json")
self.send_header("Content-Length", str(len(data)))
self.end_headers()
self.wfile.write(data)
def _authorized(self):
supplied = self.headers.get("X-Wake-Token", "").encode()
return hmac.compare_digest(supplied, TOKEN)
def do_GET(self):
if not self._authorized():
return self._reply(401, {"error": "unauthorized"})
hosts = wolctl.load_hosts()
if self.path == "/hosts":
return self._reply(200, {"hosts": sorted(hosts)})
if self.path.startswith("/status/"):
name = self.path.rsplit("/", 1)[1]
if name not in hosts:
return self._reply(404, {"error": "unknown host"})
host = hosts[name]
up = wolctl.is_up(host["ip"], host.get("check_port", 3389))
return self._reply(200, {"host": name, "up": up})
return self._reply(404, {"error": "not found"})
def do_POST(self):
if not self._authorized():
return self._reply(401, {"error": "unauthorized"})
hosts = wolctl.load_hosts()
if self.path.startswith("/wake/"):
name = self.path.rsplit("/", 1)[1]
if name not in hosts:
return self._reply(404, {"error": "unknown host"})
host = hosts[name]
size = wolctl.send_magic(
host["mac"], host.get("broadcast", "255.255.255.255"), host.get("port", 9)
)
return self._reply(202, {"host": name, "packet_bytes": size})
return self._reply(404, {"error": "not found"})
def log_message(self, fmt, *args):
print(f"[wolweb] {self.address_string()} {fmt % args}")
if __name__ == "__main__":
print(f"[wolweb] listening on {BIND}:{PORT}")
ThreadingHTTPServer((BIND, PORT), Handler).serve_forever()Generate a long random token and keep it out of the script itself. The service reads it from an environment variable, which the next section stores in a root-owned file.
python3 -c "import secrets; print(secrets.token_urlsafe(32))"Start the endpoint by hand first. It binds to the loopback address unless you set WOL_BIND, which is the safe default. Set the bind address to the sender’s LAN IP only when you are ready to reach it from other devices.
export WOL_TOKEN='paste-the-generated-token-here'
export WOL_BIND=192.168.1.10
python3 wolweb.py[wolweb] listening on 192.168.1.10:8099From any device on the LAN, a single request wakes a machine. The endpoint answers 202 Accepted because it only sends the packet and does not wait for boot. A request without the token gets 401 Unauthorized. I tested both responses on the finished script before including it here.
curl -X POST -H "X-Wake-Token: $WOL_TOKEN" http://192.168.1.10:8099/wake/desk
curl -H "X-Wake-Token: $WOL_TOKEN" http://192.168.1.10:8099/status/desk{"host": "desk", "packet_bytes": 102}
{"host": "desk", "up": true}Phone shortcut apps on both iOS and Android can send that POST request with a custom header, which turns the whole project into a one-tap wake button. That suits a retro-gaming box well, for example the one from our EmuDeck Windows setup guide, which you can wake before a couch session. Security-minded readers should notice that the token travels in clear text over plain HTTP. That is acceptable on a trusted home LAN and unacceptable across the internet, which is why Step 13 uses a VPN instead of a port forward.
Step 12: Run wolweb as a systemd Service on an Always-On Device
A script in a terminal dies when the terminal closes. Put it under systemd so it starts at boot and restarts after a crash. These steps assume a Debian-family Linux system on the sender, such as Raspberry Pi OS or Ubuntu Server, and they should adapt easily to other distributions.
sudo useradd --system --home /opt/wolctl --shell /usr/sbin/nologin wol
sudo mkdir -p /opt/wolctl
sudo cp wolctl.py wolweb.py hosts.json /opt/wolctl/
sudo chown -R root:wol /opt/wolctl
sudo chmod 750 /opt/wolctl
sudo chmod 640 /opt/wolctl/hosts.jsonStore the token and bind settings in an environment file that only root can read. systemd loads it before the service starts, so the token never appears in the unit file or in process listings.
sudo tee /etc/wolctl.env >/dev/null <<'EOF'
WOL_TOKEN=paste-the-generated-token-here
WOL_BIND=192.168.1.10
WOL_PORT=8099
EOF
sudo chmod 600 /etc/wolctl.envNow create the unit file. The hardening lines restrict what the service can touch. NoNewPrivileges blocks privilege escalation, ProtectSystem makes most of the file system read-only to the process, and PrivateTmp gives it its own temporary directory. A wake endpoint needs none of the powers that those lines remove.
[Unit]
Description=wolweb wake endpoint
After=network-online.target
Wants=network-online.target
[Service]
User=wol
WorkingDirectory=/opt/wolctl
EnvironmentFile=/etc/wolctl.env
ExecStart=/usr/bin/python3 /opt/wolctl/wolweb.py
Restart=on-failure
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
[Install]
WantedBy=multi-user.targetSave that as /etc/systemd/system/wolweb.service, then enable and start it. Check the journal to confirm that it bound to the right address.
sudo systemctl daemon-reload
sudo systemctl enable --now wolweb.service
sudo systemctl status wolweb.service --no-pager
journalctl -u wolweb.service -n 20 --no-pagerIf the service fails with a KeyError for WOL_TOKEN, the environment file is missing or unreadable. If it fails to bind, the address in WOL_BIND does not belong to the machine. Fix whichever it is, run sudo systemctl restart wolweb.service, and the status output should show the service as active (running).
The sender needs a stable address, as the target did in Step 1. Give it a DHCP reservation too, otherwise your phone shortcut breaks after the next router reboot. Once the service runs, reboot the sender once to prove it comes back by itself. A wake tool that needs manual care after a power cut defeats its own purpose.
Step 13: Wake Your PC From Outside the House Without Opening Ports
Remote use is where careless setups get hurt. A simple internet-directed broadcast is not universally supported, so sending a magic packet straight from a coffee shop to your home IP often goes nowhere. Worse, forwarding UDP port 9 on your router invites scans and does nothing to authenticate the sender. Remote Internet wake works best through a secure mechanism: a VPN, a suitably configured router, or an always-on LAN device.
The pattern this tutorial recommends is the third one. You already built the always-on LAN device, and it already sends the packet locally, where broadcasts work reliably. All you need is a secure way to reach it. Put the sender behind a VPN such as WireGuard or Tailscale, join your phone or laptop to that VPN, and call the wake endpoint over the private tunnel. Nothing is exposed to the public internet, and the wake token becomes a second layer instead of your only layer.
| Method | Exposed to internet? | Effort | Verdict |
|---|---|---|---|
| Port-forward UDP 9 to the LAN broadcast | Yes, to every scanner | Low, but many routers refuse broadcast forwards | Avoid |
| Router with built-in WoL button | Depends on the vendor’s remote access | Low | Fine if the router’s login is hardened |
| VPN into LAN, then run wolctl | No | Medium | Best default |
| Always-on device plus HTTP endpoint behind VPN | No | Medium, covered by this tutorial | Best for phone shortcuts |
| Cloud WoL service | Third party holds the control path | Low | Convenient, but you trust a vendor |
A concrete example of the VPN approach: install Tailscale or WireGuard on the sender, join your phone to the same network, and point the phone shortcut at the sender’s private VPN address on port 8099. Then bind wolweb to the sender’s LAN address and use a subnet-router feature, or run wolweb on the VPN interface address directly. The wake call travels through the tunnel, wolweb verifies the token, and the sender broadcasts locally.
If your threat model includes a NAS on the same network, take extra care. Synology reportedly published security advisory Synology-SA-26:14 on October 22 and 23, 2026, concerning PHP2Shell vulnerabilities that could permit remote code execution through susceptible DSM packages. That is one more reason never to expose a NAS or its helper services to the internet, even when the goal is as harmless as waking something up. If you want visibility into who talks to your network, our Sysmon setup guide shows how to log process and network activity on Windows hosts.
Finish the build by testing end to end from a different network. Switch your phone to mobile data, connect the VPN, trigger the shortcut, and watch the PC wake. Then disconnect the VPN and confirm that the same request fails. That second result matters just as much as the first, because it proves the endpoint is unreachable without the tunnel.
Common Pitfalls That Break Wake on LAN Windows 11 Setups
Most failed wake on LAN setup attempts trace back to a short list of mistakes. Read through these before you start debugging for hours, because one of them probably describes your situation.
- Testing over Wi-Fi. Conventional WoL remains principally an Ethernet feature, and Wi-Fi wake depends on the adapter, driver, and access point. Start wired.
- Leaving Fast Startup on. A shutdown that is really a hybrid hibernate can leave the adapter unarmed. Disable it, as in Step 5, and test a full shutdown.
- Using the wrong MAC. Docks, USB Ethernet adapters, and second onboard ports each have their own MAC. Wake the one that is actually plugged in.
- Leaving Energy-Efficient Ethernet or ErP on. Both can cut the power the NIC needs to listen. Dell calls out Energy-Efficient Ethernet and Deep Sleep specifically.
- Expecting wake from a dead battery or a switched-off power strip. The NIC needs standby power, so the PSU switch and the wall outlet must be on.
- Sending from a different subnet. Broadcasts do not cross routers by default. VLANs, guest networks, and AP client isolation all block them.
- Trusting a driver that Windows Update installed. The generic driver sometimes hides the wake properties. Install the vendor’s LAN driver.
- Opening UDP 9 to the internet. It rarely works and it widens your attack surface. Use a VPN instead, as in Step 13.
Another quiet pitfall is overconfidence in a single test. A machine that woke once from Sleep proves little about full shutdown, and a machine that woke after a week of uptime proves little about a cold start. Re-run the three-state test after any BIOS update, driver update, or router change, and keep a short note on which states pass.
Troubleshooting: 10 Fixes When the PC Will Not Wake
Work through these in order. Each item names a symptom, the likely cause, and the fix. Numbers 1 through 4 solve the large majority of cases.
- Nothing happens from Sleep. Run
powercfg /devicequery wake_armed. If the NIC is missing, redo Step 4 and use the PowerShell commands. If it is listed, move to the next item. - Sleep works but shutdown does not. Fast Startup or a firmware power-saving mode is the cause. Disable Fast Startup, then re-enter firmware and turn off ErP/EuP, Deep Sleep, and Energy-Efficient Ethernet.
- The NIC link light goes dark on shutdown. The motherboard is cutting standby power. Look for the BIOS options in Step 3, and check that the PSU switch is on. Some boards expose a separate wake from S5 toggle.
- The Power Management tab is missing. The driver does not support power management or loaded incorrectly. Install the manufacturer’s LAN driver, reboot, and look again.
- The machine wakes at random times. Pattern wake is enabled or a device like a mouse or a scheduled task is waking it. Set
-WakeOnPattern Disabledand runpowercfg /lastwaketo name the culprit. - Wake works locally but not through the VPN. Your VPN may not forward broadcasts, which is fine because wolctl broadcasts from the LAN side. Confirm that the wake request reaches the sender and that the sender sits on the same subnet as the target.
- The packet goes out but never arrives. Capture traffic on the sender with
sudo tcpdump -n udp port 9and watch for the 102-byte payload. If nothing appears, the script runs on the wrong interface or the broadcast address is wrong. - A third-party tool wakes the PC but wolctl does not. Compare the MAC in hosts.json against the adapter’s MAC character by character. A single transposed digit produces a valid-looking packet for a card that does not exist.
- The wake succeeds but the check port never answers. The machine is on, but the service is not. Remote Desktop might be off, or the Windows firewall may block the port. Change check_port to a service that you know runs, or raise the timeout.
- Laptop wakes only on AC power. That is normal on many models, and Microsoft’s Surface documentation describes the same AC requirement. Keep the charger connected, or accept Sleep-only wake on battery.
If you reach the end of this list without a result, test with the vendor’s own diagnostics. Dell’s troubleshooting page covers a wider matrix of models, and the WakeMeOnLAN utility makes a good independent sender. When both tools fail, the problem is in the target’s firmware or hardware, and the right next step is a clean BIOS reset followed by Steps 2 and 3 again.
Advanced Tips: Linux Targets, NAS Boxes, Scheduled Wakes, and Logging
Wake a Linux machine or Proxmox host
Linux needs one extra step because the kernel leaves WoL disabled on some drivers by default. Check the current state with ethtool, and enable magic packet wake with the g flag. The setting does not survive a reboot unless you make it persistent, so store it in the connection profile.
sudo ethtool eno1 | grep Wake-on
sudo ethtool -s eno1 wol g
nmcli connection modify "Wired connection 1" 802-3-ethernet.wake-on-lan magicIn ethtool output, the Supports Wake-on line lists what the hardware can do, and the Wake-on line shows what is active. A value of g means magic packet, and d means disabled. Do not copy my interface name, because yours might be enp3s0 or something else entirely.
Wake a NAS, and be careful with vendor claims
The same mechanism applies to a NAS if its hardware, operating system, and network interface support WoL. Do not assume every model does. Synology in particular offers a broad lineup, from older Plus models to the newly announced DiskStation neo+ series, and our research could not confirm that all Synology NAS models support WoL or which power states each model can wake from. Check your model’s documentation, enable WoL in its control panel or firmware, and run the same three-state test.
Schedule wakes with cron or a timer. Scheduling lets a machine wake itself up for a job and go back to sleep afterward. This pattern suits large game updates, backups, and media indexing. On the sender, add a cron line that wakes the desktop at 3 a.m. and lets the launcher patch overnight. Our Battle.net setup walkthrough covers the launcher side of a job like that.
# crontab -e on the sender
0 3 * * * /usr/bin/python3 /opt/wolctl/wolctl.py wake desk --no-waitPair the wake with a shutdown job on the target, such as a Windows scheduled task running shutdown /s /t 0 after the work completes. For a more reliable pair, use powercfg wake timers on the target itself, but only after the network wake works, so you always have a fallback.
Log every wake. A wake endpoint is a power button, so keep a record of who pressed it. The service logs each request to the systemd journal. Add a daily review with journalctl -u wolweb.service --since yesterday. If you run a home lab with several remote machines, forward those logs to a central place so a stolen phone token shows up as unusual wake activity. Rotate the token by editing /etc/wolctl.env and restarting the service.
One more option is to use the same inventory file for a cheap uptime view. Loop over the hosts, run the status command, and print a table. That turns wolctl into a tiny dashboard backend without extra software. For a wider hardware context, browse the rest of the hardware guides on this site for storage, cooling, and handheld setups that pair well with an always-on sender.
The finished project layout. Here is the complete wolctl layout after Step 12. Keep it small and boring, because a wake tool is infrastructure and should not need attention.
| File or setting | Location | Purpose |
|---|---|---|
| wolctl.py | /opt/wolctl/ | CLI that builds and sends the magic packet, then waits for boot |
| hosts.json | /opt/wolctl/ | Inventory of MAC, IP, broadcast address, check port, and timeout |
| wolweb.py | /opt/wolctl/ | Token-protected HTTP endpoint with list, status, and wake routes |
| wolctl.env | /etc/wolctl.env (mode 600) | Token, bind address, and port, kept out of the unit file |
| wolweb.service | /etc/systemd/system/ | Starts the endpoint at boot with hardening options |
| Target settings | Firmware, adapter, and power options | WoL enabled, magic packet only, Fast Startup off |
Maintenance is light. After each Windows feature update, such as the move to 26H2, re-run powercfg /devicequery wake_armed to confirm that the adapter is still armed. After each BIOS update, re-check the firmware options in Step 3, since resets to defaults sometimes revert them. After a router replacement, re-check the DHCP reservations and the broadcast address in hosts.json.
The takeaway: Wake-on-LAN is three small settings and one small packet, and the hard part is the layering. Prove each layer on its own, in the order this tutorial uses, and the failure you hit will name itself.
FAQ: Wake on LAN on Windows 11
Does Wake on LAN work on Windows 11? Yes. Wake on LAN Windows 11 support exists, because Windows 11 supports WoL through compatible wired Ethernet adapters. You enable it in BIOS/UEFI, in the adapter’s power settings, and by sending a correctly addressed magic packet. The steps in this tutorial apply to the current 26H2 release and to 25H2.
Why does Wake on LAN not work after shutdown? The usual causes are Fast Startup, Energy-Efficient Ethernet, and firmware options such as Deep Sleep or ErP that cut standby power to the network card. Disable all three, power-cycle the PC, and test again. Wake from Sleep working while shutdown fails points to exactly those settings.
Can I use Wake on LAN over Wi-Fi? Usually not in a dependable way. Standard WoL is principally an Ethernet feature. Wireless wake exists on some hardware under the name Wake on Wireless LAN, but support depends on the manufacturer, chipset, and driver, so test it before you rely on it.
What port does a magic packet use? Port 9 is the common default, and port 7 also appears in practice. The network card matches the payload pattern and not the port number, so what matters is that the UDP packet reaches the card’s network segment with the correct MAC address inside.
How do I wake my PC from outside my home network? Reach an always-on device inside your LAN through a VPN, then send the magic packet from there. A plain internet-directed broadcast is not universally supported, and forwarding UDP ports from your router exposes you to scans. This tutorial’s Step 13 shows the VPN pattern.
Is Wake on LAN a security risk? A magic packet carries no password, so anyone who can send one on your LAN can wake the machine. Keep the wake path private, put any HTTP endpoint behind a token and a VPN, and never expose the packet port to the internet. Waking a PC does not log anyone in, but it does give an attacker a running target.
Do all NAS devices support Wake on LAN? No. Support depends on the device’s hardware, operating system, and network interface, and you should not assume that every model from a vendor, including Synology, supports it. Check your model’s documentation and run the Sleep, Hibernate, and shutdown tests before relying on it.
