Listen for wakeonlan request

With nc you can listen on an udp port. The magic packet usually is sent to port 9 via broadcast. So, the command would be:

nc -ul 9

Depending on the nc implementation, you may also need to provide the -p flag:

nc -ul -p 9

To test it use the wakeonlan command...

wakeonlan <your-mac>

...and see in the nc terminal the output.

The other answer only works for "Wake-Up!"-packets coming in via UDP:9 (like from wakeonlan, and not for packets of the dedicated ethertype 0x0842 (AMD magic packet format) (e.g. etherwake).

To grab the relevant part of the payload for both of those wake-up methods:

tcpdump -UlnXi eth0 ether proto 0x0842 or udp port 9 2>/dev/null |
sed -nE 's/^.*20:  (ffff|.... ....) (..)(..) (..)(..) (..)(..).*$/\2:\3:\4:\5:\6:\7/p'

Output is one mac-address per line, line-buffered.

I know that my question might seem a little bit useless, because, if a system is running, there is no need to wake up it!

Not at all. While configuring or troubleshooting you may need to see that the packet is indeed arriving.

With this command

$ sudo tcpdump -i eth0 -n -v -s0 udp port 9

you can see each UDP packet with port 9 on eth0 interface. The output will update with each packet that meets the conditions (unlike nc that will stop after the first).

You can change eth0 to wlan0 or whatever you need (yes, you can wake up a device using the wireless interface as well).

An example:

$ sudo tcpdump -i eth0 -n -v -s0 udp port 9
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

22:09:33.209538 IP (tos 0x0, ttl 64, id 52416, offset 0, flags [DF], proto UDP (17), length 130)
    192.168.1.110.39220 > 192.168.1.18.9: UDP, length 102

22:09:36.893741 IP (tos 0x0, ttl 64, id 22576, offset 0, flags [DF], proto UDP (17), length 130)
    192.168.1.110.41489 > 192.168.1.255.9: UDP, length 102

22:09:38.227547 IP (tos 0x0, ttl 63, id 5077, offset 0, flags [DF], proto UDP (17), length 130)
    public_IP.3796 > 192.168.1.18.9: UDP, length 102

As per my experiments You can send the packet to:

• Case0: the broadcast address (within the LAN, for example 192.168.1.255)
• Case1: the IP of the device (within the LAN, for example 192.168.1.18). For this your Hub/Router may need an ARP table)
• Case2: the Public_IP of the router (for this you need to configure NAT and probably an ARP table*) which will be forwarded to the IP of the device (Case1)

* The ARP table is needed because after ~15 minutes of the device being disconnected, the Hub/Router won't remember the MAC address of the IP, and so it will refuse to send the packet as it won't know where/who to send it to.

Please do comment if I said anything wrong (to update it).