This allows re-connecting to a new session in a disconnect listener and
continue listening without having to return from listen(). The exception
can also be used to stop listening after some condition (e.g. to wait
until a specific SA got created and then stop).
The bus alert infrastructure is currently exposed through the error-notify
plugin using a dedicated socket using a rather archaic message format.
Vici clients would need a dedicated socket connection just to receive such
alert messages, making their implementation more complex.
With vici, it is rather trivial to expose bus alerts through a dedicated
event message that vici clients may subscribe to. Add such an "alert"
event type to vici. Alert names are mapped to strings for simple consumption by
clients.
For now, the error-notify string message is omitted from events, as it mostly
contains static information without much value; instead add the IKE_SA details
for alerts associated to an IKE_SA. Other alert specific data may be added in
the future if needed; preferably using a structured format instead of the
arbitrary string messages used by error-notify. To allow future extensions,
wrap IKE_SA details under a dedicated "ike-sa" property.
Was apparently forgotten when support was added to the attr plugin
with 98a3ba8a5a ("attr: Add p-cscf keyword for P-CSCF server addresses").
For consistency, using an underscore like the `split*` options and not a
dash like in the attr plugin.
References strongswan/strongswan#2396
Optionally with "dynamic" traffic selectors resolved. A new method
is added for those cases where we actually want to select potentially
narrowed traffic selectors using a supplied list. The latter now also
always logs details, while the former does not.
Threads initiating SAs can get stuck on the semaphore in
wait_for_listener() during shutdown if the corresponding job is never
executed. A particular case when this can happen is if more initiations
are triggered than worker threads are available. This causes a (known)
deadlock as no workers are free anymore to process jobs (for inbound
messages or timeouts etc.), including the one to initiate an SA.
This change at least allows a proper shutdown.
Increase buffer to 32 bytes to hold uint64_t completely and check for
overflows after multiplication with size modifiers.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
Directly calling setup.py is deprecated (apparently has been for a while,
but now we get large warnings). Direct installation is also discouraged.
So this removes that option. The built wheel (the old egg format is not
used/built anymore) can be installed manually in a venv or the like.
The previous approach had two drawbacks:
First, it caused duplicate public keys because when the `certificate_t`
object was created and added to the credential set it had no subject
assigned yet. So it defaulted to the key ID. However, all previously
loaded keys had their subject already changed to an identity, so there
never was a match and new objects were always added whenever a config
with raw public keys was loaded.
Second, the subject was replaced in a way that's not thread-safe on an
object that's already shared in the public credential set. So other
threads could potentially access the `identification_t` object that's
destroyed during that process.
References strongswan/strongswan#853Closesstrongswan/strongswan#2561
The order was different when not setting `esp_proposals` or explicitly
configuring `default`.
Fixes: 33412158f5 ("ike: Send AEAD ESP default proposal first")
This is particularly important for IKE_SAs that are not yet established,
which would get terminated as they have no established CHILD_SAs yet.
Fixes: 72f9a21b22 ("Merge branch 'vici-reload-actions'")
The previous code had some issues because it handled each child config
separately. Not only was this quite inefficient because all IKE_SAs had
to be enumerated for every config, it also caused problems with the check
for other CHILD_SAs in order to decide whether to delete the IKE_SA or
not. Because CHILD_SAs are deleted with an INFORMATIONAL exchange, they
are not immediately gone. This caused a race condition and with more
than one child config and SAs the IKE_SA could be kept because it
could appear as if other, unrelated CHILD_SAs were still there.
Another race condition, which is fixed by the previous commit, occurred
when only changing child configs. Then it could happen that the code
deemed the IKE_SA empty and a delete for it was queued. If that happened
while the IKE_SA was deleting one of the CHILD_SAs (or was busy with some
other exchange), the IKE_SA was not switched to IKE_DELETING. So it
looked usable and create-child tasks for the updated configs might have
gotten queued. Unfortunately, once the ike-delete task is eventually
executed, these tasks would be gone and the replacement CHILD_SAs never
created. This commit additionally avoids actually deleting the IKE_SA
even if all child configs change or get removed if any new CHILD_SAs are
to be initiated.
The previous option caused such requests to be enabled if not explicitly
disabled, which only the vici plugin did, for all other backends requests
would have been sent.
References strongswan/strongswan#2016
socket.connect() takes a single argument with the address that depends
on the address family, for TCP it's a tuple with IP and port.
Fixes: 00a75e332f ("vici: Create default TCP socket on Windows in Python bindings")
Closesstrongswan/strongswan#1874
As long as any `child*` selector is received, only CHILD_SAs will be
terminated or rekeyed. Any passed `ike*` selectors will only be used to
filter the IKE_SAs when looking for matching CHILD_SAs. However, the
previous log messages seemed to indicate that IKE_SAs will also be
terminated/rekeyed.
References strongswan/strongswan#1655
Previously, the logger installed by the controller always announced
LEVEL_PRIVATE(4), which produced completely useless logging calls with
the common clients (vici/stroke) whose default log level is LEVEL_CTRL(1).
This can produce quite some overhead if there are e.g. a lot of concurrent
initiate() calls.
This should prevent a deadlock that could previously be caused when a
control-log event was raised. The deadlock looked something like this:
* Thread A holds the read lock on bus_t and raises the control-log event.
This requires acquiring the connection entry in write mode to queue the
outgoing message. If it is already held by another thread, this blocks
on a condvar.
* Thread B is registering the on_write() callback on the same connection's
stream due to a previous log message. Before this change, the code
acquired the entry in write mode as well, thus, blocking thread A. To
remove/add the stream, the mutex in watcher_t needs to be acquired.
* Thread C is in watcher_t's watch() and holds the mutex while logging on
level 2 or 3. The latter requires the read lock on bus_t, which should
usually be acquirable even if thread A holds it. Unless writers are
concurrently waiting on the lock and the implementation is blocking
new readers to prevent writer starvation.
* Thread D is removing a logger from the bus (e.g. after an initiate()
call) and is waiting to acquire the write lock on bus_t and is thereby
blocking thread C.
With this change, thread B should not block thread A anymore. So thread D
and thread C should eventually be able to proceed as well.
Thread A could be held up a bit if there is a thread already sending
messages for the same connection, but that should only cause a delay, no
deadlock, as on_write() and do_write() don't log (or lock) anything while
keeping the entry locked in write mode.
Closesstrongswan/strongswan#566
Also adds error reporting via VICI for issues with mediation settings.
Fixes: 229cdf6bc8 ("vici: Order auth rounds by optional `round` parameter instead of by position in the request")
References strongswan/strongswan#1569
Since 3dd5dc5011 ("Merge branch 'vici-python-timeout'"), any timeout
set directly on the socket is reset by `vici.Transport.receive()` unless
called by `vici.Session.listen()`. This prevents configuring a default
timeout directly on the socket.
However, setting a timeout directly on the socket also had drawbacks
since it can cause `vici.Transport.receive()` to raise a timeout error
while a subset of the data have been received, with no way to recover.
This commit merges both approaches by considering the timeout configured
on the socket by default (when no timeout is explicitly set) and
keeping the switch to blocking receive once the first byte has been
received. When the full expected data have been received, the timeout
configured on the socket is restored.
Co-authored-by: Tobias Brunner <tobias@strongswan.org>
Signed-off-by: Jean-Tiare Le Bigot <jt@yadutaf.fr>
Closesstrongswan/strongswan#1562
Tobias Brunner