When roaming from a mobile network to WiFi on Android 5.x the event
received via ConnectivityManager is triggered before the mobile
connection is fully torn down (i.e. before the interface is disabled and
the routes disappear). So for strongSwan the current path still seems
valid and since no roam event is triggered later the daemon never switches
to WiFi and the connection is broken afterwards.
A possible solution to this is enabling roam events in the kernel-netlink
plugin. That would trigger an event when the device is finally disconnected
from the mobile network. However, this could actually take a some time,
during which traffic continues to be sent via mobile network instead of WiFi.
That's because Android now uses multiple routing tables, routing rules and
fwmarks to direct traffic to the appropriate interface/table, but in our
plugin we don't have the information available that would allow us to make
the switch to a different network/routing table earlier (and we actually
prefer the current path if it is still valid). Additionally, the plugin
produces quite a bit more events than ConnectivityManager (which was one
of the reasons to use the latter in the first place).
This custom kernel-net implementation is now specifically tailored for
Android. Roam events are still triggered via ConnectivityManager but
the source address is determined via connect()/getsockname() on a VPN
excluded UDP socket, which does use the correct routing table as intended
by Android. That way the daemon immediately sees a different source IP
when connectivity changes even if the device is connected to multiple
networks concurrently.
This fixes an issue when using the Android M preview. Bionic's dynamic
linker was changed so that symbols in libraries loaded with RTLD_LOCAL
were not found anymore in dlsym(RTLD_DEFAULT, ...). This is the case
for libraries loaded with System.loadLibrary(), therefore, the plugin
loader in libstrongswan was not able to resolve any symbols defined in
other libraries loaded later. While this seems to have been broken
unintentionally for existing apps (fix at [1]), it will again be a
problem whenever we decide to increase targetSdkVersion beyond 22 (or
until that fix makes it into the system/emulator images).
Unfortunately, the dynamic loader in releases prior to Android 4.3 can't
load libandroidbridge without also loading its dependencies.
[1] https://github.com/android/platform_bionic/commit/1913352c6b
This also adds a new area for advanced settings that is only displayed
if the user requests it (or if advanced settings already have been set).
The min. MTU for IPv6 is 1280, anything lower lets the TUN device
creation fail if an IPv6 address has been assigned. If lower MTUs are
necessary we might be able to catch that later when setting the MTU and
just use at least 1280 if an IPv6 address was assigned, but let's keep
it simple for now.
This generalization allows the ring dimension n to be different
from the current n = 512 and allows kappa to be > 56. Also the
hash octets are consumed in a more consistent manner.
The c_indices derived from the SHA-512 random oracle consist of
nine bits (0..511). The leftmost 8 bits of each index are taken
on an octet-by-octet basis from the 56 leftmost octets of the
SHA-512 hash. The 9th bit needed for the LSB is taken from the
extra_bits 64 bit unsigned integer which consists of the 8 rightmost
octets of the SHA-512 hash (in network order). If more than 56
indices must be derived then additional rounds of the random oracle
are executed until all kappa c_indices have been determined.
The bug fix shifts the extra_bits value by one bit in each loop
iteration so that the LSB of each index is random. Also iterate
through the hash array using the loop variable j not the c_indices
variable i.
The destroy() method sets the IKE_SA on the bus to NULL, we reset it to
the current IKE_SA so any events and log messages that follow happen in
the correct context.
A practical example where this is problematic is a DH group mismatch,
which causes the first CREATE_CHILD_SA exchange to fail. Because the SA
was not reset previously, the message() hook for the CREATE_CHILD_SA
response, for instance, was triggered outside the context of an IKE_SA,
that is, the ike_sa parameter was NULL, which is definitely not expected
by several plugins.
Fixes#862.
Changes how acquires are tracked in the trap manager, which fixes
several race conditions. Also fixes races between threads installing
trap policies and the main thread trying to flush the trap policies.
Similar changes were added to the shunt manager which previously
used no locking at all.
Fixes#1014.
When flush() is called there might be threads in install() waiting for
trap policies to get installed (without holding the lock). We have to
wait until they updated the entries with the respective CHILD_SAs before
destroying the list.
We also have to prevent further trap policy installations (and wait until
threads in install() are really finished), otherwise we might end up
destroying CHILD_SA objects after the kernel interface implementations
have already been unloaded (avoiding this is the whole point of calling
flush() before unloading the plugins).
This fixes potential race conditions in case complete() or flush() is
executed before or concurrently with a thread that handles an acquire.
It will also simplify tracking multiple acquires created for the same
trap policy in the future.
Also fixes the behavior in some error situations.
This basically reverts f4e822c1b4 ("trap-manager: don't check-in
nonexisting IKE_SA if acquire fails"). As checkout_by_config() could
return an already existing and established IKE_SA we have to properly
destroy it, for instance, in case other threads are waiting to check
it out. checkin_and_destroy() should handle the case of a new SA
properly (it produces a log message on level 1, though).
In some situations it might be valid for a host that configures
right=%any to reestablish or reauthenticate an IKE_SA. Using %any would
immediately abort the initiation causing the new SA to fail (which
might already have the existing CHILD_SAs assigned).
Fixes#1027.
If static local addresses are configured we should use their address family
as a hint when resolving the remote address.
We don't do this if %any is configured as this might break existing
configurations (%any4 and %any6 are however used as hint).
Tobias Brunner