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.
This won't hurt as long as sets and validators are of the same class.
But as soon as one of the object's class is changed this will cause
either a compile error (best option), or result (most likely) in a
crash.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
Tobias Brunner