DTLS session resumption

[tomekmalek]

Hello,

I am trying to use DTLS session resumption feature with Anjay C demo client. If I understand well AVS_COMMONS_NET_WITH_TLS_SESSION_PERSISTENCE and AVS_NET_SOCKET_OPT_SESSION_RESUMED are responsible for that.

My test environment:

• Ubuntu 20.04 @x86_64,
• MbedTLS 2.28.1,
• Anjay demo client 3.1.2 (LwM2M 1.1, PSK),
• Leshan demo server (leshan.eclipseprojects.io),
• my test scenario:
  • client connects to a server performing full DTLS handshake and successfully sends a registration,
  • I block traffic to Leshan server on my router,
  • when client is starting to reconnect DTLS session, I unblock traffic to Leshan server on my router,
  • client reconnects to server performing full DTLS handshake and successfully sends a registration.

In fact, in the last step of my scenario client performing FULL handshake during reconnection, but I expected ABBREVIATED handshake (see attached screenshot). For me, it means that resumption of DTLS session feature does not work. Maybe I am doing something wrong... What do I need to do to have resumption of DTLS session? Thanks for help.

Best regards Tomasz

[kFYatek]

Hi Tomasz,

In general, your scenario should "just work", no special configuration should be necessary.

Can you send the actual PCAP file instead of just the screenshot? The lack of proper DTLS session resumption may be a problem on either the client or the server side. My initial suspicion is that the server may not recognize the session ID that is supposedly sent as part of the Client Hello during the reconnection - however I cannot verify this hypothesis based on your screenshot alone.

[tomekmalek]

Hi @kFYatek,

Thank you for your answer. Below I am attaching pcap file and log from my console. For your information, I also tested DTLS session resumption with LeshanDemoClient and the same LeshanDemoServer and it seems to be OK.

Anjay2LeshanDemoServer.zip

Best regards Tomasz

[kFYatek]

Hi @tomekmalek,

We have looked at your PCAP and indeed the client is not sending the session ID, so the problem is on the client side.

I have examined our code once again, and it seems that my previous answer was wrong. In your case (communication with the server is blocked on the router), I think Anjay is attempting to send a Register message (which also causes a DTLS handshake attempt) and fails. When the library determines this failure, the DTLS session cache is cleared, so the resumption will not be attempted.

You can test the DTLS session resumption by, instead of blocking the communication on the router, putting the Anjay library into offline mode and back (see anjay_transport_enter_offline() / anjay_transport_exit_offline() - in the command-line demo client, you can use enter-offline and exit-offline commands). The intended flow is that the Anjay library is expected to be notified when e.g. network link is lost, through these function calls. In case of actual communication errors, though, the DTLS session will get invalidated to effectively reset the state and maximize the chance of a successful connection.

I hope that this explanation makes sense to you.

[tomekmalek]

Hi @kFYatek,

Thank you for your explanation. You have a great software :+1: It seems to be OK (see screenshot). I am performing additional tests on my side and after that I will close this issue. Thank you for your help.

best regards Tomasz