Hi,
> I am not sure how much memory to assign?
I don't think there's a simple answer to that. I think the best you can do is measure how much memory is consumed in your workflow, and add a margin. When doing measurements, you should keep in mind that DTLS handshakes may consume more memory when happening over an unreliable transport, as it then needs to cache out-of-order messages, so you might want to use something like our programs/test/udp_proxy to simulate an unreliable link for you measurements. Also, the size of the messages exchanged (and potentially cached) depends on the size of the certificate chain, so you'll want to do you measurements with a configuration as close as possible to the final one.
> > Current use: 33 blocks / 2508 bytes, max: 99 blocks / 5392 bytes (total 8560 bytes), alloc / free: 8803 / 8771
> What is blocks here and how many bytes per block?
> My understanding is that - out of 99 blocks, 33 blocks are used. Is it right?
In this context, a block just means an area of memory that is or was allocated. So for example if you do `malloc(128); malloc(1024);` you'll have two blocks used, the first being
128 bytes (plus overhead) and the second 1024 bytes (plus overhead). There is no fixed number or size of blocks in the allocator, so here the "max" means the peak of memory consumption - at that time, 5392 bytes had been allocated, over 99 blocks. You'll notice our allocator has a pretty large overhead: when adding administrative data used by the allocator, the peak memory consumption was actually 8560 bytes, out of which only 5392 were actually available to the application.
> Does the memory fragmentation and de-fragmentation is handled inside mbedTLS itself?
No, the provided allocator is very basic and doesn't protect against memory fragmentation.
> And also after every handshake, does it release the used memory buffer for the connection?
Once the handshake is complete, all the RAM that was allocated just for the handshake is freed, and the only buffers that are kept are those that are still necessary for the rest of the connection.
Hope that helps!
Best regards,
Manuel.
Hi,
SIGPIPE is handled with a signal( SIGPIPE, SIG_IGN ) in
mbedtls_net_connect. While the examples in programs/ssl/ssl_client1.c or
programs/ssl/ssl_client2.c are calling mbedtls_net_connect,
programs/ssl/mini_client.c is not, and therefore not changing the default
behavior of SIGPIPE.
Our client is based on mini_client.c. What would the best way to handle
SIGPIPE? Would it be worth it to add signal( SIGPIPE, SIG_IGN ) to the
mini_client.c example for future reference? maybe even make net_prepare()
visible from outside so a mini client like application can use it?
Thanks!
I am directing the issue - https://github.com/ARMmbed/mbedtls/issues/3146
The content of the issue is - Hello,
Currently I am using mbed tls 2.16.3 and I am using it on STM32L4xx
platform.
Before I was using dynamic memory allocation (heap), now planning to shift
to static memory allocation.
I am using x509 ecc based certificate.
I am using DTLS handshake.
I am also using "mbedtls_memory_buffer_alloc_status" to print the status of
static buffer.
The queries are -
1. I am not sure how much memory to assign?
2. I am not able to understand the message -
*Current use: 33 blocks / 2508 bytes, max: 99 blocks / 5392 bytes (total
8560 bytes), alloc / free: 8803 / 8771*
What is blocks here and how many bytes per block?
My understanding is that - out of 99 blocks, 33 blocks are used. Is it
right?
1. Does the memory fragmentation and de-fragmentation is handled inside
mbedTLS itself? And also after every handshake, does it release the used
memory buffer for the connection?
I need the values correct to make sure not to get the memory allocation
failure
Please help me in these queries.