TUN/TAP interfaces were separated in 2015 (since OpenBSD 5.9 or 6.0),
requiring adjustments in fastd. This makes fastd incompatible with older
OpenBSD versions (in TAP mode).
Fixes: #2
Fixes TUN and Multi-TAP modes with multiple peers.
The script is not converted to USE_PROCD, as we still want to have full
control over stdin and daemonization.
Also improve error handling with -o pipefail.
Fixes: #3
Deprecating and eventually removing the current little-endian handshake
format just causes unnecessary churn for users without objective benefit.
The only field that was unconditionally encoded as big-endian before is
"error detail"; as this is also variable-length and was never longer
than 1 byte in practice (and it will not be for a long time), we can also
switch that around to little-endian without any compatiblity issues.
By specifying port 0, fastd will statically bind to a random port
(rather than recreating the socket for each connection attempt).
While we're at it, clean up bind address handling a bit and also pass
"default" bind address via the new flags field.
The docs docs are updated as well (they were incorrect before, a port 0
bind was simply rejected).
It seems that newer kernels fail with ENETUNREACH instead of EINVAL with
an invalid source address in pktinfo.
This fixes fast reconnect on source address change.
When compiled with musl >1.1.20, fastd will crash in case it can't
resolve a peers hostname. This is due to a changed implementation of
freeaddrinfo in musl 1.1.21 onwards.
This segfault is fixed by not calling freeaddrinfo in case the supplied
pointer is null.
Signed-off-by: David Bauer <mail@david-bauer.net>
Currently, the CMakeList.txt completely overwrites the CMAKE_MODULE_PATH
variable.
This is problematic when an upper-layer buildsystem wants to set its own
module path to use custom modules.
For example, Buldroot [0] provides a custom platform description [1] to fix
cross-compilation issue. Overwriting the module path means that this
custom platform description is not found [2].
Providing such a custom platform description is what the upstream cmake
devs suggest [3], quoting:
If a toolchain file specifies CMAKE_SYSTEM_NAME such that a custom
`Platform/MySystem.cmake` file is loaded then the latter can set
them [*] as needed for the target platform.
[*] offending settings causing RPATH issues during cross-compilation.
So we need to append our source tree to the module path, not replace it
blindly.
[0] https://buildroot.org/
[1] https://git.buildroot.org/buildroot/tree/support/misc/Buildroot.cmake
[2] http://autobuild.buildroot.net/results/69f/69fb2e3b549a069e2898506db918423e6742c589/build-end.log
[3] http://public.kitware.com/pipermail/cmake/2017-February/065063.html
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>