How to Turn Steam On When Your Computer Is Off

Beginner40-60 minutesWindowsSteam

A computer that is powered off is not, from the perspective of its network interface, entirely absent. The network interface card retains power on circuits that monitor for a specific packet — the Magic Packet — even while the rest of the machine sits dark. When the correct packet arrives at the network interface, the card asserts a signal on the motherboard's power rail and the machine begins its POST sequence. The BIOS executes. Windows loads. Steam launches. Games update overnight. The machine is ready.

This is Wake-on-LAN. It has existed as a standard since 1996. It is implemented in virtually every desktop motherboard manufactured in the last fifteen years. It works, under the right conditions, with the reliability of hardware. It does not require subscriptions, third-party software, or persistent cloud agents. It requires only correct configuration of the network interface, the BIOS, the Windows power management stack, and the machine that sends the packet.

There is a second path: the BIOS real-time clock alarm. Some motherboards can be configured to power on at a scheduled time with no network involved. No packet sender. No remote machine. The RTC alarm is absolute — the machine powers on when the clock reaches the specified time, regardless of network state, regardless of whether any other machine is awake.

This article covers both paths, plus the configuration of Steam's auto-start behavior so that Steam launches as soon as Windows is ready, without user interaction. The 57 Studios™ contributor cohort uses this documented configuration for the overnight Workshop download cycle: machines wake at 2:00 AM, Steam starts, downloads complete, machines remain on until manually shut down or return to sleep at a configured idle timeout. This is not theoretical. It is a documented operational pattern used for Unturned™ mod content delivery.

Prerequisites

• A desktop computer (laptops have WoL support but often behave inconsistently due to power adapter state and lid-close settings)
• A motherboard with Wake-on-LAN support (present on virtually all desktop motherboards manufactured after 2008)
• A network interface card connected to the router via Ethernet cable (Wi-Fi WoL is supported on some adapters but significantly less reliable than Ethernet)
• BIOS/UEFI access (the ability to enter the BIOS setup screen at POST)
• Steam installed, as documented in How to Install Steam
• Administrator access in Windows
• For WoL: a second device (phone, laptop, or remote machine) to send the Magic Packet

What you'll learn

• How the ACPI power states (S0 through S5) define what "off" means and how they determine WoL eligibility
• How to enable Wake-on-LAN in the BIOS/UEFI firmware
• How to configure the Windows network adapter power management settings to preserve WoL capability across sleep states
• How the Magic Packet is structured and how it reaches the sleeping network interface
• How to configure and send a WoL Magic Packet from another device on your local network
• How to configure a WoL Magic Packet sender across the internet (remote WoL with port forwarding)
• How to configure a BIOS RTC wake alarm for scheduled, networkless boot
• How IPMI/BMC and remote KVM solutions differ from WoL and when they are appropriate
• How to configure Steam's auto-start setting so Steam launches on boot without user interaction
• The 57 Studios overnight-download wake cycle: documented configuration and observed behaviour

Background

ACPI power states and what "off" means

The Advanced Configuration and Power Interface specification defines a hierarchy of system power states called S-states. The S-state your machine is in when it is "off" determines whether WoL is possible and whether the BIOS RTC alarm can fire.

ACPI State	Common name	Description	WoL possible	RTC alarm possible
S0	On	Fully operational	Yes (already on)	Yes
S1	Power on suspend	CPU and RAM powered, clock gated	Yes	Yes
S2	(Rare)	CPU off, RAM on	Yes	Yes
S3	Sleep / Suspend-to-RAM	CPU and most devices off; RAM retains state	Yes	Yes
S4	Hibernate	Machine off; RAM image written to disk	Conditional	Yes
S5	Soft off / Shutdown	Machine powered down via OS; standby power remains	Yes (with full S5 WoL)	Yes
G3	Mechanical off	Power cord disconnected	No	No

The distinction between S3 (sleep), S4 (hibernate), and S5 (shutdown) is critical because it determines which power path the network interface retains and what the machine must do when woken.

S3 sleep is the state your machine enters when you click Start → Sleep. RAM remains powered; the machine can wake in under five seconds by restoring the RAM image. WoL from S3 is universally supported and the most reliable WoL path.

S5 shutdown is the state your machine enters when you click Start → Shut down. The OS is fully closed. The machine is dark except for standby power. WoL from S5 requires that your BIOS has WoL-from-S5 support enabled and that your network adapter supports powered-down WoL. Not all combinations work from S5; testing is required.

G3 mechanical off (power cord disconnected) is absolute. No packet reaches the interface. No clock runs. WoL and RTC alarms are physically impossible.

Did you know?

