This ensures we don't pass data (via msg_control) defined in a different
scope to sendmsg(). Actually, some compilers (e.g. GCC 5.2.1) might
optimize the memcpy() call away causing the packets not to get sent from
the intended source address.
It also makes the code clearer than with all these ifdefs.
Fixes#1171.
The `nat-local` and `nat-remote` keys contain information on the NAT
status of the local and remote IKE endpoints, respectively. If a
responder did not detect a NAT but is configured to fake a NAT situation
this is indicated by `nat-fake` (if an initiator fakes a NAT situation
`nat-local` is set). If any NAT is detected or faked `nat-any` is set.
Closesstrongswan/strongswan#16.
From recvfrom(2) (which UDPSocket#recv backs into):
The return value will be 0 when the peer has performed an orderly
shutdown.
(i.e. it will return an empty string)
Previously in this scenario, Vici::Transport#recv_all would spin
forever trying to pull more data off the socket. I'm not entirely
clear what happened that caused strongSwan to shutdown the socket, but
it probably should not cause vici Ruby apps to spin.
Closesstrongswan/strongswan#13.
Since 11c14bd2f5 CA certificates referenced in ca sections were
enumerated by two credential sets if they were also stored in
ipsec.d/cacerts. This caused duplicate certificate requests to
get sent. All CA certificates, whether loaded automatically or
via a ca section, are now stored in stroke_ca_t.
Certificates referenced in ca sections are now also reloaded
when `ipsec rereadcacerts` is used.
This may happen if something like `echo ... > /path/to/fifo` is used
before the plugin was able to create the FIFO. In that case we'd end
up in a loop always reading the same values from the static file.
strongSwan uses PrintableString when encoding DNs from strings (if the
character set permits it, otherwise T61String is currently used) but
certificates might be encoded with UTF8String even for simple ASCII strings.
By ignoring this string type when hashing RDNs we make sure the same hash
results in this case as long as the actual string values are the same.
Fixes#991.
If a client does Mode Config during reauthentication the assign_vips()
event might be triggered twice, we should not send another Start message
in that case.
Fixes#937.
Some clients won't do Mode Config or XAuth during reauthentication.
Because Start messages previously were triggered by TRANSACTION exchanges
none were sent for new SAs of such clients, while Stop messages were still
sent for the old SAs when they were destroyed. This resulted in an
incorrect state on the RADIUS server.
Since 31be582399 the assign_vips() event is also triggered during
reauthentication if the client does not do a Mode Config exchange.
So instead of waiting for a TRANSACTION exchange we trigger the Start
message when a virtual IP is assigned to a client.
With this the charon.plugins.eap-radius.accounting_requires_vip option
would not have any effect for IKEv1 anymore. However, it previously also
only worked if the client did an XAuth exchange, which is probably
rarely used without virtual IPs, so this might not be much of a
regression.
Fixes#937.
If AEAD algorithms are used no integrity algorithm will be received from
the other HA node. But since AUTH_UNDEFINED is 1024 and not 0 this value
was incorrectly added to the proposal, resulting in a failure during key
derivation. The variables are now explicitly initialized to 0, as already
was the case for the IKE SAs.
Fixes#1051.
When the IKE_SA is synced without the remote address, after a
reauthentication charon is not able to find it in its connected_peers
table since the destination host will be %any (it's missing in the
message, hence the default from the newly created ike_sa_t -- %any --
will be used).
By adding the value to the HA_IKE_ADD message, we should be able to
solve this problem.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
CDP and OCSP URIs for a one or multiple certification authorities
can be added via the VICI interface. swanctl allows to read
definitions from a new authorities section.
The vici logger uses the listener_t.log() callback to raise vici events.
When doing so, it holds the bus lock as reader while acquiring the vici socket
mutex (1). If at the same time the vici socket enables a writer, that thread
tries to lock the watcher mutex (2). The watcher thread uses debugging while
holding the lock, i.e. acquires the bus read lock (3).
(1) bus.rlock -> vici.lock!
(2) vici.lock -> watcher.lock!
(3) watcher.lock -> bus.rlock!
This all actually would resolve just fine, as we have a shared read lock on the
bus. However, under Windows we seem to have a strict writer preference when
acquiring the rwlock (4). This results in blocking read locks until any pending
write lock can be fulfilled, and makes the constellation deadlock. The relevant
threads are:
Thread (1)
6 0x71313d25 in wait_ at threading/windows/mutex.c:137
7 0x7054c8a2 in find_entry at vici_socket.c:201
8 0x7054d690 in send_ at vici_socket.c:624
9 0x7054f6c1 in send_op at vici_dispatcher.c:119
10 0x705502c1 in raise_event at vici_dispatcher.c:469
12 0x704c3878 in log_cb at bus/bus.c:332
13 0x712c7c3a in invoke_function at collections/linked_list.c:414
14 0x704c3a63 in vlog at bus/bus.c:400
15 0x704c3b36 in log_ at bus/bus.c:430
18 0x70508f1f in process_response at sa/ikev2/task_manager_v2.c:664
20 0x704f5430 in process_message at sa/ike_sa.c:1369
21 0x704e3823 in execute at processing/jobs/process_message_job.c:74
22 0x712e629f in process_job at processing/processor.c:235
Thread (2)
4 0x71313b61 in lock at threading/windows/mutex.c:66
5 0x712e81fd in add at processing/watcher.c:441
6 0x712e1ab9 in add_watcher at networking/streams/stream.c:213
7 0x712e1b4d in on_write at networking/streams/stream.c:237
8 0x7054d606 in _cb_enable_writer at vici_socket.c:609
9 0x712e5e34 in execute at processing/jobs/callback_job.c:77
10 0x712e629f in process_job at processing/processor.c:235
Thread (3)
3 0x71313f38 in read_lock at threading/windows/rwlock.c:74
4 0x704c3971 in vlog at bus/bus.c:373
5 0x704cc156 in dbg_bus at daemon.c:126
6 0x712e7bf9 in watch at processing/watcher.c:316
7 0x712e5e34 in execute at processing/jobs/callback_job.c:77
8 0x712e629f in process_job at processing/processor.c:235
Thread (4)
3 0x71313f70 in write_lock at threading/windows/rwlock.c:82
4 0x704c378b in remove_logger at bus/bus.c:290
5 0x704cb284 in listener_unregister at control/controller.c:166
6 0x713136cd in thread_cleanup_pop at threading/windows/thread.c:558
8 0x704cb94e in initiate at control/controller.c:435
9 0x70553996 in _cb_initiate at vici_control.c:187
12 0x7054d200 in _cb_process_queue at vici_socket.c:508
13 0x712e5e34 in execute at processing/jobs/callback_job.c:77
14 0x712e629f in process_job at processing/processor.c:235
To avoid such a situation, we dissolve the (1) lock sequence. It's actually
never good practice to acquire shared locks during bus hooks, as it is
problematic if we raise bus events while holding the lock. We do so by
raising vici events for log message asynchronously, but of curse must keep
log order as is using a synchronized queue.
Tobias Brunner