While this is labeled OTHER VERSION, it should be applicable to many versions and certainly those that use systemd.
Wake-on-LAN, a working case
Not long ago there was a question on the forum about getting Wake-on-LAN (WOL) functional. After this was solved, I implemented this in my own home network. Not long thereafter a new thread was started by another member about WOL and he could be helped with the same solution. While WOL is a subject with many aspects, these threads showed that a solution that worked for at least some of the cases in an openSUSE environment might be helpful for others. So this is not an extensive article about WOL, but a practical solution that might fit your situation, or give you starting points for further study.
What is Wake-on-LAN
In short it is a way to “start” a computer by sending it something over the LAN (Local Area Network).
See Wake-on-LAN.
While the Wikipedia article mentions waking from other networks and waking over Wireless LAN, we restrict ourselves here to Ethernet LAN.
You may see a need for WOL in an energy saving policy, to start systems when needed (to write a backup to, to use as file/print or other server, etc.)
General
We will call the computer to be woken up the “target” below.
All commands shown below are to be done “as root”.
The program ethtool is used, it is normal installed at system installation, else install it, e.g.
# zypper in ethtool
It has a long man page of which this is a quote:
wol p|u|m|b|a|g|s|f|d…
Sets Wake-on-LAN options. Not all devices support this. The argument to this option is a string of characters specifying which options to enable.
p Wake on PHY activity
u Wake on unicast messages
m Wake on multicast messages
b Wake on broadcast messages
a Wake on ARP
g Wake on MagicPacket™
s Enable SecureOn™ password for MagicPacket™
f Wake on filter(s)
d Disable (wake on nothing). This option clears all previous options.
The type used in our examples is g (Wake on MagicPacket™) and this is the subject of this document.
Hardware of the target
The target must be connected to the LAN with an Ethernet cable in a Network Interface Card (NIC) and the NIC must be able to support WOL. To check that ability:
# ethtool eth0 | grep Wake
Supports Wake-on: pumbg
Wake-on: d
#
which shows which types are supported by the NIC and that at the moment it is disabled.
(When your NIC has been given another name then eth0, use that one here and further down).
It will be clear that when none of the types is supported, there is no WOL possible using this NIC.
The fact that a NIC supports WOL does not imply that the system does so. When the NIC is detecting the MagicPacket™, it must signal the system in the same way as happens when one pushes the power switch. This requires a connection that may or may not be built in (I remember years ago that there was documentation on the internet how to add an extra electrical wire from the NIC to a point on the motherboard to achieve this). So check the system’s manual or ask the seller/manufacturer. Or just try it.
I have the idea that nowadays, with energy saving being an important issue, more desktop like systems will support WOL. I do not know about laptops and smaller devices.
Last but not least, there must be some power available. The NIC must have some power to see the ethernet frames pass by, etc. When we look into the Advanced Configuration and Power Interface (ACPI), G3 (Mechanical Off) is a Nono, G2/S5 (Soft Off) should work. Some of the G1 (Sleeping) states might also works, as they also answer to pressing the Power button.
Firmware of he target
The firmware (BIOS) will most often have a possibility to switch WOL ON/OFF (the default being OFF). That depends of course much on the system and the BIOS used. In my system I found it under Hardware > Energy Management > Activate S4/S5 through LAN.
Switching ON and testing
When all the above can be satisfied the NIC must be “armed” with
# ethtool -s eth0 wol g
For testing, bring the target in the power down state (shutdown) and send the MagicPacket™ from another partner on the LAN. When your target starts, you have passed the most difficult part :).
To make it persistent
What was found out (and the main reason for people to ask for help on the forum) is that the “wol g” setting is not persistent. It must be repeated before the next shutdown. The solution we found was that it is best to do it right after boot (that is then in time for the next shutdown 
). People still thought about doing something with rc.local, but that is old stuff. Using systemd, a systemd service was created:
# cat /etc/systemd/system/wol.service
[Unit]
Description=Wake-on-LAN
Requires=network.target
After=network.target
[Service]
ExecStart=/usr/sbin/ethtool -s eth0 wol g
Type=oneshot
[Install]
WantedBy=multi-user.target
#
To enable it so it will be started at every boot:
# systemctl enable wol.service
When you want to run it for a test:
# systemctl start wol.service
When you want to see what happened:
# systemctl status wol.service
And it worked happily ever after.
Addendum
Well, it did not work happily ever after.
I upgraded to openSUSE 15.3 and it failed. The error meassage said that there was no device of that name (in my case eth0). Inspection of the log revealed that the name eth0 was only created milliseconds after the WOL service run. Thus I decided to postpone the service until after the network is available (after all as long as it runs before system shutdown, that is fine) in the same way as we see below (where we need the network to be able to send the MagicPacket™). So the Unit file is now changed to
# cat /etc/systemd/system/wol.service
[Unit]
Description=Wake-on-LAN
After=network-online.target
Wants=network-online.target
[Service]
ExecStart=/usr/sbin/ethtool -s eth0 wol g
Type=oneshot
[Install]
WantedBy=multi-user.target
#
And I enabled the, for me appropriate, network wating function (see below for the details).
=======================================================
How to Wake from openSUSE
Until now we did not explain much about the sender of the MagicPacket™. These can be manifold. Computers, other network devices, routers. Again this Howto will be restricted to openSUSE. Only one statement is needed:
# wol <MAC address>
see:
$ man wol
Thus you must know the MAC address of the target NIC. You can find the MAC address of a NIC with (on the target):
ip address
It is after “link/ether” of the eth0 information and looks like ec:8e:b5:da:0d:0d.
It depends of course very much on the need you have where this command is to be put. In a crontab, a backup script, … In any case, after the command is given there will be some time before the target is available, thus a testing loop (e.g. based on ping and sleep) might be needed.
One case that was solved was the case to start the target as soon as possible after the system starts. At first sight it looks as if a simple systemd service as above will work. This turned out not to be the case. The timing not to send the MagicPacket™ before the network on the sending system was available was not easy. See Running Services After the Network is up.
A working solution is:
# cat /etc/systemd/system/wake-boven.service
[Unit]
Description=Wake boven
After=network-online.target
Wants=network-online.target
[Service]
ExecStart=/usr/bin/wol ec:8e:b5:da:0d:0d
Type=oneshot
[Install]
WantedBy=multi-user.target
#
But, read the above mentioned document, to let the “Wants=network-online.target” function there must be an active systemd network waiting function. It depends on the way you run your network. Two are mentioned in the document and both are found on my system (enable only one of them):
# systemctl enable NetworkManager-wait-online.service
# systemctl enable systemd-networkd-wait-online.service
I wonder about wicked?
I use systemd-networkd, so I am happy enabling the second one.
