title: Wake on LAN and Wake on WAN Guide x-toc-enable: true ...
WOL requires that your server is connected to your router/AP via ethernet. You certainly do not want your server to be bottlenecked by wifi anyway.
You then need to gather the necessary info for wol. Generally, all you need is the mac address of your server and a wol client on one of your client machines. You can find your server's mac using the ip tool. For example:
ip link show
> 2: enp0s25: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/ether **00:f5:f9:25:71:ge** brd ff:ff:ff:ff:ff:ff
To wake your server, just point it to your mac address.
wol 00:f5:f9:25:71:ge
You could stop right here with configuring wol, but you'll miss out on the ability to wake your machine remotely; for good reason. WOL generally only works over your local network, so you can't use it when you're outside your LAN. There are a plethora of extensible, principled, hacky, and over-engineered solutions for wake on wan, but I'm partial to my own ad-hoc solution.
Whenever you make parts of your network open to the internet (WAN) you necessarily introduce security risks. These security risks are a trade-off for adding fun and interesting features to your home server. Before opening anything on your local network to the internet, consider the following questions:
The second point is of major importance for this guide. Always make sure that your home server itself, your openwrt router, and all of your packages on both are up to date. If you want to further secure your home server, and you have an openwrt router, consider reading openwrt's DMZ documentation.
Connect to your OpenWrt router via ssh (generally root@192.168.1.1). You can probably adapt this solution for routers running other distros, but openwrt is the focus. Install the etherwake package and test that it works.
opkg update
opkg install etherwake
etherwake 00:f5:f9:25:71:ge
Now you'll have to create a simple service in the background that listens on an arbitrary port and runs etherwake when it receives a connection. Install the socat package.
opkg install socat
Create a simple script called wakewan
to wake your server using the etherwake command.
Replace 4044
with the port you intend to use and replace 00:f5:f9:25:71:ge
with your serever's mac address.
#!/bin/sh /etc/rc.common
START=10
STOP=15
PORT=4044
PIDFILE="/var/run/wake.pid"
start() {
socat -u tcp-l:$PORT,fork system:"etherwake '00:f5:f9:25:71:ge' \
; iptables -I INPUT -p tcp --dport $PORT -j DROP \
; iptables -I INPUT -p tcp --dport $PORT -j ACCEPT" >/dev/null 2>&1 &
echo "$!" > "$PIDFILE" &
}
stop() {
kill -15 "$(cat $PIDFILE)"
iptables -I INPUT -p tcp --dport $PORT -j DROP
iptables -I INPUT -p tcp --dport $PORT -j ACCEPT
}
Place the script on your openwrt router at /etc/init.d/wakewan
.
TIP: If you prefer to create scripts on your main machine and transfer them to other machines on your local network, you can use SCP to transfer files on your network via ssh.
Keep in mind that scp uses -P
to specify the port number, rather than ssh's -p
flag.
Once your init script is in the correct location on your openwrt device, enable and start the service. From the ssh session on your openwrt device run:
chmod +x /etc/init.d/wakewan
/etc/init.d/wakewan enable
/etc/init.d/wakewan start
Now, every time your router is contacted with any message on port 4044 it will send the wake up signal to your server. The easiest way to utilize this new feature is with ssh. If you try to ssh into your server on the WAN side, and find that it's down, wake it up by changing the ssh port to the one specified in the wakewan script:
ssh myserver@1.2.3.4 -p 3033 # results in failure
ssh myserver@1.2.3.4 -p 4044 # asks your server machine to boot
ssh myserver@1.2.3.4 -p 3033 # succeeds after machine boots
Notice that the script uses socat's -u
flag, so it will never send any message back.
You can theoretically use any program (not just ssh) to poke your openwrt router on the specified port from the WAN side.
Whatever you use to send a signal to your router will probably show an error because it doesn't receive any message back.
The script will also hard-terminate the tcp connection as it wakes your server.
All of this is done for security and simplicity, we don't want to have our router interpreting any messages it gets from the WAN side if we can help it.