aacf84d837 ("testing: Add expect-connection calls for all tests and
hosts") removed the expect-connection call for the non-existing aaa
connection. However, because the credentials were loaded asynchronously
via start-script the clients might have been connecting when the secrets
were not yet loaded. As `swanctl --load-creds` is a synchronous call
this change avoids that issue without having to add a sleep or failing
expect-connection call.
If a called script interacts with the daemon or one of its plugins
another thread might have to acquire the write lock (e.g. to configure a
fallback or set a value). Holding the read lock prevents that, potentially
resulting in a deadlock.
This took a while as in the OpenSSL package shipped with Debian and on which
our FIPS-enabled package is based, the function SSL_export_keying_material(),
which is used by FreeRADIUS to derive the MSK, did not use the correct digest
to calculate the result when TLS 1.2 was used. This caused IKE to fail with
"verification of AUTH payload with EAP MSK failed". The fix was only
backported to jessie recently.
While this is not the latest 2.x release it is the latest in /old.
Upgrading to 3.0 might be possible, not sure if the TNC-FHH patches could
be easily updated, though. Upgrading to 3.1 will definitely not be possible
directly as that version removes the EAP-TNC module. So we'd first have to
get rid of the TNC-FHH stuff.
Even if not using caching when running the configure script (-C) this
allows pre-defining the result by setting the environment variable
ss_cv_func_pthread_condattr_setclock_monotonic=yes|no|unknown
before/while running the script.
As the check requires running a test program this might be helpful
when cross-compiling to disable using monotonic time if
pthread_condattr_setclock() is defined but not actually usable with
CLOCK_MONOTONIC.
References #1502.
fgetc() returns an int and EOF is usually -1 so when this gets casted to
a char the result depends on whether `char` means `signed char` or
`unsigned char` (the C standard does not specify it). If it is unsigned
then its value is 0xff so the comparison with EOF will fail as that is an
implicit signed int.
Updates the default Debian image used for the test environment from wheezy
to jessie. Also adds a script that allows chrooting to an image (base,
root or one of the guests). In pretty much all test scenarios
expect-connection is used to make test runs more reliable.
Fixes#1382.
There is a bug (fix at [1]) in hostapd 2.1-2.3 that let it crash when used
with the wired driver. The package in jessie (and sid) is affected, so we
build it from sources (same, older, version as wpa_supplicant).
[1] http://w1.fi/cgit/hostap/commit/?id=e9b783d58c23a7bb50b2f25bce7157f1f3
Sometimes tcpdump fails to process all packets during the short running
time of a scenario:
0 packets captured
18 packets received by filter
0 packets dropped by kernel
So 18 packets were captured by libpcap but tcpdump did not yet process
and print them.
This tries to use --immediate-mode if supported by tcpdump (the one
currently in jessie or wheezy does not, but the one in jessie-backports
does), which disables the buffering in libpcap.
However, even with immediate mode there are cases where it takes a while
longer for all packets to get processed. And without it we also need a
workaround (even though the version in wheezy actually works fine).
That's why there now is a loop checking for differences in captured vs.
received packets. There are actually cases where these numbers are not
equal but we still captured all packets we're interested in, so we abort
after 1s of retrying. But sometimes it could still happen that packets
we expected got lost somewhere ("packets dropped by kernel" is not
always 0 either).
The main difference is that ping now reports icmp_seq instead of
icmp_req, so we match for icmp_.eq, which works with both releases.
tcpdump now also reports port 4500 as ipsec-nat-t.
Several packages got renamed/updated, libgcrypt was apparently installed
by default previously.
Since most libraries changed we have to completely rebuild all the tools
installed in the root image. We currently don't provide a clean target in
the recipes, and even if we did we'd have to track which base image we
last built for. It's easier to just use a different build directory for
each base image, at the cost of some additional disk space (if not manually
cleaned). However, that's also the case when updating kernel or
software versions.
It is still compatible with the current release as the config in
sites-available will be ignored, while conf-enabled does not exist and
is not included in the main config.
Unlike `apt-get install` in a chroot debootstrap does not seem to start
the services but stopping them might cause problems if they were running
outside the chroot.
Newer versions of GCC are too "smart" and replace a call to malloc(X)
followed by a call to memset(0,X) with a call co calloc(), which obviously
results in an infinite loop when it does that in our own calloc()
implementation. Using `volatile` for the variable storing the total size
prevents the optimization and we actually call malloc().
This fixes DNS server installation if make-before-break reauthentication
is used as there the new SA and DNS server is installed before it then
is removed again when the old IKE_SA is torn down.
If running resolvconf fails handle() fails release() is not called, which
might leave an interface file on the system (or depending on which script
called by resolvconf actually failed even the installed DNS server).
Changes how the interface for routes installed with policies is
determined. In most cases we now use the interface over which we reach the
other peer, not the interface on which the local address (or the source IP) is
installed. However, that might be the same interface depending on the
configuration (i.e. in practice there will often not be a change).
Routes are not installed anymore for drop policies and for policies with
protocol/port selectors.
Fixes#809, #824, #1347.
We don't need them for drop policies and they might even mess with other
routes we install. Routes for policies with protocol/ports in the
selector will always be too broad and might conflict with other routes
we install.