Is wake on LAN any good these days? I remember it being flaky in the late 90s early 00s...
I only had one problem with it, and that was that it isn't enough to enable it in the BIOS, but I needed to flip a switch on Windows and set up a systemd service on Linux (I dual boot).<p>For Linux set it to "g": <a href="https://wiki.archlinux.org/title/Wake-on-LAN#Make_it_persistent" rel="nofollow">https://wiki.archlinux.org/title/Wake-on-LAN#Make_it_persist...</a><p>For Windows you need to enable "Wake on Magic Packet": <a href="https://www.windowscentral.com/how-enable-and-use-wake-lan-wol-windows-10" rel="nofollow">https://www.windowscentral.com/how-enable-and-use-wake-lan-w...</a>
I always wondered: why make it so difficult to turn on? Is it a security issue? I mean, an off-by-default OS setting <i>and</i> an off-by-default BIOS setting? How dangerous is this thing??
It draws more power because the NIC can't power off completely. So Microsoft and every hardware vendor are incentiviced to turn it off to look good. (And probably
to please regulations)<p>That it is defaulted off I feel is motivated, but to make it so hard to turn it on is pretty pathetic.<p>The fury Microsoft generated by turning it off in a Windows update still fuels me. I had a remote PC that I need to access remotely during holiday season. And Microsoft turns off my ability to power it on, with me left trying to figure out why I can't access the machine anymore.
"set it to 'g'". Awesome.<p>G for maGic, I presume?
Yep, pretty sure. m is for multicast.
From arch wiki: d (disabled), p (PHY activity), u (unicast activity), m (multicast activity), b (broadcast activity), a (ARP activity), g (magic packet activity)
I still have a lot of weirdness when it comes to making things actually stay asleep and wake up again when wanted. There's a lot of hardware that often boots up, or always boots but only if it's been switched on once before, or keeps trying to wake itself up for no good reason.<p>The absolute most consistent way I've found is using cheap zigbee smart switches or even second hand smart PDUs. Set the machine to boot when power is restored and actually switch the thing on and off from the wall. It saves a whole lot of messing around, you can force the reboot issue and for a tiny amount more in upfront costs you can have power monitoring as well. It also works for network gear that doesn't sleep or anything else that had a physical switch.<p>edit: Ideally give me hardware with proper out-of-band management (ipmi or AMT at a pinch), but for everything else having control of the power is as good as it gets.
It's pretty heavily used in some on premises HPC contexts... used to run a large supermicro cluster which we would power down when not needed, which saved a fair amount of electricity (and by extension emissions and money.) It's quite solid.
I have weird desktop system on ASRock motherboard.
I have 2 ethernet (10gbe and 1gbe) ports and WiFi build in.
i have 10gbe network so ofc I want to use 10gbe port.<p>the issue that I discovered after many hours of debugging is that 10gbe port is powered down completely on suspend/power off. so it have no way to work.<p>because I had limited number of ethernet ports available I set up system to use wake up over WiFi (with wake also on key rotation or disconnect)
I haven't had problems with it the past few years, on SuperMicros.<p>EDIT: as the sibling comment reminded me, I'm using IPMI, not WoL. That said, I have tested WoL and had no issues with it doing its job – I only switched because I had a server that would randomly fail to find its NVMe drive at boot; rebooting (which IPMI allowed me to do) would fix it.
Been fine for me mid 00's and onwards. From memory with SuperMicro, HP, Dell kit etc. Ususally setup via ipmi. Not done it for a while, but don't recall issues.
In my experience it depends a lot on your hardware. For some versions my msi consumer Mainboard just would not respond to wol packets. No matter what I tried.