Wi-Fi Wake-on-WLAN for Headless Devices: Define Which Packets Must Wake the Product

Wake-on-WLAN qualification should prove a chain: a defined network event reaches the radio, the configured trigger is recognized, the platform resumes from the intended sleep state, and the application becomes usable. A successful cloud command after several retries proves only the last part. It does not identify which event woke the host.

This guide uses Linux 6.6 power-management and nl80211 interfaces, plus NetworkManager 1.46.0 profile semantics. It applies to Linux Wi-Fi station products whose driver and firmware expose WoWLAN support. It does not certify a particular radio, board or suspend state. Chipset firmware, bus wake routing, board power domains and the access point remain part of the product-specific qualification.

Turn “remote wake” into an observable contract

Write one requirement for each permitted wake cause. A local maintenance packet, association loss and an offloaded TCP connection are different cases. For every case, specify the sender, network path, expected device identity, allowed sleep state, expected host action and evidence needed to call it a pass. Also specify traffic that must not wake the device.

Keep the contract narrower than “any packet.” For example, a product might permit a local management station to request wake while unrelated broadcast traffic should leave it asleep. Whether the selected hardware can implement that policy is a capability question to answer before committing to a power budget.

Linux distinguishes device runtime power management from system sleep and distinguishes hardware wake capability from user-space wake policy. An enabled device wake setting is therefore not evidence that every sleep state supports the desired event. See Linux 6.6 device power-management documentation.

Capture capability, configured policy and actual sleep state separately

Start with a read-only inventory: kernel build, radio device identifier, driver, firmware revision, network-manager version, interface identity and power topology. Preserve the raw capability report generated by the product’s installed wireless tools. Record which triggers and pattern limits are advertised, rather than copying another module’s command line.

NetworkManager 1.46.0 documents a wake-on-wlan property with options including magic packet, disconnect and TCP-related wake. It explicitly says that devices need not support all options. Its default value delegates to global settings; ignore leaves management of the setting alone. Neither means “this particular wake test is armed.” Inspect the active connection and the applied driver state where the implementation permits it. The versioned wireless settings reference is the boundary for these meanings.

Record the actual system sleep selection, not simply a test script’s label. Linux exposes sleep-state choices through its power-management interfaces, and available states depend on platform support. Suspend-to-idle and deeper suspend are separate qualification rows, as described in Linux 6.6 system sleep states. Do not generalize a pass in one row to another.

Build a packet corpus that matches the interface

For each positive stimulus, keep a minimal packet description or sanitized capture and a corresponding negative variant. Change one meaningful feature at a time: destination identity, required payload bytes or the event type. Verify delivery from an observation point near the access point or receiver path. A sender’s successful transmit call is weaker evidence than observing the packet on the relevant network segment.

The Linux 6.6 nl80211 definitions make two details particularly important: packet-pattern matching uses an unpacked, Ethernet-like representation rather than raw over-the-air header offsets, and the any-activity mode is incompatible with the other trigger modes. Disconnect detection is implementation-specific. These are interface semantics, not claims that a given firmware implements every feature. See the versioned WoWLAN trigger definitions.

Do not assume that a pattern can inspect an application’s encrypted content. Match only bytes that the actual offload path makes available, and validate the resulting rule with captured traffic. Treat a wake packet as a request to resume processing, not as authorization to actuate hardware or reveal data; the resumed application still needs its normal authentication and replay protections.

Run a controlled wake experiment

1. Use a bench device with independent recovery access. Confirm that a known local recovery mechanism works before testing a headless suspend path.
2. Establish the intended association and record the active wake policy. Disable unrelated test stimuli where safe, while keeping an independently identifiable recovery timer if needed.
3. Enter the selected sleep state. Confirm entry using available platform evidence; do not count an immediate suspend abort as a successful wake.
4. Send exactly one positive stimulus at a recorded time. Keep application-level retries off for this isolated experiment.
5. Collect host resume evidence and any driver-reported wake reason. Record unavailable or ambiguous reasons honestly.
6. Measure application readiness separately, using a harmless authenticated status request after resume.
7. Repeat with the negative packet and with no packet. A resume caused by a recovery timer or unrelated interrupt must not count as a packet-trigger pass.

Use a common external time reference when correlating packet capture and power-state evidence. If the instruments have independent clocks, record their uncertainty. Do not subtract unsynchronized timestamps and report the difference as wake latency. The procedure above is a proposed test plan; no target measurements are claimed.

Interpret failures at the first unsupported gate

• No receiver-side packet evidence: investigate network delivery, addressing and filtering before the host wake configuration.
• Packet delivered, no resume: verify support, applied trigger, sleep-state compatibility and the board’s wake path. Preserve any firmware or driver error.
• Host resumes, application stays unavailable: inspect resume ordering, association recovery and service readiness as a separate failure.
• Negative traffic wakes the host: look for a broader trigger, a disconnect event or another wake source. Do not immediately blame packet-pattern precision.
• Wake reason unavailable: retain the observation, but classify causal attribution as inconclusive until controlled positive and negative trials narrow it.

Hypothetical example: cloud retries hide a missing wake contract

Imagine a battery-backed inspection gateway that should wake for a local maintenance request. A demonstration sends a cloud status command repeatedly and eventually gets a response. The same device also has a scheduled health-check wake. Without a timeline, either mechanism could explain the response.

The proposed qualification would first exercise the local stimulus without cloud retries, then run a no-stimulus control covering the same observation window. It would label the health-check wake independently. If only the scheduled wake produces readiness, the remote-wake requirement remains unproven even though the demonstration looked successful.

After proving the local wake path, reintroduce the real cloud workflow and test its own reachability, connection lifetime and retry behavior. The result should be two linked records: a bounded hardware-and-software wake capability, and a service-level recovery behavior. That separation makes firmware regressions, access-point changes and application failures substantially easier to diagnose.