I have noticed that when running ‘mbed-client-linux-example’ on my Ubuntu 14.04 machine to talk to the mbed Device Connector, if I delay the sending of the client ‘Certificate’ message in the DTLS handshake by a few seconds, the flight of messages that include ‘Server Hello done’ is retransmitted by the server. I think that is fine according to the DTLS spec. The handshake eventually completes, but after some time (usually within the next minute when /Test/0/D reaches 5), error messages show up in the output console:
Registered
Incrementing Resource Value Resource Value /Test/0/D : 1 Sending update register
registration updated Incrementing Resource Value Resource Value /Test/0/D : 2 Incrementing Resource Value Resource Value /Test/0/D : 3 Sending update register
registration updated Incrementing Resource Value Resource Value /Test/0/D : 4 Incrementing Resource Value Resource Value /Test/0/D : 5
If the handshake completes (and by that I mean if both parties see the handshake as completed, which is the case for example if at least one “application data” message is exchanged in both directions), then it seems unlikely to me that this is a bug in mbed TLS.
If the handshake doesn’t complete (ie if at least one of the parties doesn’t think it’s complete), then the most likely explanation is that the timeout values should be adjusted using mbedtls_ssl_conf_handshake_timeout() on both sides).
Of course it could also be a bug in mbed TLS, but wih the currently available data it’s hard to say.
Thanks Manuel. The handshake does go to completion, and as you saw from
the trace the registration update messages was successfully sent the
first time. However, the error is consistently reproducible when running
on a Linux box if I simply put a breakpoint on the function
ssl_write_client_key_exchange(). Resuming the code execution a few seconds after it
reaches the breakpoint results in the error shown. Do you think you can
try this and see if you can reproduce it?
