Skip to content

Conversation

@rlubos
Copy link
Contributor

@rlubos rlubos commented Dec 17, 2025

Implement support for multiple client sessions per DTLS server socket. This includes some major refactoring of the DTLS server socket functionality, including splitting the TLS session context from the TLS socket context. DTLS server socket will allocate new session context for packets coming from unknown clients. TLS client/server and DTLS client functionality shouldn't be affected, as those scenarios only support a single session per socket.

Resolves #64954

Separate TLS session context from the TLS socket context so that a
single DTLS server socket can support multiple client sessions.
Other socket types will only have a single session per TLS socket.

Signed-off-by: Robert Lubos <[email protected]>
It has to be possible to initialize TLS sessions separately of the TLS
socket context.

Signed-off-by: Robert Lubos <[email protected]>
Split DTLS BIO RX functions for client and server case, given the
functionality will differ heavily. DTLS server needs to peek packet
before passing it to mbed TLS to allow to switch DTLS sessions in case
peer address doesn't match.

Signed-off-by: Robert Lubos <[email protected]>
Refactor RX side for DTLS server to allow session switching when a
datagram from a peer that does not match current session. The server
needs to loop over established sessions, and in case no session is
found allocate a new one.

Signed-off-by: Robert Lubos <[email protected]>
For TX, the DTLS server needs to check the peer address before passing
the packet to mbed TLS. In case the peer address doesn't match the
active session, it needs to switch sessions.

Signed-off-by: Robert Lubos <[email protected]>
In case of errors on an active session (in most cases peer closing the
session), the session should be freed. Note, that as mbed TLS needs some
session context to work with, the last session on a socket is not freed,
but only reset instead.

Signed-off-by: Robert Lubos <[email protected]>
In case a client address changes, but a session uses Connection ID
extension, the server should verify if the packet belongs to any of the
established sessions based on the CID value.

Therefore, before attempting to allocate a new session in such case,
loop over sessions and try to match the packet to one of the existing
sessions based on CID. In case of success, update the corresponding peer
address.

If no session is found based on CID, only then try to allocate a new
one.

Signed-off-by: Robert Lubos <[email protected]>
With support for multiple client sessions for DTLS server socket, the
session timeout can no longer rely on built-in mbed TLS timing out
mechanism, as this only works for the session that is currently active.
Background sessions would never time out if the client just went silent.
Therefore, allocate a per-session timestamp, that keeps track of the
last activity on the session. Then, whenever poll() or recv() is called
loop over all sessions to identify those that timed and should be
released.

Signed-off-by: Robert Lubos <[email protected]>
For options that return the handshake status, make sure they work in
multi-client DTLS server case, by returning the status for the session
that completed handshake most recently. For TLS and DTLS client cases
that should make no difference, as there should only be one session per
context.

Signed-off-by: Robert Lubos <[email protected]>
Add test cases verifying that DTLS server socket can handle multiple
clients.

Signed-off-by: Robert Lubos <[email protected]>
@zephyrbot zephyrbot added area: Networking area: Sockets Networking sockets area: Tests Issues related to a particular existing or missing test labels Dec 17, 2025
@sonarqubecloud
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: Networking area: Sockets Networking sockets area: Tests Issues related to a particular existing or missing test

Projects

None yet

Development

Successfully merging this pull request may close these issues.

DTLS server socket support multiple clients

3 participants