The flag is required to convince libtool on Cygwin to build DLLs. But on
Windows these shared libraries can not have undefined symbols, so we have to
link them explicitly to the libraries they reference.
For plugins this is currently not done, so only the monolithic build is
supported. The plugin loader wouldn't be able to load DLLs anyway, as
it tries to load files that don't exist on Cygwin.
INCLUDES are now deprecated and throw warnings when using automake 1.13.
We now also differentiate AM_CPPFLAGS and AM_CFLAGS, where includes and
defines are passed to AM_CPPFLAGS only.
This new flag gives the kernel-interface a hint how it should priorize the
use of newly installed SAs during rekeying.
Consider the following rekey procedure in IKEv2:
Initiator --- Responder
I1 -------CREATE-------> R1
I2 <------CREATE--------
-------DELETE-------> R2
I3 <------DELETE--------
SAs are always handled as pairs, the following happens at the SA level:
* Initiator starts the exchange at I1
* Responder installs new SA pair at R1
* Initiator installs new SA pair at I2
* Responder removes old SA pair at R2
* Initiator removes old SA pair at I3
This makes sure SAs get installed/removed overlapping during rekeying. However,
to avoid any packet loss, it is crucial that the new outbound SA gets
activated at the correct position:
* as exchange initiator, in I2
* as exchange responder, in R2
This should guarantee that we don't use the new outbound SA before the peer
could install its corresponding inbound SA.
The new parameter allows the kernel backend to install the new SA with
appropriate priorities, i.e. it should:
* as exchange inititator, have the new outbound SA installed with higher
priority than the old SA
* as exchange responder, have the new outbound SA installed with lower
priority than the old SA
While we could split up the SA installation at the responder, this approach
has another advantage: it allows the kernel backend to switch SAs based on
other criteria, for example when receiving traffic on the new inbound SA.
This might happen on Android if sockets are bound to the physical IP
address but packets are still routed via TUN device. Since it seems to
happen quite often (or for stuff that requires regular traffic) this
hides these messages from the default log.
Two callbacks can be registered that get called when new inbound plaintext and
outbound ESP packets have been processed. Inbound ESP and outbound plaintext
packets can be queued for processing with two other methods.
Martin Willi