That’s almost certainly because you’ve got wake on LAN enabled in your BIOS settings and something else on your network wants to have a late-night chat with your computer.
The MAC-specific magic packet is an optional mode for wake on LAN, not a mandatory one. Plenty of network adapters forward packets to the OS if wake on LAN is enabled and let the OS decide whether it only wants to respond to magic packets, and by default when wake on LAN is enabled, there are other kinds of packet Windows responds to, e.g. Address Resolution Protocol, which lots of routers use to check whether devices are still connected. It’s not supposed to wake the machine, especially if S0 sleep is enabled, but it can, especially if it’s done excessively.
A magic packet is any packet using any protocol with that string in it. And the os cannot respond to a wake-on-lan packet, because the os is not running at the time; the computer is powered off. The os is later informed, via acpi, of the reason it was woken up, should it bother to check. If you don’t want a magic packet, then any packet will wake the system up. I am not aware of any alternatives. Extensions, yes. But not alternatives
It’s not any packet that’s waking up machines configured to wake on LAN without restricting it to magic packets, it’s any packet addressed to the machine’s MAC. Just like a regular packet when the machine’s fully awake, it’s specific to the network adapter with that MAC, and gets handled by that network adapter. Once it wakes the machine (either to fully on or a sleeping-but-still-doing-things state like S0), the OS starts/resumes and is told why it was started and can choose to access the packet and respond to it. From the perspective of the device on the other end of the wire, it sent a packet to a machine and got the response it expected. It doesn’t have to know whether the machine was fully powered on or whether it woke up to deal with the request before going back to sleep again.
By default, for most network traffic that partially wakes Windows when the machine has wake on LAN enabled in the UEFI settings, Windows sees it’s been woken by LAN activity, checks the packet, decides it doesn’t care, and goes back to sleep before anyone notices (or remains in S0 sleep if it was in S0 sleep as it wouldn’t need to wake up to deal with the packet). For a few other kinds of LAN activity, it opts to respond to the packet. If you’ve got your UEFI settings set to only wake on magic packets, these won’t make it that far, though. There’s also a Windows setting to force it not to respond to regular non-magic packets and immediately go back to sleep if it’s woken by them.
I thought the “addressed to it” part was implied. you seem to keep saying that windows handles things. The computer is shut down, not in sleep mode. There is no windows to handle things. Windows is not loaded. It has not gone through the boot process. WoL still works if you rip out all the storage. WoL is handled by the network adapter hardware
You’re describing what windows does after a computer is woken/turned on. That’s irrelevant, by that point the WoL is long over. After the pc is turned on and booted then windows is free to do whatever, including putting the system back to sleep. Whether it does this fast enough for you to notice is irrelevant, that is not WoL functionality.
And no, systems are not constantly waking up and then re-sleeping. Again, if the pc was shut down it’d have to go through the whole boot process before windows can put the system back to sleep. And you would find a sleeping pc when you left a shutdown one. Not what happens. And if instead of sleeping it shut itself down that’d look like a boot loop. definitely noticable.
tldr: after the pc is turned on and the os has been loaded, the os is free to do anything
We’re in a thread that was started by someone complaining that their Windows machine kept waking up seemingly on its own when they put it to sleep, so how wake on LAN behaves for a computer that’s completely shut down was never particularly relevant, and certainly not something to be taken as the only situation we’re discussing. When a computer is asleep, wake on LAN can wake it, and because the OS is still loaded, it doesn’t need to do a full boot before running any wake on LAN handling it has. If wake on LAN is disabled in the motherboard settings, then a computer in a deep sleep like S3 can’t respond to network activity at all.
Also, I’m not sure where you’ve got the idea that wake on LAN is mainly for fully powered off machines. There’s a reason it’s usually called wake on LAN, not power on by LAN. The ability for a network event to power on a machine from S5 power off is usually a separate setting and isn’t even possible on all hardware that supports wake on LAN.
I’m also not sure where you got the idea that only the hardware aspect counts as wake on LAN and the OS-side handling for being woken on LAN doesn’t count. Like with many things related to computers, it requires a hardware aspect and a software aspect working together to form a whole system, and in this case, it’s the whole system that’s called wake on LAN.
When Windows wakes itself up to do things like that, it wakes itself to a different sleep level where it can still do things but the machine isn’t visibly on. That’s the whole point of S0 sleep. If it’s fully waking itself up to do things, then either S0 sleep is disabled or there’s a firmware bug affecting the motherboard that means certain actions during S0 sleep will exit sleep (which is more common than it should be).
That’s almost certainly because you’ve got wake on LAN enabled in your BIOS settings and something else on your network wants to have a late-night chat with your computer.
yeah wake on lan is pretty hard to accidentally trigger.
Why would random software be sending packets with 0xFFFFFFFFFFFF + mac*16?
The MAC-specific magic packet is an optional mode for wake on LAN, not a mandatory one. Plenty of network adapters forward packets to the OS if wake on LAN is enabled and let the OS decide whether it only wants to respond to magic packets, and by default when wake on LAN is enabled, there are other kinds of packet Windows responds to, e.g. Address Resolution Protocol, which lots of routers use to check whether devices are still connected. It’s not supposed to wake the machine, especially if S0 sleep is enabled, but it can, especially if it’s done excessively.
A magic packet is any packet using any protocol with that string in it. And the os cannot respond to a wake-on-lan packet, because the os is not running at the time; the computer is powered off. The os is later informed, via acpi, of the reason it was woken up, should it bother to check. If you don’t want a magic packet, then any packet will wake the system up. I am not aware of any alternatives. Extensions, yes. But not alternatives
It’s not any packet that’s waking up machines configured to wake on LAN without restricting it to magic packets, it’s any packet addressed to the machine’s MAC. Just like a regular packet when the machine’s fully awake, it’s specific to the network adapter with that MAC, and gets handled by that network adapter. Once it wakes the machine (either to fully on or a sleeping-but-still-doing-things state like S0), the OS starts/resumes and is told why it was started and can choose to access the packet and respond to it. From the perspective of the device on the other end of the wire, it sent a packet to a machine and got the response it expected. It doesn’t have to know whether the machine was fully powered on or whether it woke up to deal with the request before going back to sleep again.
By default, for most network traffic that partially wakes Windows when the machine has wake on LAN enabled in the UEFI settings, Windows sees it’s been woken by LAN activity, checks the packet, decides it doesn’t care, and goes back to sleep before anyone notices (or remains in S0 sleep if it was in S0 sleep as it wouldn’t need to wake up to deal with the packet). For a few other kinds of LAN activity, it opts to respond to the packet. If you’ve got your UEFI settings set to only wake on magic packets, these won’t make it that far, though. There’s also a Windows setting to force it not to respond to regular non-magic packets and immediately go back to sleep if it’s woken by them.
I thought the “addressed to it” part was implied. you seem to keep saying that windows handles things. The computer is shut down, not in sleep mode. There is no windows to handle things. Windows is not loaded. It has not gone through the boot process. WoL still works if you rip out all the storage. WoL is handled by the network adapter hardware
You’re describing what windows does after a computer is woken/turned on. That’s irrelevant, by that point the WoL is long over. After the pc is turned on and booted then windows is free to do whatever, including putting the system back to sleep. Whether it does this fast enough for you to notice is irrelevant, that is not WoL functionality.
And no, systems are not constantly waking up and then re-sleeping. Again, if the pc was shut down it’d have to go through the whole boot process before windows can put the system back to sleep. And you would find a sleeping pc when you left a shutdown one. Not what happens. And if instead of sleeping it shut itself down that’d look like a boot loop. definitely noticable.
tldr: after the pc is turned on and the os has been loaded, the os is free to do anything
We’re in a thread that was started by someone complaining that their Windows machine kept waking up seemingly on its own when they put it to sleep, so how wake on LAN behaves for a computer that’s completely shut down was never particularly relevant, and certainly not something to be taken as the only situation we’re discussing. When a computer is asleep, wake on LAN can wake it, and because the OS is still loaded, it doesn’t need to do a full boot before running any wake on LAN handling it has. If wake on LAN is disabled in the motherboard settings, then a computer in a deep sleep like S3 can’t respond to network activity at all.
Also, I’m not sure where you’ve got the idea that wake on LAN is mainly for fully powered off machines. There’s a reason it’s usually called wake on LAN, not power on by LAN. The ability for a network event to power on a machine from S5 power off is usually a separate setting and isn’t even possible on all hardware that supports wake on LAN.
I’m also not sure where you got the idea that only the hardware aspect counts as wake on LAN and the OS-side handling for being woken on LAN doesn’t count. Like with many things related to computers, it requires a hardware aspect and a software aspect working together to form a whole system, and in this case, it’s the whole system that’s called wake on LAN.
Or they’re using S0 sleep and the computer is waking itself up to update
When Windows wakes itself up to do things like that, it wakes itself to a different sleep level where it can still do things but the machine isn’t visibly on. That’s the whole point of S0 sleep. If it’s fully waking itself up to do things, then either S0 sleep is disabled or there’s a firmware bug affecting the motherboard that means certain actions during S0 sleep will exit sleep (which is more common than it should be).