The capacitors on a modern ATX motherboard retain enough charge after a controlled S5 shutdown to keep the WoL circuits alive for several hours, even after the power supply's soft-off rail is asserted. This is why you can pull the power cord from a machine in S5 and, after plugging it back in, the machine will not self-power-on: the WoL circuit resets when the rail drops to true zero. The machine must be in a state where the PSU continues to provide 5V standby current for WoL to remain active.

Part 1: Wake-on-LAN configuration

Step 1: Enable WoL in BIOS/UEFI

Enter the BIOS/UEFI setup at POST by pressing the appropriate key for your motherboard (typically Del, F2, or F12 — the specific key is displayed briefly during the POST splash screen and is documented in your motherboard manual).

Navigate to the power management section. The exact location varies by motherboard vendor:

Motherboard vendor	Typical BIOS navigation path	Setting name
ASUS	Advanced → APM Configuration	Power On By PCI-E / WoL
MSI	Settings → Advanced → Power Management	WoL (S3/S4/S5)
Gigabyte	Settings → Platform Power	Wake on LAN
ASRock	Advanced → ACPI Configuration	Wake-Up By PCIE Device
Biostar	Advanced → ACPI Configuration	Wake-Up On LAN

The setting may be labeled "Wake on LAN", "WoL", "Power On By PCI-E", or "Wake by Onboard LAN". Enable it. On some boards you will find separate toggles for WoL from S3, S4, and S5 independently. Enable the states you intend to use.

Common mistake

On some ASUS motherboards, the WoL setting is hidden under "Restore on AC Power Loss" as a secondary dependency. If enabling "Wake on LAN" has no effect, verify that "Restore on AC Power Loss" is not set to "Power Off", which overrides the WoL configuration for S5 wake scenarios.

Save and exit the BIOS. The machine reboots into Windows.

Step 2: Configure the Windows network adapter

Windows has its own power management layer that independently controls whether the network adapter remains powered during sleep and whether it can receive WoL packets. The BIOS enables the hardware path; Windows must also enable the software path.

Open Device Manager

Press Win + X and click Device Manager. Expand the Network adapters section. Locate your Ethernet adapter. Right-click it and click Properties.

Configure power management settings

Navigate to the Power Management tab. Verify the following checkboxes:

Checkbox	Required state
Allow the computer to turn off this device to save power	Can be checked; does not affect WoL
Allow this device to wake the computer	Must be checked
Only allow a magic packet to wake the computer	Recommended: checked

The "Allow this device to wake the computer" checkbox is the critical one. Without it, Windows does not pass WoL power events from the adapter to the ACPI layer.

Configure advanced adapter properties

Navigate to the Advanced tab in the same Properties dialog. Locate the following properties and set them as documented:

Property	Recommended value	Notes
Wake on Magic Packet	Enabled	Primary WoL trigger
Wake on Pattern Match	Optional	Used for other wake triggers; not required
Wake on LAN	Enabled	Must match BIOS setting
Energy Efficient Ethernet	Disabled	EEE can interfere with WoL packet reception
Advanced EEE	Disabled	Same as above
Power Down Speed on Link Down	Disabled	Disabling preserves powered state when link drops briefly

The Energy Efficient Ethernet settings are a frequent and non-obvious source of WoL failures. EEE places the physical layer in a low-power state when no traffic is detected, and on some adapters this low-power state is deep enough that the WoL circuits do not respond to the Magic Packet. Disabling EEE restores full WoL reliability.

# Verify current power management state of Ethernet adapter via PowerShell
Get-NetAdapterPowerManagement -Name "Ethernet*" |
    Select-Object Name, WakeOnMagicPacket, WakeOnPattern

Best practice

After changing power management settings in Device Manager, verify the changes persisted by reopening the Properties dialog. Some Windows updates and driver updates silently reset power management settings to defaults. If WoL stops working after a Windows update, the first diagnostic step is to verify that the adapter power management settings remain as configured.

Step 3: Identify the machine's MAC address

The Magic Packet contains the target machine's MAC address repeated sixteen times. You must know the MAC address of the Ethernet adapter to construct or configure the packet sender.

# Get the MAC address of all Ethernet adapters
Get-NetAdapter | Where-Object { $_.MediaType -eq "802.3" } |
    Select-Object Name, MacAddress, Status

Record the MAC address in the format XX:XX:XX:XX:XX:XX or XX-XX-XX-XX-XX-XX (both are equivalent). The MAC address is also printed on a sticker on the network adapter itself and on the motherboard near the Ethernet port on many boards.

Step 4: Configure a static ARP entry (recommended)

The Machine running the WoL sender needs to know how to route the Magic Packet to the sleeping machine. In S3/S5, the sleeping machine has no ARP presence — it cannot respond to ARP queries because its CPU is off. The sender must therefore use a broadcast address or a static ARP entry.

