DTLS Fallback mechanism or faulty config?

Mbed TLS
1

Dear MbedTLS!

Description of the problem
Not really a problem, more of a question? I’m using mbedtls with OPTEE, by putting private key related functionality inside a TA to make it more secure. This is however unimportant, as the problem occurs in the rich environment, a basic linux system. So the problem isn’t related to OPTEE.

I modified the ssl_server example program by putting a few printfs in it as proof of concept code, so mbedtls remains unchanged, I only added code that doesn’t effect mbedtls in any way. After running this, and connecting to it with an example ssl_client1 program, I get the following debug messages after the handshake starts:

You must use mbedtls_ssl_set_timer_cb() for DTLS
mbedtls_ssl_fetch_input() returned -28928 (-0x7100)

I don’t even get past the client hello stage of the handshake. The problem is, I’m not using DTLS at all. Actually, I believe the transport merthod is specifically set to stream via:

mbedtls_ssl_config_defaults( &conf,
                MBEDTLS_SSL_IS_SERVER,
                MBEDTLS_SSL_TRANSPORT_STREAM,
                MBEDTLS_SSL_PRESET_DEFAULT )

Question
Based on me not changing any configuration in the latest mbedtls release, and not changing anything mbedtls related in the example server app, even setting the transport method to stream. What could be the reason It’s trying to use DTLS without me telling it to do so?

Could this be, because the server is running in a QEMU emulated environment and I’m using port forwarding to access the server from the host system, so the connection has a low bandwidth and mbedtls falls back to DTLS? It might be far fetched but I’m at a loss …

Any help would be appriciated :slight_smile: also, this is my first post so go easy on me. I’ll provide additional info if needed.

mbedtls version used
I just cloned the github repo a few hours ago, so my mbedtls is the latest (I think it’s 2.20.0 or so). There’s one catch, I messed up the versions and previously used mbedtls-2.7.9 as the base of my project, and I didn’t run into the timer problem with DTLS.

toolchain used
I used the aarch64 toolchain, the arm-gcc-8.3.0 and ld to make mbedtls, but I doubt It’s the root of the problem, as version 2.7.9 works like a charm.

2

Hi @mzombor
As mentioned in this anouncement, Mbed TLS is now maintained under open governance at TrustedFirmware.org.
I would suggest you post your question there, as it doesn’t seem your question is Pelion related.

In addition, as mentioned in this blog :

Until Mbed TLS 3.0 is released, only Long-Term Support (LTS) versions of Mbed TLS 2.x will be released. Feature releases will be targeting Mbed OS only.

This means that version 2.20.0 is not supported.

If you are calling mbedtls_ssl_config_defaults() with MBEDTLS_SSL_TRANSPORT_STREAM, then you shouldn’t have received this error.
Perhaps there is some memory overflow in your system, however this error is checking explicitely if the transport is equal to MBEDTLS_SSL_TRANSPORT_DATAGRAM, so a memory overflow assigning 1 is highly improbable.
Ar eyou sure you don’t have a later call to mbedtls_ssl_conf_transport(&conf, MBEDTLS_SSL_TRANSPORT_DATAGRAM ) ?
Regaqrds,
Mbed Support
Ron

3

Dear @roneld01

Thanks for the directions! I’m gonna post there as well in case someone runs into the same problem, I got lost in the mbed* forums a bit :slight_smile:

Also, I didn’t delete my post last night as I was really tired but I actually solved the hickup. It was indeed a version mismatch, I managed to include the header files of version 2.7.9 and not the latest release, now everything’s back in working order.

Thank you for taking your time for me!

Regards,
Máté

1 Like