The reference to this is <https://sourceware.org/glibc/wiki/NameResolver>,
which mentions:
"From the perspective of the application that calls getaddrinfo() it
perhaps doesn't matter that much since EAI_FAIL, EAI_NONAME and
EAI_NODATA are all permanent failure codes and the causes are all
permanent failures in the sense that there is no point in retrying
later."
This should cover more early-boot situations.
While we're at it, we clean up the logic a bit so that we don't have a
retry message on the final non-retrying attempt. We also peer into errno
when receiving EAI_SYSTEM, to report to the user what actually happened.
Also, fix the quoting back tick front tick mess.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
DaveM suggests we do in fact do this. Others on the same thread weren't
happy about the length of the proposed message, so we also give a bit of
a less dramatic warning.
This reverts commit a2cc976a3b572cf308cc2d97c080eacac60416fe.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Also prefix octal 0, in case these files are actually of modes that
don't start with 0 by accident (such as SUID or sticky bit).
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This helps with old Debian which has ancient iproute2, as well as paving
the path toward this script supporting userspace implementations.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This doesn't actually fix a real problem, but it is more correct than
not having it.
Suggested-by: Aaron Sigel <aaron@vtty.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Maybe an attacker on the system could use the infoleak in /proc to gauge
how long a wg(8) process takes to complete and determine the number of
leading zeros. This is somewhat ridiculous, but it's possible somebody
somewhere might at somepoint care in the future, so alright.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This was only required because clueless network operators were trying to
route fec0::/10 globally, when that range doesn't actually have global
scope. Now that we understand the cause was operator error, we revert
the change here, so that the routing table is kept consistent.
This reverts commit 64e47de870a2f0575b5564a70e5680b48ab83ff9.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Otherwise, we wind up not doing the right thing in the v6-only case, or
doing something totally borked when v4 and v6 are filled unevenly.
Reported-by: Roelf Wichertjes <contact@roelf.org>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
While OpenResolv supports explicit ordering directives such as `-m` and
exclusivity directives such as `-x`, Debian's own resolvconf supports
none of this, instead using a hard coded list of interface name
templates for determining ordering. While trying to emulate `-x` is
difficult [*], we can at least try to mostly emulate `-m 0` by
masquerading as a `tun*` interface to resolvconf. Ugly, but it works.
[*] One heavy handed way of emulating `-x` would be something like:
# echo nameserver 8.8.8.8 > /etc/resolv.conf.wg0-exclusive
# mount --bind -o ro /etc/resolv.conf.wg0-exclusive /etc/resolv.conf
# rm -f /etc/resolv.conf.wg0-exclusive
This in practice works quite well, but is a bit heavy to put in a man
page. It also doesn't "stack" well. For example, if we simply run
`umount /etc/resolv.conf`, how do we know which resolv.conf entry we're
unmounting?
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Otherwise, traffic is sent with the IP address of a different interface,
and then packets don't actually get delivered.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Jason A. Donenfeld
Samuel Holland
Jake McGinty