Option A: Broadcast (simple, works on same subnet)

Most WoL senders default to sending to the broadcast address 255.255.255.255 or the subnet's directed broadcast address (192.168.1.255 for a 192.168.1.0/24 network). The sleeping machine's NIC receives the broadcast regardless of whether it has an ARP entry. This is the standard method and requires no configuration.

Option B: Static ARP entry (more reliable on some router configurations)

Some managed routers suppress or rate-limit broadcast traffic in ways that prevent the Magic Packet from reaching the sleeping adapter. Configuring a static ARP entry on the sender machine binds the target machine's IP address to its MAC address, enabling unicast delivery instead of broadcast.

# Add a static ARP entry on the sender machine (run as Administrator)
# Replace 192.168.1.100 with the sleeping machine's usual IP address
# Replace AA-BB-CC-DD-EE-FF with its MAC address
netsh interface ip add neighbors "Ethernet" "192.168.1.100" "AA-BB-CC-DD-EE-FF"

Best practice

Configure a DHCP reservation for the target machine on your router so that the machine always receives the same IP address. A DHCP reservation binds a specific IP address to the machine's MAC address in the router's DHCP server configuration. With a reservation in place, the static ARP entry will remain valid across DHCP lease renewals.

Step 5: Construct and send the Magic Packet

The Magic Packet is a broadcast frame containing the target machine's MAC address repeated sixteen times, preceded by a synchronisation stream of six bytes of 0xFF. The total packet is 102 bytes.

Using PowerShell to send a Magic Packet

function Send-WakeOnLan {
    param (
        [Parameter(Mandatory)]
        [ValidatePattern('^([0-9A-Fa-f]{2}[:-]){5}[0-9A-Fa-f]{2}$')]
        [string]$MacAddress,

        [string]$BroadcastAddress = '255.255.255.255',

        [int]$Port = 9
    )

    # Parse MAC address to byte array
    $macBytes = $MacAddress -split '[:-]' | ForEach-Object { [Convert]::ToByte($_, 16) }

    # Construct Magic Packet: 6 x 0xFF + 16 x MAC
    $packet = [byte[]]::new(102)
    0..5 | ForEach-Object { $packet[$_] = 0xFF }
    1..16 | ForEach-Object {
        $offset = $_ * 6
        $macBytes | ForEach-Object -Begin { $i = 0 } -Process {
            $packet[$offset + $i] = $_
            $i++
        }
    }

    # Send via UDP broadcast
    $udpClient = [System.Net.Sockets.UdpClient]::new()
    $udpClient.EnableBroadcast = $true
    $endpoint = [System.Net.IPEndPoint]::new([System.Net.IPAddress]::Parse($BroadcastAddress), $Port)
    $udpClient.Send($packet, $packet.Length, $endpoint) | Out-Null
    $udpClient.Close()

    Write-Host "Magic Packet sent to $MacAddress via $BroadcastAddress`:$Port"
}

# Usage — replace with your target machine's MAC address
Send-WakeOnLan -MacAddress "AA:BB:CC:DD:EE:FF"

The standard port for WoL Magic Packets is UDP port 9 (the discard port). Some implementations use port 7 or a configurable custom port. The port choice does not affect delivery on a local network; both ports are equally valid. When routing WoL packets across the internet (see the next section), the port must match the forwarding rule configured on the router.

Mobile WoL sender apps

From a phone on the same Wi-Fi network, several apps provide a graphical WoL interface:

Platform	App	Notes
Android	Wake On LAN (by Bogdan Nistor)	Stores named device profiles
Android	Network Tools	General networking toolkit with WoL support
iOS	WakeOnLAN – Wake Computers	Simple MAC-address entry
iOS	Network Radar	Full network scanner with WoL

These apps send the same Magic Packet as the PowerShell function above. Their advantage is convenience for the overnight-download use case: you can trigger a wake from your phone the night before without touching the keyboard.

Step 6: Configure WoL across the internet (optional)

If you want to wake your machine from outside your home network, you must configure port forwarding on your router to forward incoming UDP packets on the WoL port to the sleeping machine's IP address.

Common mistake

When configuring WoL port forwarding, forward the port to the broadcast address of your LAN subnet (192.168.1.255 for a 192.168.1.0/24 network), not to the target machine's specific IP address. The sleeping machine does not have an active ARP entry, so a packet forwarded to a specific IP may be dropped by the router's ARP cache timeout logic. Broadcasting ensures the packet reaches the NIC regardless.

