Since 4b670a20 we require an explicit strongswan.conf to re-load configurations.
However, the define was missing in the build, breaking SIGHUP based config
reloading.
Fixes#651.
This allows to (relatively) quickly (re-)build and install the current
or an arbitrary strongSwan source tree within the root image.
bindfs is used to bind mount the source directory using the regular user
and group (only works if sudo is used to run the script) so that newly
created files are not owned by root.
As with building the root image in general the guests must not be
running while executing this script. The guest images are automatically
rebuilt after the root image has been updated so configuration files and
other modifications in guests will be lost.
We don't expect a response with the same MID, but apparently some
devices (e.g. FRITZ!Box) do that for DPDs, while still treating the
response as a new exchange. By storing the last message block as IV
we can't decrypt the first block of such a response.
Fixes#661.
While the examples in RFC 2408 show proposal numbers starting at 1 and
increasing by one for each subsequent proposal this is not mandatory.
Actually, IKEv1 proposals may start at any number, the only requirement
is that the proposal numbers increase monotonically they don't have to
do so consecutively.
Most implementations follow the examples and start numbering at 1 (charon,
racoon, Shrew, Cisco, Windows XP, FRITZ!Box) but pluto was one of the
implementations that started with 0 and there might be others out there.
The previous assumption that implementations always start numbering proposals
at 0 caused problems with clients that start numbering with 1 and whose first
proposal consists of multiple protocols (e.g. ESP+IPComp).
Fixes#661.
This might not be the case if e.g. an address appeared but the old one
is still available but not actually usable. Without this the MOBIKE
task would eventually time out even though we might be able to switch
to a working address.
Because we only queue one MOBIKE task at a time, but destroy superfluous
ones only after we already increased the counter for pending MOBIKE updates,
we have to reduce the counter when such tasks are destroyed. Otherwise, the
queued task would assume another task is queued when it is running and
ignore any successful response.
Martin Willi