This reverts commit 3293d14628.
The position of tasks in the queue does not actually determine the order
in which they are activated. Instead this is determined by the
statements in task_manager_v2_t.initiate().
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.
Due to the issue described in c641974, purge() inadvertently destroyed
CA certificates that should have been kept (while the pointer to these
objects remained in the array). This lead to incorrect reference counts
and after a few reauthentications with multiple authentication rounds,
which cause calls to purge(TRUE), to crashes.
Because enumerate() for value based arrays returns a pointer directly to
the internal array elements and because array_remove_at() or rather the
called array_remove() may move elements over the element at the currently
enumerated position, the pointer passed to enumerate() will point to a
different array element after the array_remove_at() call. The caller
will thus operate on the wrong element if that pointer is accessed again
before calling enumerate().
For performance reasons we currently don't change the implementation to copy
each array element during enumeration to a private member of the enumerator and
return a pointer to that. Similarly, due to the danger of subtle bugs we don't
remember the pointer passed to enumerate() to later redirect it to a copy
created during the array_remove_at() call.
In the previous implementation queued jobs could prevent a service from
getting destroyed. This could have lead to a deadlock when the
processor is cancelled. Now destroy() still blocks, but waits only for
actually running tasks. The service instance is reference counted so that
queued jobs can safely be destroyed.
Calling on_accept() sometimes lead to deadlocks when service->destroy()
was called concurrently. That is, two threads waiting in on_accept() but
the last worker would only wake one due to the call to signal(). Calling
broadcast() wouldn't help either as that could lead to crashes if the thread
that called destroy() is woken first.
This is also more efficient as a constant pool of concurrent workers can
be maintained, otherwise peaks at the limit were followed by only a single
worker being active.
Due to how reauthentication works for IKEv1 we could get a second
IKE_SA, which might cause problems, when connectivity problems arise
when the connection is initially established.
Fixes#670.
We actually never deleted cached interfaces. So if the kernel reuses
interface indices events for newly created interfaces could have been
associated with interface objects of deactivated and deleted interfaces.
Since we also didn't update the interface name when such an interface
got reactivated we ended up using the old name e.g. to install routes.
A trigger for this was the deletion and recreation of TUN devices during
reauthentication of SAs that use virtual IPs.
Seems that packet counts can be retrieved after all. At least the Linux
and FreeBSD kernels treat the number of allocations as number of packets.
We actually installed packet limits in that field already.
Because this->thread is also read by threads that don't hold the
mutex the previous implementation was problematic (especially since
pthread_t is an opaque type of unknown length).
Fixes#654.
The condvar is signaled for every handled message received from the
kernel not only for replies (this changed with 2a2d7a4dc8). This may
cause segfaults because this->reply is not set when the waiting thread is
woken due to an IP address change.
Since this->reply is only set when it is actually the expected reply (and
only one request is sent at a time, thanks to c9a323c1d9) we only have
to make sure the reply is there (and clear it once we handled it).
Using separate condvars could also be an option in the future.
The package/library is called libjson-c on recent distributions.
Some like Ubuntu 14.04 provide symlinks with the old name but these
will eventually disappear. Using pkg-config allows us to easily check
for it (with a fallback) and configure the proper compiler flags.
Fixes#663.
This will result in an infinite loop as packets sent over that socket
will again pass through the TUN device and the DNS proxy.
Apparently, bypassing fails when airplane mode is enabled.
Fixes#662.
Adds a DNS proxy feature that uses VPN-protected sockets to resolve the
VPN gateway's hostname while reestablishing the IKE_SA, which is
required because we keep the TUN device up to avoid leaking plaintext
traffic.
The TUN device is recreated without DNS servers before reestablishing in
case the VPN server pushed DNS servers to the client that are only
reachable via VPN.
Fixes#622.
The IKE_SA is destroyed anyway, so letting the GUI remain in
"connecting" state would be incorrect.
We still use keyingtries=0 for now, though. And we still abort after the
first failed attempt initially, in case there is a configuration error.
Since VpnStateService.disconnect() is now not called until the error
dialog is dismissed the daemon would continue to try connecting.
So while the error dialog is shown the connection might actually be
successfully established in the background, which is not intended.
This way the IKE_SA is destroyed right after sending the IKE_SA_INIT of
the second connection attempt (due to keyingtries=0).
Non-DNS data is cached in the BuilderAdapter so the TUN device can be
recreated easily (since the CHILD_SA is gone we couldn't actually gather
that information).
This class proxies DNS requests over VPN-protected UDP sockets.
It is not really Android specific and might be useful for
kernel-libipsec or libipsec in general too, so we could maybe move it later
to libipsec (might need some portability work).
The GUI reflects the state of the IKE daemon more closely by switching
back to the "connecting" state when the IKE_SA or CHILD_SA is down and
is getting reestablished.
Fixes#616.
No matter what triggers it. We also don't close the TUN device, but we
might handle that differently in the future to allow reestablishing the
IKE_SA if host names have to be re-resolved via DNS.
Unless we are disconnecting. This currently triggers the connecting
dialog, perhaps just updating the status text would do too (when switching
from CONNECTED to CONNECTING, not from DISCONNECTED to CONNECTING).
Adds support to import CA and server certificate directly in the app.
On Android 4.4 and newer the SAF allows users to easily browse for such
files, on older systems they have to open them from file manager or the
download app (only works if the MIME type is correctly detected).
Also adds support for ECDSA keys on recent Android systems.
Since the import activity can be triggered by any other app on the
system we shouldn't just import every certificate we get.
Also, in some situations (e.g. if no passphrase has been set yet for the
system-wide certificate store) we are the only application that can open
certificate files. So if a user clicked on a certificate file she would
just get a confirmation Toast about a successful import, with no indication
whatsoever where the certificate was actually imported. The new dialog
shows the app icon to indicate that strongSwan is involved.
Thanks to the SAF, introduced with Android 4.4, browsing and opening
files on the system is very easy to implement.
On older systems the menu option is removed.
Tobias Brunner