Router configuration field	Value
Protocol	UDP
External port	9 (or your chosen custom port)
Internal IP	Subnet broadcast address (e.g., 192.168.1.255)
Internal port	9 (or same as external)

After configuring port forwarding, send the Magic Packet from outside the network by targeting your router's public WAN IP address with the WoL port. The packet travels from the internet to your router, the router forwards it to the broadcast address, and the sleeping machine's NIC receives it.

Did you know?

Your router's public WAN IP address may change if you have a dynamic IP address from your ISP. A dynamic DNS (DDNS) service such as DuckDNS (free) or No-IP can provide a stable hostname that resolves to your current WAN IP address. Configure the DDNS client on your router (most consumer routers have native DDNS support) and target the DDNS hostname in your WoL sender app for internet-based wake events.

Part 2: BIOS RTC wake alarm for scheduled boot

The BIOS real-time clock (RTC) alarm is an independent mechanism from WoL. It does not require a network, a sender device, or any external trigger. The BIOS maintains a clock that runs continuously on standby power. You configure an alarm time, and when the clock reaches that time, the BIOS asserts the power signal and the machine boots — regardless of network state, regardless of whether any other machine is awake or sending packets.

Step 1: Enter BIOS/UEFI and locate the RTC alarm setting

Enter the BIOS setup at POST. Navigate to the power management section. Look for an option variously labeled:

Motherboard vendor	RTC alarm setting name
ASUS	APM Configuration → Resume By RTC Alarm
MSI	Settings → Advanced → Power Management → RTC Wake-up
Gigabyte	Settings → Platform Power → RC6 (Render Standby) / Wake Up event
ASRock	Advanced → ACPI Configuration → Power-On by RTC
Biostar	Power → RTC Wake

Step 2: Configure the alarm

Enable the RTC alarm setting. The configuration typically offers two modes:

Mode	Description	Typical syntax
Daily at time	Wake every day at a specific time	HH:MM:SS (24-hour)
One-time at date and time	Wake once at a specific date and time	DD/MM/YYYY HH:MM:SS

For the 57 Studios overnight-download cycle, the recommended configuration is Daily at 02:00:00. This triggers a wake at 2:00 AM every night, which provides a reliable window for Steam to download Workshop updates before the working session begins the following morning.

Best practice

Configure the RTC alarm in 24-hour format regardless of your locale preference. Most BIOS implementations that support RTC alarms use 24-hour format internally, and entering a time in 12-hour format without AM/PM disambiguation can produce unpredictable results (for example, "2:00" being interpreted as 2:00 AM, 2:00 PM, or causing the alarm to not fire at all, depending on the BIOS implementation).

Step 3: Save and verify

Save the BIOS settings and exit. Power the machine off. Wait until the clock passes the configured alarm time. Observe whether the machine powers on. If it does not, the most common causes are:

Cause	Diagnosis	Resolution
Machine did not reach S5 before the alarm time	Machine never fully powered down	Ensure full shutdown before alarm fires
BIOS RTC not enabled correctly	Machine does not power on	Re-enter BIOS and re-verify the setting
Standby power lost	Machine wakes with BIOS reset	Check that PSU is switched on and cord is seated
BIOS clock incorrect	Machine wakes at wrong time	Correct BIOS clock; sync to NTP on next boot

Part 3: IPMI, BMC, and remote KVM (advanced)

Wake-on-LAN and RTC alarms are sufficient for consumer and prosumer hardware. Enterprise-grade hardware (server motherboards, workstation boards in the E-series or Threadripper Pro line) often includes an IPMI (Intelligent Platform Management Interface) controller or a BMC (Baseboard Management Controller) — a physically separate processor on the motherboard that manages power, fan control, and health monitoring independently of the main CPU.

The BMC maintains its own network connection on a dedicated management port. It is powered whenever the PSU is connected to mains power, regardless of the main machine's power state. From the BMC, you can:

• Power on, power off, and reset the machine
• View a serial console of the machine's POST output
• Mount a virtual disk or ISO image
• Reconfigure BIOS settings
• Monitor hardware health (temperatures, fan speeds, voltages)

BMC access is the most complete remote power control available. If your hardware includes IPMI, the BMC approach is strictly more capable than WoL. However, configuring IPMI is beyond the scope of this article because consumer Steam users almost never encounter IPMI-capable hardware.

If you are a 57 Studios contributor running a dedicated mod-development server on a machine with IPMI, consult the IPMI configuration documentation provided by your board vendor (typically available as an IPMI/BMC User's Guide in PDF format from the vendor's support page).

Part 4: Steam auto-start on boot configuration

With WoL or the RTC alarm configured, the machine will power on at the scheduled time or in response to the Magic Packet. Steam must then launch automatically without user interaction.

