[riot-notifications] [RIOT-OS/RIOT] pkg/tinydtls: DTLS process gets completly borked (#15842)

Aiman Ismail notifications at github.com
Sat Jan 23 07:34:52 CET 2021

I cannot reproduce the zero address but I can see the server not responding to the ClientHello. I enabled the debug log of tinydtls and got the following after the client sends the second request:

> Jan 23 06:53:01 DEBG dtls_handle_message: FOUND PEER
Jan 23 06:53:01 DEBG got packet 22 (67 bytes)
Jan 23 06:53:01 ALRT No security context for epoch: 0
Jan 23 06:53:01 INFO decrypt_verify() failed

The server actually received the ClientHello but it cannot continue the handshake because it thinks that the session is still valid. I found in the [TLS RFC][1] that closing a session in (D)TLS requires both sides to send a close_notify. So when you terminate the client before the server closed the session, the server is still waiting for the close_notify from the client back.

In tinydtls, it set the session to `DTLS_STATE_CLOSING` after one side sends a close_notify and after receiving a close_notify from the other side, changes it to `DTLS_STATE_CLOSED` and **only then** it frees the allocated storage for the peer.

So I think you need a way to cleanly end the session when the client just goes offline for whatever reason. tinydtls has a function `dtls_reset_peer`, which should free the peer. Maybe you should try using this in the DTLS session management module e.g. after sending a close_notify, if the client does not responds with another close_notify, assume its offline and resets the peer.

Hope that helps :)

[1]: https://tools.ietf.org/html/rfc5246#section-7.2.1

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20210122/da46aaa5/attachment.htm>

More information about the notifications mailing list