permit hostname for mac addr argument, resolved via /etc/ethers

[jmtd]

It would be nice if we could specify a hostname in place of the MAC address argument, and for wakeonlan to attempt to look this up via nss/nsswitch/the ethers db (e.g. /etc/ethers).

Note that this would be to resolve a hostname to a MAC address, not to specify an IP for the WOL packet.

Examples

$ getent ethers coil
e0:4f:43:e6:2b:36 coil
$ wakeonlan $(getent ethers coil | awk '{ print $1 }')
Sending magic packet to 255.255.255.255:9 with e0:4f:43:e6:2b:36

getent(1) implies that the libc function to do this correctly is ether_hostton.

[petterreinholdtsen]

A patch implementing /etc/ethers has been included in the Debian edition since 0.41-3, see https://bugs.debian.org/296825 and https://salsa.debian.org/debian/wakeonlan/-/blob/master/debian/patches/01-etcethers?ref_type=heads .

[jmtd]

Hi @petterreinholdtsen , thank you for looking after the Debian package which is benefiting from your attention.

The Debian patch only matches hostnames if the hostname can be resolved to an IP by the running host's netwrok configuration, which is unnecessary. if the entry is e.g.

08:00:20:00:61:CA  pal

(example from ethers(5), to show that hostnames in ethers is valid)

then the patch attempts to resolve 'pal' to an IP via gethost, That's completely unnecessary if the name is determined not to be an IP address, we know we have the right line, we just need the MAC extracted.

In my case the name is not resolvable, it's assigned by zeroconf once the host is up.

[petterreinholdtsen]

Good observations. Not sure if it matter much, as I believe it would be best practice to list pal in /etc/hosts too when using /etc/ethers like in your example. In any case, I do not plan to work on the patch, and leave it to others to improve it. I just wanted to make sure you were aware of it.

…

-- Happy hacking Petter Reinholdtsen