Step 1: Configure Steam to launch at Windows startup

Open the Steam client. Navigate to Steam → Settings → Interface. Locate the setting "Run Steam when my computer starts" and enable it.

With this setting enabled, Steam adds itself to the Windows startup list. Every time Windows starts, Steam launches automatically as part of the user session startup sequence.

Common mistake

The Steam auto-start setting only takes effect after the user's Windows session is active. If Windows requires a login password before the desktop is available, Steam will not launch until after the user logs in. For the overnight-download use case, you must either configure Windows auto-login (which has security implications on a shared or internet-accessible machine) or use a dedicated scheduled task that does not depend on the user session. The auto-login configuration is documented in Appendix A.

Step 2: Verify the startup entry

# Verify Steam appears in the startup list
Get-CimInstance Win32_StartupCommand | Where-Object { $_.Name -like "*Steam*" } |
    Select-Object Name, Command, Location

The output should include a Steam entry with the command path pointing to Steam.exe. If no entry appears, return to the Steam Settings → Interface page and confirm the setting is enabled, then close and relaunch Steam to allow the setting to take effect.

Step 3: Configure Steam to begin downloading immediately on launch

Ensure that Steam's download settings do not impose a schedule that would delay downloads after the overnight wake. Navigate to Steam → Settings → Downloads and verify:

Setting	Required state for overnight downloads
Throttle downloads while streaming	Off
Allow downloads during gameplay	On
Automatically restart Steam if needed to complete update	On
Schedule auto-updates	Off (or set window to include overnight hours)
Allow downloads when game is running	On

If you have a scheduled download window configured, ensure the window includes the RTC alarm time. A 2:00 AM alarm with a download window of 1:00 AM–6:00 AM covers the overlap.

The 57 Studios overnight-download wake cycle

The 57 Studios contributor cohort has operated a documented overnight-download wake cycle since early access to large Unturned Workshop content packs began requiring substantial download times. The cycle is documented here as a complete reference configuration.

Hardware profile

Component	Specification
Machine role	Dedicated Unturned mod development workstation
Sleep state	S5 (full shutdown) — preferred over S3 for this use case
Network	Ethernet; router configured with DHCP reservation
WoL	Enabled in BIOS; Windows adapter configured; EEE disabled
RTC alarm	Configured for 02:00 daily
Trigger method	RTC alarm (primary); WoL fallback via phone app

The choice of S5 (shutdown) rather than S3 (sleep) is deliberate. S3 sleep leaves the machine in a state that may accumulate RAM soft errors and OS state drift over multiple sleep cycles without reboot. For a machine that processes mod file operations and Workshop publishing, the 57 Studios cohort prefers the clean state a full boot provides. The RTC alarm's ability to fire from S5 makes this preference operationally equivalent to S3 for the wake-cycle use case.

Wake cycle sequence

Observed behaviour metrics (57 Studios cohort)

Metric	Observed value	Notes
Time from RTC alarm to POST complete	12–18 seconds	Depends on hardware; NVMe POST adds ~2s
Time from POST to Windows desktop	40–60 seconds	NVMe SSD; Windows 11
Time from desktop to Steam login window	8–15 seconds	Startup list processing time
Time from Steam login to download start	15–25 seconds	Steam update check + CDN manifest fetch
Total wake-to-download-begin time	75–120 seconds	All steps combined
Reliability of RTC alarm (S5 → S0)	High	Near 100% in observed cycles
Reliability of WoL from S5	Moderate	80–90%; depends on adapter and BIOS combination
Reliability of WoL from S3	Very high	95%+ consistently

The reliability differential between WoL from S5 and WoL from S3 is the reason the 57 Studios cohort uses the RTC alarm as the primary mechanism. The RTC alarm fires from S5 with near-perfect reliability; WoL from S5 requires more precise hardware alignment.

Best practice

Test your WoL or RTC configuration during a period when you are present and can observe the result. Configure the alarm for five minutes in the future, shut the machine down, and watch whether it powers on at the correct time. Do not rely on an untested configuration for an unattended overnight cycle; a failed wake means no updates downloaded, and the failure may not be apparent until the next working session.

Network-stack WoL behaviour across S-states

The network interface card's internal firmware handles WoL packet detection differently depending on the machine's ACPI state. The distinctions matter because they affect packet timing requirements and reliability.

S3 (sleep) WoL network stack behaviour

In S3, the main CPU is off but RAM retains its contents and the PCIe bus remains powered at low speed. The network adapter's firmware actively monitors the physical layer for incoming packets matching the Magic Packet pattern. The detection hardware runs at full receive speed. The window between packet arrival and power-on assertion is typically under 100 milliseconds.

