You need to send the WOL packet to the broadcast address of your network, not to the machine IP address. It this way all the machines on the network will receive it, including the ones that have been powered off for a while
this post was submitted on 22 Sep 2025
20 points (91.7% liked)
Selfhosted
61086 readers
824 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
-
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 3 years ago
MODERATORS
I am talking about WoL in unicast mode, not with the magic packet.
Im curious, why unicast over magic packet?
Because I want the server to boot when a service on said server is being accessed. Without having to manually boot it before.
I'm not familiar with this setup. But do you want for the server to boot as soon as it receive any packet addressed to its IP?
Yup. And it works already, as long as the server was shut down in the last few hours. Then it stops working. The 4 hours mentioned here seem about right.
Why shutdown the homelab in the first place? Are you trying to save on power consumption?
The other idea I had was to use another lower power device spoofing the server's Mac. But it seems like it would require an ethernet hub and those don't really exist anymore.
Yes, electricity is expensive here and I don't use it daily.
As @ott's comment mentions, you can't send unicast traffic to a machine that isn't active on the network at that time. 'Active on the network' means different things to different devices though... to a Layer 3 device like your PC or a router it means 'this device has talked to the machine at some time in the last 4 hours' (depends on arp timeout), to a Layer 2 device like a switch it means 'the switch has seen a packet with that source mac-address some time in the last 5 minutes' (depends on mac aging time).
You state that unicast WOL works when the device has been turned on and then back off, but you don't state if it stops working at some time after the machine is shut off. This works because the router (or the WOL-packet generating PC if in the same subnet) has an arp entry (4 hour timeout) and can create a packet destined for the correct machine, however the switch either knows the port the mac-address belongs to (WOL sent within mac aging time) or has already timed out that mac-address so it treats the unknown destination as a broadcast. Once the arp entry times out, the router (or PC) will fail to encapsulate the WOL packet since it has nothing to put in the dest-mac field.
To make this work you need to use broadcasts, there is no other reliable way. To make WOL work on a different network than where your server is connected, you need to use directed broadcast packets (unicast packets sent to broadcast address of remote network, properly configured remote router will allow the packet and send it as a broadcast on the intended network).
https://serverfault.com/questions/672160/wake-on-lan-unicast-is-not-working-why
(From your own post further down)
So you're saying that they need to direct the WOL unicast, on the same segment, to the MAC and not the IP, yes?
Then if they are in a remote subnet/LAN/network, they'll need to contact something local to generate the unicast packet.
From what I’ve read, they either need a static ARP entry OR whatever was stated in the third paragraph.
Do you think I didn't read this? You obviously saw that I posted it in another comment, and I am mentioning info from the very text you posted here.
(Edit: I am realizing I am coming across as kinda hostile here, but I genuinely just want to understand your thought process behind posting this)
If you read the comments of the answer you copied, the OP of the question also said the following:
The following solutions worked: Static ARP entries and subnet-directed broadcasts. You may use one of both if you have the same scenario. Thanks for pointing me in the right direction.
Them mentioning that one 'may use one of both' makes me believe there is a way to make this work properly with unicast. The serverfault post is also mentioning the need to manage several machines this way, which is why I believe the answer you copied suggested using broadcast, as managing ARP entries for several machines could become tedious and unreliable.
The most straight-forward method would be to buy a standalone switch. I have a TP-LINK TL-SG108 8-port gigabit switch and it seems to retain the ARP table indefinitely.
My previous solution was an ESP32 board with an SSH server and a relay, wired parallel with the power switch, that would be closed by an output pin on command.
I'll look into my options regarding a different switch or router, thanks.
However your solution with the ESP32 would require me to manually trigger the boot, no? At that point I can just use the magic packet, which works fine already.