Server ignores handshake after queueing application data from client.

[gordonklaus]

Your environment.

• Server: pion/dtls v2.0.0
• Client: nRF9160 (Mbed TLS)

What did you do?

• A client successfully handshakes with a server and sends application data.
• The server goes down, without notifying the client, then starts back up.
• The client continues to send application data. The server log says:

dtls DEBUG: 14:39:43.547692 conn.go:643: received packet of next epoch, queuing packet
dtls TRACE: 14:39:43.547699 handshaker.go:146: [handshake:server] Flight 0: Preparing
dtls TRACE: 14:39:43.547756 handshaker.go:146: [handshake:server] Flight 0: Sending
dtls TRACE: 14:39:43.547768 handshaker.go:146: [handshake:server] Flight 0: Waiting
dtls TRACE: 14:39:44.551177 handshaker.go:146: [handshake:server] Flight 0: Sending
dtls TRACE: 14:39:44.551224 handshaker.go:146: [handshake:server] Flight 0: Waiting
...

• After not receiving a response for some time (application layer), the client decides to restart and initiates a new connection with the server.

What did you expect?

A successful second handshake.

What happened?

The client is completely ignored. There is nothing more in the server logs.

Thoughts

I can work around the issue by blocking the application data that the client sends after the server restart. It is this application data (which the server queues) that seems to interfere with the second handshake.

However, the client's second connection is from a different source port, with which the server has no prior association. Application data from a one source should not interfere with a handshake from another.