In S3, the adapter retains the ARP cache that was populated before sleep. This means a Magic Packet sent as a unicast to the machine's IP address will reach the adapter even without a static ARP entry on the sender, because the router's ARP cache typically retains the entry for several minutes to hours.

S5 (shutdown) WoL network stack behaviour

In S5, the RAM is cleared and the PCIe bus is in a lower-power state. The adapter operates from standby power and runs a simplified firmware path. The Magic Packet detection hardware is the same circuit as in S3, but the PCIe interface operates at reduced speed, and on some hardware combinations the physical layer's auto-negotiation speed drops from 1 Gbps to 100 Mbps in S5.

More importantly, the router's ARP cache for the target machine has expired (the machine has been off for hours), which means a unicast Magic Packet cannot reach the adapter via the router's normal forwarding. Broadcast delivery is required from S5.

Did you know?

The physical layer negotiation speed drop in S5 on some adapters (from 1 Gbps to 100 Mbps) is a subtle source of WoL failures on networks where the switch port has auto-negotiation disabled and is manually set to 1 Gbps. If WoL works from S3 but not S5, checking the switch port speed negotiation is a productive diagnostic step.

S4 (hibernate) WoL network stack behaviour

S4 (hibernate) occupies a middle ground. The machine has written its RAM image to disk and powered off, but on many hardware combinations the power state is still considered "powered" by the PSU (the standby rail remains active). WoL from S4 depends heavily on whether the BIOS firmware treats the hibernated state as WoL-eligible. On most modern consumer boards it is. The BIOS setting typically called "WoL from S4" or "Wake from Hibernate" controls this.

Frequently asked questions

Does WoL work over Wi-Fi?

