#10937·mbedtls

Rare intermittent failure of "DTLS fragmenting: 3d …" test

Author: gilles-peskine-armCreated Aug 29, 2026Updated Aug 29, 2026
Labelsbugcomponent-tls

On the nightly test on development at 522e2e4651db0758dcc7f5da6737239ce45cab22 (a little after 4.2.0), the test case "DTLS fragmenting: 3d, MTU=116, gnutls client, DTLS 1.2" failed because the client timed out. Extract from the client log:

# DTLS fragmenting: 3d, MTU=116, gnutls client, DTLS 1.2
echo 'GET / HTTP/1.0' | /usr/local/gnutls-3.7.2/bin/gnutls-cli --x509cafile ../framework/data_files/test-ca_cat12.crt -p 22897 -u --insecure 127.0.0.1 --priority=NORMAL
|<1>| Discarded replayed handshake packet with sequence 0
…
|<1>| Discarded replayed handshake packet with sequence 2
*** Fatal error: The operation timed out
Processed 2 CA certificate(s).
Resolving '127.0.0.1:22897'...
Connecting to '127.0.0.1:22897'...
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - subject `CN=localhost,O=PolarSSL,C=NL', issuer `CN=PolarSSL Test Intermediate CA,O=PolarSSL,C=NL', serial 0x10, EC/ECDSA key 256 bits, signed using RSA-SHA256, activated `2023-05-17 07:10:37 UTC', expires `2033-05-17 07:10:37 UTC', pin-sha256="shCDObP7s3FdA8DLWAtbRBHexn4AEXt2ByJnqh3OYaE="
        Public Key ID:
                sha1:dd4af65f21c4982d7b0e3acc5421512f2375ebe2
                sha256:b2108339b3fbb3715d03c0cb580b5b4411dec67e00117b76072267aa1dce61a1
        Public Key PIN:
                pin-sha256:shCDObP7s3FdA8DLWAtbRBHexn4AEXt2ByJnqh3OYaE=

- Certificate[1] info:
 - subject `CN=PolarSSL Test Intermediate CA,O=PolarSSL,C=NL', issuer `CN=Polarssl Test EC CA,O=PolarSSL,C=NL', serial 0x0e, RSA key 4096 bits, signed using ECDSA-SHA256, activated `2023-05-17 07:10:37 UTC', expires `2033-05-17 07:10:37 UTC', pin-sha256="6hZVoGEer30Yy5D6ai8QmFWvucvMy2a4DWTEcFvzOd8="
- Status: The certificate is NOT trusted. The name in the certificate does not match the expected. 
*** PKI verification of server certificate failed...
EXIT: 1

Full logs:

all_u16-full_without_tls13-o-cli-194.log all_u16-full_without_tls13-o-srv-194.log all_u16-full_without_tls13-o-pxy-194.log

This has happened previously, at 03334868372d9ab34d0b25dfa0a316c5b79d556b.

I am filing a separate issue from https://github.com/Mbed-TLS/mbedtls/issues/8471 because there seem to be two different causes. There's a class of failures that we haven't seen on 4.0 and above affecting full_without_ecdhe_ecdsa and variants, which is the focus of 8471. This issue here is rarer, and has been observed after 4.0.