Open thomasschaeferm opened 7 months ago
Whether to use ipv6, is detected automatically from the ip address given. It’s also possible to pass a domain name, e.g. localhost
or google.com
. If a domain is passed, the ip version can’t be used automatically. The -6
flag is to support domain names that use ipv6. If the network is unreachable, you can try explicitly specifying the interface to use using the -n
flag.
Pinging @alimg for verification, because they implemented this feature in #26.
usage: wakeonlan [-h] [-6] [-i ip] [-p port] [-n interface] mac address [mac address ...]
./wakeonlan -n eth0 -6 -i 2001:a61:483:c901:1e6f:65ff:fec9:8746
wakeonlan: error: the following arguments are required: mac address
./wakeonlan -n eth0 -6 fusion.tschaeferm.dynv6.net
or
./wakeonlan -n eth0 -6 1C:6F:65:C9:87:46
dont work
You write a tool as not planned to work. That is crazy.
@thomasschaeferm, the error message you got in your first command clearly states what was missing. You must always provide a mac address along with the ip address. The -i
option is not a substitute of mac address, so your command line should look like ./wakeonlan -n eth0 -6 -i <ip-or-hostname> <mac-address>
The limitation @remcohaszing mentioned about automatic ipv6 detection with domains is true. I should clarify although its not explicitly documented in the CLI help message, the -i
option actually accepts an hostname in place of an ip address.
Please also note that the CLI defaults to broadcast ip (255.255.255.255
) when the -i
option is omitted. This is not a valid ipv6 address, so if your interface does not have an ipv4 there is nothing that the tool can actually do. There is no such thing as broadcast ip in ipv6 networks. If you are looking for waking up more than one machine in your network, I suppose your best bet is to figure out a multicast address that works for you.
So the -i
is optional for IPv4 and if omitted defaults to IPv4 broadcast (255.255.255.255), but is mandatory in IPv6? Which then probably leads to the issue here where the CLI help indicates the parameter as optional, but in some cases it is actually mandatory?
Why not use the all nodes multicast for IPv6 in order to mirror the IPv4 behaviour? The interface is then already supplied in that case, so it should be able to construct ff02::1%<interface>
for the all nodes multicast out that interface?
other tools
./pywake 1C:6F:65:C9:87:46
sending IPv6 packet to IP ff02::1 for MAC 1C:6F:65:C9:87:46
@thomasschaeferm wrote:
You write a tool as not planned to work. That is crazy.
Be respectful. This is an OSS project that’s created and maintained by volunteers, so you get to use it for free.
My takeaway from further discussion is that this project does work as intented, but it has some confusing behaviour. I’m thinking of the following solution:
ip
argument to hostname
, with the -o
and --hostname
CLI flags. (-h
already means help.)--interface
short flag from -n
to -i
, since -i
is no longer taken.hostname
from 255.255.255.255
to None
.hostname
is an IPv4 address, ignore the address_family
option. Always use IPv4.hostname
is an IPv6 address, ignore the address_family
option. Always use IPv6.hostname
is None
and address_family
is AF_INET6
, use ff02::1
as the hostname.hostname
is None
and address_family
is not AF_INET6
, use 255.255.255.255
as the hostname.hostname
something else, respect address_family
as-is, default to AF_INET
.These are breaking changes, so this requires a semver major release.
Any thoughts?
At an ipv6-only host I get only that
without
-6
option it also doesn't work: