The Wake On LAN feature isn't functioning despite receiving magic packets, as confirmed by Wireshark analysis.
The Wake On LAN feature isn't functioning despite receiving magic packets, as confirmed by Wireshark analysis.
Here’s a revised version of your text:
I’m trying to figure out what I’m doing incorrectly.
I’ve shared some additional details about the steps I took.
I’m sending a wakeonlan message from a Raspberry Pi connected to the same home network.
Wireshark captures the WOL packet, but when the PC is in sleep mode, the command fails to wake it.
When I put the PC to sleep, the Ethernet port LED lights up slowly in green.
Also, after putting the PC to sleep and waking it by pressing Enter on the keyboard, it starts up but with some applications still open.
Hardware details: ASUS tuf gaming b650-plus
Device Manager shows a Realtek Gaming 2.5GbE Family Controller
Driver version: 1125.21.903.2024
BIOS settings:
Power on PCI-E/Wake On Lan is turned ON
Deep Sleep and Fast Boot are disabled
In Windows 11 network adapter power management:
- Allow the computer to turn off this device to save power: DISABLED
- Allow this device to wake the computer: ENABLED
- Only allow magic packet to wake the computer: ENABLED
In Windows 11 advanced settings for network adapter:
- Wake on magic packet: ENABLED
- Wake on pattern match: ENABLED
- WOL & Shutdown Link Speed: 10Mbps First
- Shutdown Wake On Lan: ENABLED
- Advanced EEE: DISABLED
- Energy-Efficient Ethernet: DISABLED
- Green Ethernet: DISABLED
- Power Saving Mode: DISABLED
Control Panel – Power Options – Choose what the power button does – Turn on fast start-up is DISABLED
If you need further clarification, just let me know.
Thank you!
Wake on LAN has consistently been unreliable. We often had to resend the wake packet several times. This situation has deteriorated significantly over time... now that Microsoft has stepped in. They introduced numerous additional low-power and sleep features. Sadly, the BIOS provides extra support, and Microsoft can modify these settings through the operating system. The issue appears to be that Windows doesn't shut down exactly as intended for Wake on LAN, possibly because it's being disabled by some BIOS behavior.
I was very upset with WOL before, but now with Microsoft's involvement things have become even worse. Many BIOS configurations don't adhere strictly to the standard. For instance, they sometimes treat packets addressed to the PC's own MAC address instead of a broadcast MAC. Additionally, many systems wake up with an incomplete IP header in the packet, even though the PC doesn't actually have an IP address when it enters Wake on LAN mode.
What I did and what I suggest everyone try is to use the option that initiates booting from a power restore. You can then put the machine to sleep or shut it down and use a specialized power outlet to manage the PC's startup process. Another option, if you prefer, is to enable Wake on WAN, which isn't a standard feature but allows remote access via the internet through power plugs.
When I put the PC into sleep mode, the ethernet port lights up green indicating it's connected to the local network. On the same network, I connected a Raspberry Pi from an external network and was able to send magic packets using wakeonlan with its MAC address. Wireshark captures packets when the PC is powered on (though I'm unsure how to verify this during sleep). Sending the same packet while the PC is asleep has no effect, even after sending multiple packets, which is causing frustration. I'm looking for guidance to troubleshoot these issues and identify the root cause. Regarding the boot-on-power restore, I have a shelly plug at home that I can use to power my PC from outside the network. I can switch it on or off remotely, but I'm concerned about whether this is safe enough for the hardware to constantly toggle the main power supply. Additionally, I noticed small devices like switchbot or fingerbot that can press the power-on button when needed.
As recommended, WOL didn't function correctly. Apply the approach proposed by @bill001g or the alternative you referenced—a switchbot or fingerbot.
Windows handles recovery well and removes the need to handle moving parts in a disk drive.
I usually start by placing the machine into sleep mode. There are a few methods, but I believe Microsoft refers to the one I use as suspend. Once the device shuts down, you can turn off power. When electricity returns, it restarts as if you just pressed a key to wake it from sleep. Of course, you can still shut it down normally and remove power. It should boot up again when power is restored.
Does booting from power restore maintain hardware integrity? If confirmed, I'll proceed and evaluate its performance during sleep and shutdown phases.
The only time I might be concerned is if the machine was running full blast and was suddenly turned off. Mostly all the fans stop. You run a tiny chance of corrupted files but windows seems to fix that.
Both the sleep and shutdown the only thing that is on is the tiny standby power.
This is pretty much how I run my main gaming machine everyday. I sleep the machine and then I turn off the pc at a power strip that turn off the monitors. When I turn it back on in the morning the machine boots itself and all the web pages are back at the point I ended.
The following points summarize the current situation:
Advanced EEE: DISABLED
Energy-Efficient Ethernet: DISABLED
Green Ethernet: DISABLED
Power Saving Mode: DISABLED
Control Panel - Power Options - Select power button behavior; fast start-up is OFF
As mentioned before, WOL has been causing issues.
I recommend turning on all energy-saving settings just to test.
Although no active energy-saving configurations exist, these four options (and potentially more) might be triggering events that interfere with the Raspberry Pi’s WOL functionality.
Reference: https://learn.microsoft.com/en-us/t...se...an-feature
Details from the article:
"The default response to WOL events has shifted from Windows 7 to Windows 10."
It’s possible this change also applies from Windows 10 to Windows 11.
Sleep states: https://learn.microsoft.com/en-us/window...ing-states
Verify and observe the sleep state using the powercfg /a command as shown in the link.
Additionally, powercfg /l shows the active power settings.
Monitor if the sleep state changes at specific times.
Regarding the WOL packet: it originates from a Raspberry Pi and appears in Wireshark.
How is this packet formed? More info can be found here:
https://www.pdq.com/blog/wake-on-lan-wol...owershell/
The packet consists of a byte array with six 255s (0xFF) and sixteen repetitions of the target machine’s 48-bit MAC address. Magic packets are sent across the local network without being routed beyond a certain subnet."
The main issue lies with the BIOS component, which is unrelated to the operating system that starts up. Previously, accessing the BIOS required manual steps during boot time, providing a strong security measure. However, now the industry has let Microsoft control changes that have weakened or complicated functionality for other operating systems. Even before these updates, WOL had some problems, but now certain machines won't work at all unless you carefully configure both the BIOS and Windows.
I'm contemplating the order of "bytes" sent to activate the target system. Or perhaps the network adapter that must be ready to respond. Or any component waiting to detect and act.
Reference: https://learn.microsoft.com/en-us/window...management
I'm still trying to grasp all these details.
The goal is to send the right sequence in the proper format so that the WOL action runs on the intended device.
Bytes, MAC addresses, specific patterns...
For example:
https://www.pdq.com/blog/wake-on-lan-wol...owershell/
This leads into WOL methods.
The starting point is the source—whether it's a Raspberry Pi or another device—that must receive the correct sequence.
It doesn't have to use PowerShell directly.
The main challenge is identifying the accurate byte pattern, which might vary.
I'm hoping Wireshark could help in a practical WOL scenario to uncover the exact pattern.
I'll experiment if time and conditions allow.