Uses separate locks for socket read and write operations. While holding the
socket reader lock, a different thread can still claim the socket write lock.
This allows to asynchronously send event messages while holding the read
lock.
For some rwlock_t implementations acquiring the read lock could be quite
expensive even if there are no writers (e.g. because the implementation
requires acquiring a mutex to check for writers) particularly if the
lock is highly contended, like it is for the vlog() method.
Due to an unprotected incrementation, two load-tester initiators occasionally
use the same SPI under high load, and hence generate 2 IPsec SAs with the same
identifier. The responder IPsec stack will refuse to configure the second SA.
Use an atomic incrementation to avoid this race condition.
Signed-off-by: Christophe Gouault <[email protected]>
Due to an unprotected incrementation, two load-tester initiators occasionally
use the same identifier under high load. The responder typically drops one of
the connections.
Use an atomic incrementation to avoid this race condition.
Signed-off-by: Christophe Gouault <[email protected]>
This patch is based on one by Christoph Gouault.
Currently, to count the total number of half_open IKE_SAs,
get_half_open_count sums up the count of each segment in the SA hash
table (acquiring a lock for each segment). This procedure does not scale
well when the number of segments increases, as the method is called for
each new negotiation.
Instead, lets maintain a global atomic counter.
This optimization allows the use of big values for charon.ikesa_table_size
and charon.ikesa_table_segments.
If one peer starts reauthentication by deleting the IKE_SA, while the other
starts CHILD_SA rekeying, we run in a race condition. To avoid it, temporarily
reject the rekey attempt while we are in the IKE_SA deleting state.
RFC 4306/5996 is not exactly clear about this collision, but it should be safe
to reject CHILD_SA rekeying during this stage, as the reauth will re-trigger the
CHILD_SA. For non-rekeying CHILD_SA creations, it's up to the peer to retry
establishing the CHILD_SA on the reauthenticated IKE_SA.
The extensions and conditions apply to the rekeyed IKE_SA as well, so we should
migrate them. Especially when using algorithms from private space, we need
EXT_STRONGSWAN to properly select these algorithms during IKE rekeying.
Even in Main Mode, some Sonicwall boxes seem to send ID/HASH payloads in
unencrypted form, probably to allow PSK lookup based on the ID payloads. We
by default reject that, but accept it if the
charon.accept_unencrypted_mainmode_messages option is set in strongswan.conf.
Initial patch courtesy of Paul Stewart.
Before this change a reqid set on the create_child_t task was used as
indicator of the CHILD_SA being rekeyed. Only if that was not the case
would the local traffic selector be changed to 0.0.0.0/0|::/0 (as we
don't know which virtual IP the gateway will eventually assign).
On the other hand, in case of a rekeying the VIP is expected to remain
the same, so the local TS would simply equal the VIP.
Since c949a4d501 reauthenticated CHILD_SAs also have the reqid
set. Which meant that the local TS would contain the previously
assigned VIP, basically rendering the gateway unable to assign a
different VIP to the client as the resulting TS would not match
the client's proposal anymore.
Fixes#553.
Martin Willi