Is it possible to make WoL unicast work indefinitely?

Submitted ⁨⁨1⁩ ⁨week⁩ ago⁩ by ⁨meekah@lemmy.world⁩ to ⁨selfhosted@lemmy.world⁩

I am trying to set up my homelab to wake whenever it is being accessed. I set up wake on LAN for unicast, and it works fine for a while after shutting down the system. It stops working after a few hours of the server being turned off, though.

From what I’m gathering online, the issue is that my router uses ARP cache for resolving IPs. Before that gets flushed, it still works. However, it seems like my router does not allow me to configure a static ARP entry. I already set a static IP for my server in the router, but it still won’t work a few hours.

Is there any way to make this work? I just want to allow a friend of mine to boot my server whenever they try to access a service on it.

source

Comments

Sort:hotnew top

lorentz@feddit.it ⁨1⁩ ⁨week⁩ ago
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

source
- meekah@lemmy.world ⁨1⁩ ⁨week⁩ ago
  I am talking about WoL in unicast mode, not with the magic packet.
  
  source
  - k_rol@lemmy.ca ⁨1⁩ ⁨week⁩ ago
    Im curious, why unicast over magic packet?
    
    source
    -> View More Comments
AtariDump@lemmy.world ⁨1⁩ ⁨week⁩ ago
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).

source
- meekah@lemmy.world ⁨1⁩ ⁨week⁩ ago
  I would appreciate if you marked quotes as auch, using >.
  
  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.
  
  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. 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.
  
  source
- ripcord@lemmy.world ⁨1⁩ ⁨week⁩ ago
  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.
  
  source
  - AtariDump@lemmy.world ⁨1⁩ ⁨week⁩ ago
    From what I’ve read, they either need a static ARP entry OR whatever was stated in the third paragraph.
    
    source
maxwellfire@lemmy.world ⁨1⁩ ⁨week⁩ ago
Why shutdown the homelab in the first place? Are you trying to save on power consumption?

source
- meekah@lemmy.world ⁨1⁩ ⁨week⁩ ago
  Yes, electricity is expensive here and I don’t use it daily.
  
  source
rtxn@lemmy.world ⁨1⁩ ⁨week⁩ ago
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.

source
- meekah@lemmy.world ⁨1⁩ ⁨week⁩ ago
  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.
  
  source