#25 sequence numbers during handshake

[Alfredo Quesada Sánchez]

After having enabled debug, I've seen how many "client hello" packets must be sent from a client when it comes to connect to a server.

I've tried to connect the test dtls-client and dtls-server to each other and the process simply gets frozen:
- 1st try. The "client hello" is sent with no cookie, and the server answers with a "hello verify request".
- 2nd try. The "client hello" has a cookie, which doesn't match the one is calculated by the server and it sends back another "hello verify request". In this case the sequence number sent by the client was 1 and the sequence number received in the response (another "hello verify request") is 0. As a result, this second response is discarded.

For some reason, in too many cases there are issues related to the sequence number. Am I right? (btw, I'm using "tinydtls-5.0-release-BSD", which seems to be version 0.5.2 according to the file "doc/Makefile", but doesn't match any version number I can find on this web.. I don't know where the person who gave it to me got this version).

[Olaf Bergmann]

You are always welcome to open issues related to the tinydtls code hosted here. Now, you got some code from somebody somewhere in the Internet that may or may not be derived from the original tinydtls sources (I do not know what "version 5.0 release-BSD" or "version 0.5.2" is supposed to be. tinydtls never had anything like this as you can easily see in the release notes.)

To proceed from here, you should go and identify the source of your library and file an issue in its corresponding bug tracker.

[Alfredo Quesada Sánchez]

Ok, I updated to 0.8.2, and have noticed this packet exchange:
CLIENT <-> SERVER

client hello (no cookie) ->
hello verify request <-
client hello (cookie invalid) ->
hello verify request <-
client hello (cookie ok)
server hello <-
certificate <-
server key exchange <-
certificate request <-
server hello done <-
client hello (small message number) -> (maybe timeout at client?)
certificate ->
client key exchange ->
certificate verify ->
finished ->
finished <-
certificate (wrong epoch) ->
client key exchange (wrong epoch) ->
certificate verify (wrong epoch) ->
certificate (wrong epoch) ->
.. (more packets in wrong epoch)

application data ->

Once application has been exchanged the handshake seems to be completely finished and no extra packets are sent, other than the expected.

In this case the client is Californium Scandium and the server is tinydtls in a PIC32 uC. Apparently it's a problem from Scandium's side, not ending the handshake after having received the "finished" response, so I agree with the "Won't fix" :)

Regards