Very slow creation of TLS connection with the MQTT Agent code base

Partners & Sponsors AWS
1

When I try to establish a TLS connection from my HW with AWS Core IOT using the MQTT agent code base I’m facing a very long (~15-20 sec) period of connection establishment phase that ended successfully.
When I do it from VS with the same credentials it immediately connected, it is also work very fast when I used older version (202002) with the same HW and the same credentials.
Any idea where to look for the root cause of that?

2

To clarify, are you referring to this code? GitHub - FreeRTOS/coreMQTT-Agent-Demos: Demonstrates use of coreMQTT-Agent for simple MQTT connection sharing among different threads of execution.

The project in the repo above is visual studio, so if that is the code base you are using then the implication if you are not using visual studio is that you have the agent code running on different hardware. If that is the case, which hardware? TLS negotiation has a lot of math which may run slowly if the hardware is less capable, although 20 seconds seems extreme.

3

Yes, this is the code I’m referring to.

Indeed, as you say, the project in the repo is a VS only project. And if I use it out of the box with my credentials it is connected to AWS Core endpoint immediately.

I ported this project to my target board (ST Nucleo H743), with this board and a code that is based on 202002 I can connect to the core endpoint with the same credentials in seconds.

When I run the MQTT_Agent ported code on this board I can see that the board get IP address from the DHCP and then it takes about 20 seconds more to establish the TLS connection with the endpoint, from here on everything work fine.

I attach a log of this session (including TlsTransport debug level)
mbedTLS_Connection_Log.zip (6.9 KB)

4

Looking at the logs, it seems that most of the time is spent in the mbedTLS handshake. Since you have a working project, would you please compare the contents of mbedtls_config.h and FreeRTOSIPConfig.h. Also, what does the output look like in the successful/fast scenario?

Thanks.

5

For anyone else who stumbles upon a similar issue, the root cause was that one project was configuring the core to run at 64 MHz while the other one was configuring it to run at 400 MHz.

1 Like