NRF9160: Any way to persist DTLS Connection-ID (CID)/Session across e.g. socket closing/modem flight mode?

[HFled]

I'm currently evaluating DTLS-CID for our use cases.

As far as I understand, the point of CID is to have the connection-identifier be distinct from the port/ip tuple, so that the dlts connection can remain active/you don't need to do a new handshake when those change.

I'm baffled right now as to how to use this currently.

E.g. something I'd like to do is create a dtls-connection, send some data, and then turn off the modem. And then at a later point I'd like to turn the modem back on and send some new data, without having to perform a new handshake. But since I need to close the socket before turning of the modem (or the socket will return an error after turning the modem back on and I'd have to close/reopen it then), all state is discarded anyway and a new handshake needs to be performed.

Am I missing something (e.g. a way to explicitly persist dtls-state) or am I misinterpreting how this feature is supposed to be used? And if the later, I'd appreciate a quick explanation how you intend it to be used and in what situations I/the user sees benefit from it.

Regargs,

Henning

[Achim Kraus]

Hi Henning,

using PSM there is no need to "turn off" the modem. So you don't need to close the socket.

AFAIK, there is also a possibility to save (TLS_DTLS_CONN_SAVE) and load (TLS_DTLS_CONN_LOAD) the connection. So in cases, where the modem lose the network and closes the socket on its own, that may help. I didn't test that.

I'm using my own implementation (https://github.com/boaks/zephyr-coaps-client), where tinydtls is used and is outside of the socket and so more resilient against "TCP style implementations", which drops sockets, when the network is temporary lost. That also needs to close and open the UDP socket (that's caused by the modem), but the DTLS context is not affected.

[HFled]

I played around with CONN_LOAD/SAVE but without success. The documentation also still explicitly states that context is lost on socket close, so I suppose that's to be expected.

I'm aware that PSM would solve my issue, but I'm explicitly interested in the non-psm case. Moving the DTLS context out of the modem/into app-space seems to be the obvious/proper solution for that. Though I'll still need to investigate the Blog post linked by Charlie above.

PS: Just randomly want to say thanks for all the work and support you're doing around here and generally speaking in the DTLS/Coap realm. "So I stumbled across this post/answer/project" by Achim has become a bit of a running gag among me and my colleagues (in a positive way ofc. ;) ).

[Achim Kraus]

Your welcome.