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]>
While it really would be desirable to allow stream destruction during on_read()
callbacks, this does not work anymore since e49b2998. Until we have a proper
solution for this issue, use asynchronous disconnects for the only user doing
so.
Fixes#518.
The additional 6 bytes are not actually padding but are parsed by the
Cisco client as protocol and src and dst ports (each two bytes but
strangely only the first two in network order).
In certain situations it is desirable to bind the send/receive sockets
for the DHCP address allocation to a particular interface. With this
patch the strongswan.conf option charon.plugins.dhcp.interface can be
used to restrict the DHCP communication to a configurable interface.
Signed-off-by: Thomas Egerer <[email protected]>
The child_updown() function sets up environment variables to the updown
script. Sometimes call to hydra->kernel_interface->get_interface() could
fail and iface variable could be left uninitialized. This patch fixes
this issue by passing "unknown" as interface name.
Here is the stacktrace:
0 0x00007fa90791f445 in raise () from /lib/x86_64-linux-gnu/libc.so.6
1 0x00007fa907922bab in abort () from /lib/x86_64-linux-gnu/libc.so.6
2 0x0000000000401ed7 in segv_handler (signal=11) at charon.c:183
3 <signal handler called>
4 0x00007fa90793221f in vfprintf () from /lib/x86_64-linux-gnu/libc.so.6
5 0x00007fa9079f0580 in __vsnprintf_chk () from /lib/x86_64-linux-gnu/libc.so.6
6 0x00007fa9079f04c8 in __snprintf_chk () from /lib/x86_64-linux-gnu/libc.so.6
7 0x00007fa8f9b95b86 in snprintf (
__fmt=0x7fa8f9b961b8 "2>&1 PLUTO_VERSION='1.1' PLUTO_VERB='%s%s%s' PLUTO_CONNECTION='%s' PLUTO_INTERFACE='%s' PLUTO_REQID='%u' PLUTO_ME='%H' PLUTO_MY_ID='%Y' PLUTO_MY_CLIENT='%H/%u' PLUTO_MY_PORT='%u' PLUTO_MY_PROTOCOL='%u"..., __n=1024, __s=0x7fa8f7923440 "2>&1 PLUTO_VERSION='1.1' PLUTO_VERB='up-host' PLUTO_CONNECTION='remote-40.0.0.40' PLUTO_INTERFACE='\367\250\177")
at /usr/include/x86_64-linux-gnu/bits/stdio2.h:65
8 child_updown (this=0x8486b0, ike_sa=0x7fa8e4005f80, child_sa=0x7fa8d4008290, up=true) at updown_listener.c:308
9 0x00007fa907ecc11c in ?? () from /usr/lib/strongswan/libcharon.so.0
10 0x00007fa907ef89bf in ?? () from /usr/lib/strongswan/libcharon.so.0
11 0x00007fa907ef2fc8 in ?? () from /usr/lib/strongswan/libcharon.so.0
12 0x00007fa907ee84ff in ?? () from /usr/lib/strongswan/libcharon.so.0
13 0x00007fa907ee3067 in ?? () from /usr/lib/strongswan/libcharon.so.0
14 0x00007fa90835e8fb in ?? () from /usr/lib/strongswan/libstrongswan.so.0
15 0x00007fa908360d30 in ?? () from /usr/lib/strongswan/libstrongswan.so.0
16 0x00007fa907cade9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
17 0x00007fa9079db4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
18 0x0000000000000000 in ?? ()
Signed-Off-By: Ansis Atteka <[email protected]>
Due to the previous negation the high bits of the mask were set, which
at least some versions of the Android build system prevent with a compile-time
check.
Martin Willi