Hi, This is somewhat related to RT #1709
In the case where one record within the flight is lost, the DTLS state machine will continue to move forward without detecting it. This is observed when the MTU is low and the cert was fragmented into multiple records. Let's say one fragment of the client's cert is lost, when the server receives the subsequent ClientKeyExchange, CertificateVerifym ChangeCipherSpec and Finish, it will happily compute the checksum, complains and terminate the connection. The right approach would be to wait for the peer to retransmit and make sure all fragments had been reassmbled before computing checksum. I understand that much of the DTLS code was borrowed from TLS where there is no out-of-order or missing packets... To reproduce, simply add a random packet dropper between the socket and DTLS. Thanks, Alex.Hi,
This is somewhat related to RT #1709
In the case where one record within the flight is lost, the DTLS state machine will
continue to move forward without detecting it.
This is observed when the MTU is low and the cert was fragmented into multiple records.
Let's say one fragment of the client's cert is lost, when the server receives the subsequent ClientKeyExchange, CertificateVerifym ChangeCipherSpec and Finish, it will happily compute the checksum, complains and terminate the connection.
The right approach would be to wait for the peer to retransmit and make sure all fragments had been reassmbled before computing checksum.
I understand that much of the DTLS code was borrowed from TLS where there is no out-of-order or missing packets...
To reproduce, simply add a random packet dropper between the socket and DTLS.
Thanks,
Alex.