Some Wi-Fi adapters support a variant of WoL where they maintain a low-power receive state during sleep. However, the reliability and support are significantly lower than Ethernet-based WoL. The IEEE 802.11 standard does not mandate WoL support, and the implementation quality varies widely between adapter vendors. For the overnight-download use case, Ethernet is strongly recommended. If Ethernet is not physically feasible, a Powerline adapter (which runs over the home's electrical wiring and provides an Ethernet jack at the destination) is a reliable alternative to a direct Ethernet run.

My computer was off and I sent a Magic Packet but it did not wake. Why?

The most common causes in descending order of frequency:

Cause	Diagnostic	Fix
WoL not enabled in BIOS	Enter BIOS and check	Enable WoL in BIOS
Windows adapter WoL not enabled	Device Manager → Power Management	Enable "Allow this device to wake the computer"
EEE interfering with WoL	Advanced tab in adapter properties	Disable Energy Efficient Ethernet
Machine in G3 (power cord disconnected or PSU switch off)	Physical inspection	Reconnect power; verify PSU switch is on
Broadcast blocked by router	Test with static ARP	Configure static ARP or check router broadcast settings
Wrong MAC address in packet	Verify with Get-NetAdapter	Correct the MAC address
Machine reached WoL-ineligible state	S4 on non-supporting hardware	Switch to S3 sleep or configure S5 WoL

Can I wake a machine from sleep without knowing its MAC address?

No. The Magic Packet requires the target machine's MAC address. The MAC address is a hardware identifier assigned to the network adapter and is required to construct a valid Magic Packet. Every method of WoL — mobile apps, router-based WoL, PowerShell scripts — requires the MAC address to be known in advance.

What is a "Magic Packet" exactly?

A Magic Packet is a UDP datagram. Its payload is exactly 102 bytes: six bytes of 0xFF (the synchronisation stream) followed by the target machine's six-byte MAC address repeated exactly sixteen times (16 × 6 = 96 bytes; 6 + 96 = 102 bytes total). The repetition pattern is what distinguishes a Magic Packet from random network traffic. The NIC's WoL detection hardware scans incoming packets for this specific pattern against the adapter's own MAC address. When a match is found, the NIC asserts the wakeup signal.

Does WoL work if the router is off?

No. If the router is off, the switch fabric that delivers packets between machines on the LAN is not operational. The Magic Packet cannot reach the sleeping machine's switch port, and therefore cannot reach the adapter. The router must be operational for WoL to work. This is worth noting because "turn off everything" sometimes includes the router; for the overnight-download use case, the router must remain on.

What if I want to wake my machine but I am not on the same local network?

Configure port forwarding on your router for UDP port 9 (or your chosen WoL port), targeting the subnet's broadcast address. Obtain your router's public WAN IP address (or configure DDNS for a stable hostname). From outside the network, target the WAN IP in your WoL sender app. The packet will travel over the internet to your router, which will forward it to the broadcast address, and the sleeping machine's NIC will receive it.

Does the RTC alarm work if the power went out while the machine was off?

Depends on the BIOS clock's battery backup. Every motherboard has a CR2032 coin cell battery that maintains the RTC clock (and BIOS settings) when mains power is absent. If the power outage is brief and the coin cell is healthy, the clock continues running through the outage and the alarm fires at the correct time when power is restored. If the coin cell is dead or the outage is very long, the BIOS clock may reset to its default date (often January 1, 2000), which means the alarm will not fire at the correct time and the BIOS clock must be corrected manually.

Can I have both WoL and an RTC alarm configured simultaneously?

Yes. The two mechanisms are independent. If both are enabled, whichever event fires first will wake the machine. For the 57 Studios overnight cycle, having both configured provides redundancy: if the RTC alarm fails (for example, due to a standby power disruption that reset the BIOS), the Magic Packet can be sent manually from a phone as a fallback.

How do I stop the machine from waking at the RTC alarm time on days I do not want downloads?

Two approaches: disable the RTC alarm in the BIOS on those days (requires entering BIOS, which is inconvenient), or configure a Windows scheduled task that shuts the machine down shortly after it wakes if a specific condition is met (for example, if no user is logged in after five minutes). The latter is more elegant for automation; see Appendix B for the scheduled-task configuration.

Why does Steam sometimes not launch even though Windows booted?

The Steam startup entry depends on the user's Windows session being active. If Windows is at the login screen (because auto-login is not configured), Steam will not launch until someone enters the password and the desktop loads. For unattended overnight cycles, auto-login is required. See Appendix A.

What is the difference between S3 sleep and S4 hibernate for this use case?

S3 sleep keeps RAM powered; the machine resumes in under five seconds with its exact prior state. S4 hibernate writes the RAM to disk and powers off; the machine takes thirty to sixty seconds to resume because it must read the RAM image back from disk. For WoL purposes, S3 is more universally reliable and faster to wake. For the 57 Studios overnight-download cycle using the RTC alarm (where wake speed matters less than clean state), S5 full shutdown is preferred because it provides a clean OS state for each cycle. S4 hibernate is generally the least desirable option for this use case.

Does the machine need to be connected to the internet for WoL to function?

The machine itself does not need internet access to receive a WoL Magic Packet — the packet is delivered at the Ethernet hardware layer before any OS or application stack is involved. However, for Steam to download Workshop updates after waking, the machine does need internet access. Ensure your LAN's gateway (router) is connected to the internet and that the machine's IP address (via DHCP reservation) is reachable before configuring the overnight cycle.

How do I prevent Steam from downloading during the wrong hours and only download during the overnight window?

In Steam Settings → Downloads, enable the scheduled download window and configure it to your preferred overnight hours (for example, 1:00 AM to 6:00 AM). Steam will queue downloads and only transfer during that window. Combined with the RTC alarm at 2:00 AM and the auto-start configuration, this creates a fully automated overnight-download cycle where the machine wakes, Steam starts, and downloads begin within the configured window without any user action.

Best practices

• Test your WoL or RTC alarm configuration manually before relying on it for unattended overnight cycles
• Configure a DHCP reservation for the target machine on your router so its IP address is stable
• Disable Energy Efficient Ethernet on the target machine's network adapter to ensure WoL packet reception
• Use the RTC alarm as the primary overnight-wake mechanism; it is more reliable from S5 than WoL
• Keep the router powered on for WoL; the router's switch fabric is required for packet delivery
• Configure Windows auto-login if the overnight cycle must be fully unattended (see Appendix A)
• Set Steam's scheduled download window to your overnight hours so downloads only run when the machine is intentionally awake
• Verify on the first morning after configuration that downloads were processed as expected
• Document the MAC address of your target machine in a durable location (password manager, physical label on the machine) for use in WoL sender configuration

Appendix A: Configuring Windows auto-login for unattended overnight cycles

For Steam to launch automatically after a WoL or RTC alarm boot, the Windows user session must start without requiring a password. Windows auto-login configures the session to start automatically for a designated user account.

Common mistake

Auto-login reduces the security of the Windows account against physical access. Only configure auto-login on machines in a physically secure location, or on machines that do not store sensitive credentials or data you cannot risk being accessed by anyone who can reach the keyboard.

Method: netplwiz

1. Press Win + R and type netplwiz, then press Enter.
2. In the User Accounts dialog, select the user account that should auto-login.
3. Uncheck the checkbox labeled "Users must enter a user name and password to use this computer."
4. Click Apply. A dialog prompts for the account's password.
5. Enter the password and click OK.
6. Click OK to close the User Accounts dialog.

Windows will now log in to the selected account automatically on each boot, allowing the Steam auto-start to proceed without user intervention.

Verifying auto-login

Restart the machine. If it boots directly to the desktop without a login prompt, auto-login is configured correctly.

Appendix B: Scheduled task to shut down the machine after overnight downloads

For users who want the machine to shut itself down after overnight downloads complete rather than remaining on all day, a Windows scheduled task can trigger an automatic shutdown based on a time condition.

# Create a scheduled task that shuts the machine down at 6:00 AM
# (assumes overnight downloads are complete by 6:00 AM)
# Run this in an elevated PowerShell session

$action = New-ScheduledTaskAction -Execute "shutdown.exe" -Argument "/s /f /t 60"
$trigger = New-ScheduledTaskTrigger -Daily -At "06:00AM"
$settings = New-ScheduledTaskSettingsSet -ExecutionTimeLimit (New-TimeSpan -Minutes 5)
$principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -LogonType ServiceAccount -RunLevel Highest

Register-ScheduledTask `
    -TaskName "SteamOvernightShutdown" `
    -Action $action `
    -Trigger $trigger `
    -Settings $settings `
    -Principal $principal `
    -Description "Shuts down machine after Steam overnight download window"

This task runs as SYSTEM, does not require a user to be logged in, and initiates a forced shutdown (with 60-second countdown) at 6:00 AM. Adjust the time to match your download window end.

To remove the task:

Unregister-ScheduledTask -TaskName "SteamOvernightShutdown" -Confirm:$false

Appendix C: Diagnosing a failed WoL or RTC wake event

When the machine does not wake as expected, the following diagnostic sequence identifies the failure point.

Step 1: Confirm the machine is in a WoL-eligible power state

WoL and RTC alarms cannot fire from G3 (power cord disconnected or PSU main switch in the Off position). Confirm the PSU is plugged in and the PSU switch (the rocker switch on the back of most ATX power supplies) is in the On position. The machine must reach at least S5 via a controlled OS shutdown, not by pulling the power cord.

Step 2: Confirm BIOS settings survived the shutdown

Some BIOS configurations are reset if CMOS power is lost (dead coin cell, or a CMOS-clear jumper being triggered). Enter the BIOS and re-verify that WoL and/or the RTC alarm settings are still as configured. If they have been reset to defaults, the coin cell may need replacement (a standard CR2032, available at any hardware or electronics store for under two dollars).

Step 3: Confirm the Magic Packet was sent and received

On the sender machine, run a packet capture to verify the Magic Packet is actually being transmitted. Using PowerShell with the Npcap or WinPcap library installed, or using Wireshark with its capture filter set to udp.port == 9, observe whether the outgoing packet matches the expected Magic Packet structure (102 bytes, starts with FF:FF:FF:FF:FF:FF, followed by the target MAC repeated sixteen times).

Step 4: Confirm the packet reached the target subnet

If the sender is on the same subnet as the target machine, a successful packet capture on the sender is sufficient to confirm delivery (broadcasts are not routed; they stay on the subnet). If the sender is on a different subnet or across the internet, use a machine on the same subnet as the target to run a capture and confirm the packet is arriving at the LAN.

WoL failure point	Diagnosis method	Resolution
BIOS not enabling WoL	BIOS audit	Enable setting; verify it persists
Windows adapter not enabling WoL	Device Manager audit	Enable Power Management checkboxes
EEE interference	Adapter Advanced tab audit	Disable EEE and Advanced EEE
Packet not sent by sender	Wireshark capture on sender	Fix sender app configuration
Packet not reaching target	Wireshark capture on LAN	Fix broadcast/routing configuration
PSU in G3	Physical inspection	Reconnect power and PSU switch
CMOS reset	BIOS audit	Replace coin cell; reconfigure
Router blocking broadcast	Router logs	Configure static ARP or use directed broadcast

Cross-references

• How to Close Steam Completely from the System Tray — the prior article; documents the complete Steam shutdown procedure used at the end of each session
• How to Install Steam — foundational article covering Steam's installation and startup configuration
• How to Install Unturned — the next article in the sequence; the first step in the Unturned setup flow

Next steps

With your machine configured for remote or scheduled waking and Steam set to auto-start, continue to How to Install Unturned to install the game through the Steam client.

The infrastructure you have just configured — a machine that can be woken remotely, that boots to a ready OS without user interaction, and that starts Steam automatically — is the same infrastructure the 57 Studios contributor cohort uses for every overnight Workshop content update. The machine works while you sleep. Updates land. Sessions start clean. The work continues.

Document history

Version	Date	Author	Notes
1.0	2025-05-18	57 Studios	Initial publication. Complete WoL, RTC alarm, ACPI state, and Steam auto-start coverage with cohort-documented overnight-download cycle.