Hi Milo,
At this stage, I only want to reduce the size of the buffer for the alternative memory alloc.
Do you know a way to do it?
By default each SSL connection uses two heap buffers of size 16KB each, as that's the size mandated by the standard. If you know you'll only send records of at most 2KB for example, then you can reduce
MBEDTLS_SSL_OUT_CONTENT_LEN to 2048 in mbedtls_config.h. If in addition you also know that your peer will never send larger records, you can also reduce
MBEDTLS_SSL_IN_CONTENT_LEN in your config. Note the reducing the IN buffer can only be done if you control or otherwise know the behaviour of all peers you'll be connecting to. Note that even if you ever send very small chunks of application data
with `mbedtls_ssl_write()` you might still need to use a larger value in order to allow for the larger messages in the handshake (the Certificate message tends to be the largest).
In addition to what's mentioned in the knowledge base article, you can also look into `MBEDTLS_SSL_VARIABLE_BUFFER_LENGTH` to reduce the size of your SSL buffers - contrary to the options above, where sizes are determined statically at compile time, it might
reduce the size dynamically based on what the peer supports (but you have to use `mbedtls_ssl_conf_max_frag_len()` as well for it to have any effect).
Taking a step back, we can identify three main areas of heap usage in an SSL connection:
-
The SSL in/out buffers just discussed above are the main one.
-
Parsed X.509 certificates as discussed already: basically the more trusted roots you load, the more heap you'll consume, and same with the length of the chains (from trusted root to end-entity cert via intermediate
CAs), but that's something you may or may not control.
-
Asymmetric crypto (RSA, ECC). Here there are a few trade-offs between performance and heap usage, mentioned (or linked to) in the article. You can try those out but don't forget to measure the impact on performance
too and confirm if it is acceptable to you.
Hope this helps,
Manuel.
From: Milorad Podoaba via mbed-tls <mbed-tls@lists.trustedfirmware.org>
Sent: 26 January 2026 21:54
To: Ben Taylor <ben.taylor@linaro.org>
Cc: mbed-tls@lists.trustedfirmware.org <mbed-tls@lists.trustedfirmware.org>
Subject: [mbed-tls] Re: Some problems regarding mbed TLS
Hi Ben,
Not sure how much code you want me to share. You need to be more specific.
There might be a memory problem in our application, it just hard to tell and the mbed TLS seems not able to recover.
At this stage, I only want to reduce the size of the buffer for the alternative memory alloc.
Do you know a way to do it?
Thank you and regards,
Milo
 |
Milorad Podoaba
Firmware System Engineer
Arrowhead Alarm Products Ltd.
|
|
|
|
|
|
|
|
|
|
On 27/01/2026 12:19 am, Ben Taylor wrote:
Hi Milo,
Thanks for reporting this issue. Is there any chance you could share some example code that can reproduce the error, so we can investigate it further?
Many thanks
Ben
Hello,
Our devices are connecting to AWS IoT Core.
Recently we had few customers with poor connection complaining that the device didn't reconnect.
We are using ARM Keil MDK 8.1.0 + mbed TLS 3.6.4.
On Wireshark logs we have identified 2 errors:
- close notify from server after client hello
- bad certificate or unknown CA from client after server hello
The device was stuck on one of these errors and only a reboot would fix it.
I think these 2 errors are not related.
On detail analysis for the first error, we saw that the cipher suites list was missing and that was the reason for close notify from server.
Looking at the TLS code saw that the list is being created only one time after reboot.
So in ssl_ciphersuites.c just commented out supported_init = 1 and now seems to be good.
I do not know the reason why the list was lost during runtime.
For the second error, we were able to reproduce the problem quite consistently.
Some logs at IoT client code showed that somehow the TLS lost the ability to parse properly the server certificates.
I believe that this was some memory allocation problem, so I've configured the mbed TLS to get allocation from a separate buffer and that seems to fix the problem.
This buffer has to be quite large, 56k size. Any smaller size would return memory allocation failure.
Any reason why it has to be so big?
Just want to know if someone had before these issues and if I can lower the buffer.
Let me know if you need extra details about the problems.
Thank you and regards,
Milo
--
 |
Milorad Podoaba
Firmware System Engineer
Arrowhead Alarm Products Ltd.
|
|
|
|
|
|
|
|
|
|
--
mbed-tls mailing list --
mbed-tls@lists.trustedfirmware.org
To unsubscribe send an email to
mbed-tls-leave@lists.trustedfirmware.org