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:
1. close notify from server after client hello 2. 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
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
On Mon, 26 Jan 2026 at 10:28, Milorad Podoaba via mbed-tls < mbed-tls@lists.trustedfirmware.org> wrote:
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.
(09) 414 0085 <%2809%29%20414%200085%20%20%20> milo@aap.co.nz www.aap.co.nz <//www.aap.co.nz> 1A Emirali Road, Silverdale, Auckland, New Zealand
[image: linkedin] https://www.linkedin.com/company/arrowhead-alarm-products-ltd-/
[image: instagram] https://instagram.com/aapltd?igshid=1356ehzmruf5r
-- mbed-tls mailing list -- mbed-tls@lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-leave@lists.trustedfirmware.org
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
MiloradPodoaba
Firmware System Engineer
Arrowhead Alarm Products Ltd.
(09) 414 0085 tel:%2809%29%20414%200085%20%20%20
milo@aap.co.nz mailto:milo@aap.co.nz
www.aap.co.nz <//www.aap.co.nz>
1A Emirali Road, Silverdale, Auckland, New Zealand
linkedin https://www.linkedin.com/company/arrowhead-alarm-products-ltd-/
instagram https://instagram.com/aapltd?igshid=1356ehzmruf5r
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
On Mon, 26 Jan 2026 at 10:28, Milorad Podoaba via mbed-tls mbed-tls@lists.trustedfirmware.org wrote:
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: 1. close notify from server after client hello 2. 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 -- MiloradPodoaba Firmware System Engineer Arrowhead Alarm Products Ltd. (09) 414 0085 <tel:%2809%29%20414%200085%20%20%20> milo@aap.co.nz <mailto:milo@aap.co.nz> www.aap.co.nz <//www.aap.co.nz> 1A Emirali Road, Silverdale, Auckland, New Zealand facebook <https://www.facebook.com/ArrowheadAlarmProductsLtd/?hc_ref=ARTrnwMZmLZimX6KHC1J2U2HWEdztNNES-m_Ncck0hUNiUiucg4NapNzAjkb9USxlTw&fref=nf&__xts__[0]=68.ARD73Z3zLqWRinEYq5B3pCmj6K7NTk5T0sHH46rthGKDavHtQLvLoIMW104lK2l12AVotJOMgF7c19VyewhJpKUe_Ta_YpnQH4iDh3wVCYCDLQ91t_6cX6sgP2ihPIf7B81suU5fIc8exObMKGhvh1mR1qPDnj6_vHK0L9caX00cbljhy8pKAMItcGMSu9-b-Rm6hgteHEHIWP-4h3ioM3xWC1oKC8xQcmE_jKSTfGs-pgac2jMz33XsyQgp-JQPFL2umeo6R7yg7nmUrQYwDabtIMDmygcQ6JZw5PgdRB-34OfT4AGyS_wTaDnMFd0nBC7aRpYyJ8mSOY2WNcArkFc&__tn__=kC-R> linkedin <https://www.linkedin.com/company/arrowhead-alarm-products-ltd-/> instagram <https://instagram.com/aapltd?igshid=1356ehzmruf5r> -- mbed-tls mailing list -- mbed-tls@lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-leave@lists.trustedfirmware.org
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? You can have a look at our knowledge base article about reducing memory usage: https://mbed-tls.readthedocs.io/en/latest/kb/how-to/reduce-polarssl-memory-a... Unfortunately it is somewhat outdate, in particular MBEDTLS_SSL_MAX_CONTENT_LEN has been replaced with MBEDTLS_SSL_OUT_CONTENT_LEN and MBEDTLS_SSL_IN_CONTENT_LEN.
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:
1. The SSL in/out buffers just discussed above are the main one. 2. 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. 3. 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
[cid:part1.ERCeLtqV.ZDiYWCQi@aap.co.nz] Milorad Podoaba
Firmware System Engineer
Arrowhead Alarm Products Ltd.
[cid:part2.7TKrZVqS.9BPiaDTT@aap.co.nz] (09) 414 0085 tel:%2809%29%20414%200085%20%20%20 [cid:part3.mTkpCOPv.FZHBj53x@aap.co.nz] milo@aap.co.nzmailto:milo@aap.co.nz [cid:part4.2OmiVYGw.3Vu4ftrz@aap.co.nz] www.aap.co.nz<//www.aap.co.nz> [cid:part5.4azr0MAq.b3Ly0Gut@aap.co.nz] 1A Emirali Road, Silverdale, Auckland, New Zealand
[linkedin]https://www.linkedin.com/company/arrowhead-alarm-products-ltd-/
[instagram]https://instagram.com/aapltd?igshid=1356ehzmruf5r
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
On Mon, 26 Jan 2026 at 10:28, Milorad Podoaba via mbed-tls <mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org> wrote: 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:
1. close notify from server after client hello 2. 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
-- [cid:part9.0jgU0qng.G00K6LPp@aap.co.nz] Milorad Podoaba
Firmware System Engineer
Arrowhead Alarm Products Ltd.
[cid:part10.emLhLkcz.zJLTzgJo@aap.co.nz] (09) 414 0085 tel:%2809%29%20414%200085%20%20%20 [cid:part11.pXot2pBz.00dDqyQ0@aap.co.nz] milo@aap.co.nzmailto:milo@aap.co.nz [cid:part12.SCJk8FlW.aTJ4OUEs@aap.co.nz] www.aap.co.nz<//www.aap.co.nz> [cid:part13.mRxuFbpl.faS2TAEq@aap.co.nz] 1A Emirali Road, Silverdale, Auckland, New Zealand
[facebook]https://www.facebook.com/ArrowheadAlarmProductsLtd/?hc_ref=ARTrnwMZmLZimX6KHC1J2U2HWEdztNNES-m_Ncck0hUNiUiucg4NapNzAjkb9USxlTw&fref=nf&__xts__[0]=68.ARD73Z3zLqWRinEYq5B3pCmj6K7NTk5T0sHH46rthGKDavHtQLvLoIMW104lK2l12AVotJOMgF7c19VyewhJpKUe_Ta_YpnQH4iDh3wVCYCDLQ91t_6cX6sgP2ihPIf7B81suU5fIc8exObMKGhvh1mR1qPDnj6_vHK0L9caX00cbljhy8pKAMItcGMSu9-b-Rm6hgteHEHIWP-4h3ioM3xWC1oKC8xQcmE_jKSTfGs-pgac2jMz33XsyQgp-JQPFL2umeo6R7yg7nmUrQYwDabtIMDmygcQ6JZw5PgdRB-34OfT4AGyS_wTaDnMFd0nBC7aRpYyJ8mSOY2WNcArkFc&__tn__=kC-R [linkedin]https://www.linkedin.com/company/arrowhead-alarm-products-ltd-/ [instagram]https://instagram.com/aapltd?igshid=1356ehzmruf5r -- mbed-tls mailing list -- mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-leave@lists.trustedfirmware.orgmailto:mbed-tls-leave@lists.trustedfirmware.org
mbed-tls@lists.trustedfirmware.org
-
Ben Taylor -
Manuel Pegourie-Gonnard -
Milorad Podoaba