mbedtls_ssl_write returns: error: [write():207]: (0XFFFFFFB2) UNKNOWN ERROR CODE (004E) #3954
Comments
|
I traced down the problem to be happning somewhere in LWIP function lwip_sendto: I have the feeling mbedtls DTLS streaming causes some kind of memory leak within LWIP as once the error occured, the esp32 wifi becomes very unstable. |
|
Another step further, debugging lwip shows me where the mem alloc fails
|
1 similar comment
|
Another step further, debugging lwip shows me where the mem alloc fails
|
|
Even with LWIP_STATS enable an pbub debug enabled, nothing which explains the ERR_MEM:
|
|
It seems to fail at a simple malloc call (traced back to mem_malloc), |
|
After weeks of getting mad because of this issue, I digged deep down into heap, lwip debugging and so on - nothing really was helping and showing that there is any memory shortage. However today I most likely found the root cause of the issue. So I have a Class that does the DTLS UDP Streaming which uses HTTPClient from arduino-esp32, and I was using new/delete to create HTTPClient objects dynamically after the ERR_MEM occurred. I remembered that I had trouble (strange exceptions) when deleting dynamic HTTPClient objects before in my OTA Updatecode. So as a workaround, I made the HTTPClient Object static which fixed the problem at that time. Now I applied the same to my Class that does the DTLS Streaming, I made the HTTPClient object static at the top of the Class code like this: And it appears to have fixed the problem mostly - I am running DTLS Streaming now since about 60 minutes without any ERR_MEM till yet. So I think HTTPClient is messing something badly up in the destructor, perhaps heap corruption? All the samples I find are not using new/delete but either static HTTPClient objects or on Stack. |
|
Thanks for the report, and i'm happy to hear that you've managed to work around the problem. If the problem does turn out to originate from mbedtls after all, do please come back to us. |
|
@bensze01 thats correct, the problem does not come from mbedtls, the original out of memory error was also happening inside LWIP and not mbedtls. But I already created this issue when I traced this down. https://github.com/espressif/arduino-esp32 builds on https://github.com/espressif/esp-idf/ and is used on esp32 IOT based boards. I hope this helps other facing the same problem. |
|
I'm closing this issue since it isn't a problem in Mbed TLS. |
|
Hello, Platform : STM32Cube |
|
@anjalir14 Posting on a closed issue is not a good way to ask for support. However, I happened to still be notified of messages on this issue, so here's my answer. -0x6d is not an mbedtls error code, so it must be an error code coming from the I/O layer (probably the In the future, for support requests, please use the mailing list. |
|
Firstly, I'm sorry and thank you for your help. I will try to debug my code again and if I came up with any error then I will mail you. |
|
Hi, I'm not able to send a message on the mailing list that you have provided me. I'm having a few errors can you pls help me out over here only? Thank you |
I am using mbedtls in a typical esp32 devkit with ESP-IDF release 3.3 with arduino-esp32 master branch.
I have more than enough memory free:
FreeMem ~ 140KB
MaxFreeHeap: 180KB
I have a sketch that receives about 60 UDP packages per seconds, with a data size of up to 1024 bytes per packet.
At the same time its streaming DTLS data (UDP) with about 50 packets per second with about 70 bytes erach packet.
At a random point mbedtls_ssl_write returns an error while sending:
error: [write():207]: (0XFFFFFFB2) UNKNOWN ERROR CODE (004E)
I then tear down the connection and reestablish DTLS Streaming. However from this point Network is unstable.
Also incoming UDP packages start to stutter and fill up the internal queue. When I stop UDP streaming to the device, I can see that it still is processing UDP packages for 5-15 seconds.
I digged a little deeper and I found out that the lower socket error code is 12 (ENOMEM ) happening in write call of lwip.
https://github.com/ARMmbed/mbedtls/blob/7f007f70e06e45ffcb70cee75c5e71b3316a3316/library/net_sockets.c#L628
I have played with larger buffers here and there but nothing seems to be fixing this problem.
And I am only experiencing it once DTLS streaming is active,
The text was updated successfully, but these errors were encountered: