This fixes handling of SIGINT (CTRL+C) so we don't continue with the
next potentially hanging command (e.g. several pings after another that
fail because a required SA didn't come up correctly). We try to kill
the PID for every SIGINT in case the first one arrived before the
subshell was started. The `TDUP_<host>` variables are not updated in
the main shell when `stop_tcpdump` is called from the subshell, so
it is called redundantly during the cleanup (removed the useless guard
there and use pkill to suppress any messages if no process is found).
If we get interrupted during one of the init/cleanup WAIT_FOR waits,
we just let them running in the background when exiting the script.
They should generally not do any harm (and be terminated once the next
run is attempted, which might require a rebuild during development
anyway).
Since a103f3a284 ("testing: Add options to only run pre- or posttest
scripts of a scenario") we can now also skip the remaining steps easily.
However, we do run the posttest script to clean up properly (e.g.
terminate the daemons, restore firewall rules etc.). That's also why
it's not running in a subshell.
This reverts commit b998695344.
Seems like this is not necessary anymore. Possibly because of
8ff3238027 ("openssl: Prevent OpenSSL from using posix_memalign() if
LD is enabled").
This doesn't really seem useful (perhaps it was before we started to
configure the outbound interface on our routes). And it can actually
cause the route installation to fail e.g. for routes over point-to-point
interfaces where we'd get "Error: Nexthop has invalid gateway" errors.
Note that we can't return NULL if we find an interface as e.g. the updown
plugin uses this method to determine the outbound interface (it ignores
the nexthop), which it passes to the script. If we returned NULL, it
would pass "unknown" instead, which would cause the firewall rules to
mismatch. While it seems that 0.0.0.0/:: is ignored as nexthop by the
kernel on the installed route, I still explicitly ignore such addresses
to avoid any unintended side-effects.
The automatic route installation in the ikev2/shunt-manual-prio scenario
had to be disabled on the clients. The reason is that the route in table
220 won't have a nexthop set (the peers are directly connected), so when
trying to reach alice or venus via SSH, which matches the port-specific
bypass policies for which we don't install throw routes, the hosts will
do ARP requests for the target IPs instead of routing the packets via
moon.
Closesstrongswan/strongswan#2548
Clean up leak-detective whitelist for newer Botan versions but add
`botan_private_key_load` as `botan_privkey_load*` won't show up anymore
without bfd-backtraces due to inlining if we don't call it directly.
Ref: https://github.com/randombit/botan/discussions/4868
This ensures that packets on sun are processed on a particular CPU and
not randomly on one, which causes expected SAs not to get created or
other weird things.
Also remove the --enable-md4 option. We never supported MD4 via wolfSSL,
as it's not available via the hash API we use (would require explicit
MD4-specific functions and structures).
Seems that there is a delay before the disk can be used when using newer
QEMU versions (e.g. on Debian trixie). We get errors like these:
sfdisk: cannot open /dev/nbd0: Inappropriate ioctl for device
or
mount: /srv/strongswan-testing/build/loop: special device /dev/nbd0p1 does not exist.
A sleep before the next command seems to help.
Also see [1].
[1] https://gitlab.com/qemu-project/qemu/-/issues/1413
This new option allows to disable leak detective to reduce the runtime
during development. Either only for the command line (swanctl, pki etc.)
or optionally also for the daemon(s).
Disabling leak detective only for the CLI tools already brings a
considerable reduction in runtime (from 48m to 38m on my dev host) as
there are many such calls in the post-test stage. Any leaks in those
tools are also a lot less of an issue than leaks in the daemon. So using
this during development should be fine as long as a full test run is done
regularly (in particular before releases). Disabling leak detective
completely further reduces the runtime (to 30m on my dev host). But that
should probably only be used for functional regression tests after
verifying new code didn't introduce new leaks.
This also fixes the service script which is used for charon-tkm since
16fcdb460a ("charon-tkm: Don't use starter/stroke with charon-tkm anymore").
While some increase was necessary anyway because the idle system requires
about 5-10 MiB more memory, the main issue is resolving the code line and
function name in case of a memory leak. Calling addr2line requires a lot
more memory than before. Using backtraces via libbfd doesn't help either
because the trigger is the bfd_find_nearest_line() call we use as well.
And because we'd try to resolve all symbols that way (for whitelisting),
the memory overhead would be even higher and affect every shutdown, even
if no leak occurred. It also causes a significant time overhead (running
all tests took 75m instead of 48m).
I also tested switching to ASAN/LSAN. The peak memory usage is slightly
higher than when using libbfd, but enabling it also increased the runtime
overhead a lot (the daemon and swanctl both required about 10-20 MiB more
memory, not just during the shutdown).
Update revision for some dependency updates. While python3-setuptools is
installed on the system, the venv apparently can't use it. legacy-cgi is
required to use that old Django version with newer Python releases.
The API for libgmpada has change with 1.6 in a way that's not
backwards-compatible. So we use a different revision that includes
the required changes depending on the Debian version.
This also adds support for esa_select(), to support seamless rekeyings,
which requires updating xfrm-ada as well.
apt-key add is deprecated (and not available in trixie) as it makes the
available for all sources. The recommended approach makes the key very
specifically available for just our repository.
Debian trixie doesn't provide a 99-sysctl.conf symlink in that directory
anymore. The memory settings are also useful there as the default of
one changed and overbooking helps when forking a process with large
memory footprint (e.g. the IKE daemon).
We keep MD5 enabled for now as we need it for TLS 1.0/1.1. Once we
remove that we can reconsider (although, it's also needed for EAP-MD5
and since MD4 is disabled as well, which means EAP-MSCHAPv2 won't
be available, we'd be left with only EAP-GTC for simple username/password
authentication, which nobody else supports).
With a long delay, the retransmit might not get sent before further tests
are evaluated on faster machines, while more retransmits should still allow
the scenario to succeed on slower ones.
Tobias Brunner