Repository navigation
esp32: mbedtls can't allocate in/out buffers on IDF4.x #5303
Description
Activity
I didn't know that it's possible to configure the in/out SSL content lengths separately in mbedtls. IMO it'd be good to enable this feature on all ports that use mbedtls, because otherwise SSL connections cost a lot of RAM (ie 16k for incoming, to support all servers, but 4k or so on outgoing data).
OK, I will send a PR to do that.
However, looking at the heap summary in 3.3 (below) is quite interesting and clearly shows why this problem exists now -- there used to be a 154504 byte region in 3.3 which is now split into 79760 + 16648 + 15072 in 4.x.
Heap summary for capabilities 0x00001800: At 0x3ffae6e0 len 6432 free 0 allocated 6276 min_free 0 largest_free_block 0 alloc_blocks 31 free_blocks 0 total_blocks 31 At 0x3ffba478 len 154504 free 0 allocated 154120 min_free 0 largest_free_block 0 alloc_blocks 88 free_blocks 0 total_blocks 88 At 0x3ffe0440 len 15072 free 0 allocated 14968 min_free 0 largest_free_block 0 alloc_blocks 18 free_blocks 0 total_blocks 18 At 0x3ffe4350 len 113840 free 94508 allocated 19124 min_free 87416 largest_free_block 94448 alloc_blocks 40 free_blocks 4 total_blocks 44 Totals: free 94508 allocated 194488 min_free 87416 largest_free_block 94448The 3.3 MicroPython heap is 115008 bytes which came from that now-split 154504 region. On 4.x the MicroPython heap (now 107136 bytes) comes from that 113840 byte region instead.
A consequence of this fragmentation is that even though setting
CONFIG_MBEDTLS_ASYMMETRIC_CONTENT_LENfixes the reported issue, it will fail to allocate a second concurrent ssl socket. Whereas in 3.3 it could support two concurrent sockets (or 4 withCONFIG_MBEDTLS_ASYMMETRIC_CONTENT_LEN).- added 2 commits that reference this issue
on Nov 7, 2019 - added a commit that references this issue
on Nov 11, 2019 - added a commit that references this issue
on Dec 20, 2019
Raised at https://forum.micropython.org/viewtopic.php?f=18&t=7208
At the point that
modussl_mbedtls.ccallsmbedtls_ssl_setup, the ESP32 heap looks like this:mbedtls_ssl_setuptries to allocate two 16717 buffers -- the first (ssl->in_buf) succeeds (likely from the fourth block) then the second (ssl->out_buf) fails.Easy workaround would be to enable
CONFIG_MBEDTLS_ASYMMETRIC_CONTENT_LEN(which would drop the output buffer to 4kiB).I'll grab the heap info for a 3.3 build. I'm guessing that by chance the fragmentation across the blocks just ends up being slightly more favourable to two >16kiB allocations.