lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] PolarSSL and mbedTLS


From: Jan Menzel
Subject: Re: [lwip-users] PolarSSL and mbedTLS
Date: Thu, 2 Mar 2017 19:16:15 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1

Hi Noam!
        I'd suggest to enable the ssl layers memory pool debugging features.
64k is good, but I'm not entirely sure if thats enough. You need memory
for the certificate (if you have pre-shared in flash, its copied to ram
anyhow) and quite some memory for the initial key exchange and
certificate validation (depends on your configuration). On my system I
also noticed that there is quite some loss due to fragmentation. (My
system is based on a LPC1768 and I've dedicated 12k to the SSL layer. I
only support 1k MAX_CONTENT_LEN and only RSA, AES, DHE and PSK)

        Jan

On 01.03.2017 16:58, Noam Weissman wrote:
> Hi Jan,
> 
> Thanks for responding :-)
> 
> When I started this project I found (the hard way) that PolarSSL uses memory 
> allocations, and lots of it.
> As my system is complicated I cannot spare any of the 192Kb of the micro .
> 
> The micro has a second bank that is fast memory (CCM) so I used this one. I 
> have allotted all of the CCM 
> (64K) for micro heap. The SSL actually needs 2 x 16K + some extras so a 
> minimum of about 45-50K... 64 
> I think is sufficient ?
> 
> I am running a TCP (terminal like telnet) that sends and receives small 
> messages. In order not to waste 
> memory I have reduced the MSS size to its default and use more buffers. This 
> works fine with terminal
> HTTP and all... a compromise.
> 
> Any way here are my LwIP memory settings:
> 
> 
> /* ---------- Memory options ---------- */
> /* MEM_ALIGNMENT: should be set to the alignment of the CPU for which
>    lwIP is compiled. 4 byte alignment -> define MEM_ALIGNMENT to 4, 2
>    byte alignment -> define MEM_ALIGNMENT to 2. */
> #define MEM_ALIGNMENT           4
> 
> /* MEM_SIZE: the size of the heap memory. If the application will send
>    a lot of data that needs to be copied, this should be set high. */
> #define MEM_SIZE                (15 * 1024)
> 
> /* MEMP_NUM_PBUF: the number of memp struct pbufs.  
>   prevoiusly this was high as we understood that the pBuf buffers 
>   are allocated from the LwIP heap (MEM_SIZE). But after reducing
>   PBUF_POOL_SIZE to 6 the TCP stack started to get slow and hanged.
>   
>   We found out that the values were wrong and pBuf are allocated 
>   from the PBUF_POOL and its size is PBUF_POOL_SIZE * PBUF_POOL_BUFSIZE  
> */
> #define MEMP_NUM_PBUF           25
> 
> /* MEMP_NUM_UDP_PCB: the number of UDP protocol control blocks. One
>    per active UDP "connection". */
> #define MEMP_NUM_UDP_PCB        10
> 
> /* MEMP_NUM_TCP_PCB: the number of simulatenously active TCP
>    connections. */
> #define MEMP_NUM_TCP_PCB        20
> 
> /* MEMP_NUM_TCP_PCB_LISTEN: the number of listening TCP
>    connections. */
> #define MEMP_NUM_TCP_PCB_LISTEN 15
> 
> /* MEMP_NUM_SYS_TIMEOUT: the number of simulateously active
>    timeouts. */
> #define MEMP_NUM_SYS_TIMEOUT    15
> 
> 
> /* ---------- TCP options ---------- */
> #define LWIP_TCP                1
> #define TCP_TTL                 255
> 
> /* Controls if TCP should queue segments that arrive out of
>    order. Define to 0 if your device is low on memory. */
> #define TCP_QUEUE_OOSEQ         0
> 
> /* TCP Maximum segment size. */
> #define TCP_MSS                 536
> 
> /* TCP sender buffer space (bytes). */
> //
> // When TCP_SND_BUF was (4*TCP_MSS) we had problems with memory
> // alocation. After reducing it to (3*TCP_MSS) we stopped getting 
> // memory allocation errors. After more testing with memory allocation
> // I have reduced it to 2 * MSS and now it look OK with no memory alloocation
> // problems !!! 
> //
> #define TCP_SND_BUF             (2 * TCP_MSS)
> 
> /*  TCP_SND_QUEUELEN: TCP sender buffer space (pbufs). This must be at least
>   as much as (2 * TCP_SND_BUF/TCP_MSS) for things to work. */
> 
> #define TCP_SND_QUEUELEN        (6 * (TCP_SND_BUF)/(TCP_MSS))
>   
> /* TCP receive window. */
> #define TCP_WND                 (4 * TCP_MSS)
> 
> 
> /* MEMP_NUM_TCP_SEG: the number of simultaneously queued TCP
>    segments. */
> //#define MEMP_NUM_TCP_SEG        20
> #define MEMP_NUM_TCP_SEG        TCP_SND_QUEUELEN // 20  // This was previosly 
> 20 and cause a MEM_ERR it was changed 
>                                                  // to BE THE SAME SIZE AS 
> TCP_SND_QUEUELEN
> 
> /* ---------- Pbuf options ---------- */
> /* PBUF_POOL_SIZE: the number of buffers in the pbuf pool. */
> #define PBUF_POOL_SIZE          MEMP_NUM_PBUF
> 
> /* PBUF_POOL_BUFSIZE: the size of each pbuf in the pbuf pool. */
> #define PBUF_POOL_BUFSIZE       LWIP_MEM_ALIGN_SIZE(TCP_MSS + 40 + 
> PBUF_LINK_HLEN)
> 
> /* ---------- Netbuf options ---------- */
> /* MEMP_NUM_NETBUF: the number of struct netbufs.*/
> #define MEMP_NUM_NETBUF         6
> 
> /* MEMP_NUM_NETCONN: the number of struct netconns.*/
> #define MEMP_NUM_NETCONN        6
> 
> 
> As far as I understand the SSL will read a buffer decrypt it and return from 
> ssl_read with the decrypted data.
> 
> The SSL function ssl_read does not know in advance (I think) how many bytes 
> are there to decrypt. So if it
> Works for a small message it should work for a larger message that is 
> decrypted in chunks anyway.
> 
> Any suggestion for an easy to handle (for testing) WSS server in PHP or 
> similar ?
> 
> I think you are correct that it is a memory problem or some tweaking issue 
> but I am not sure what ?
> 
> Anymore hints will be welcomed :-) 
> 
> 
> BR,
> Noam.
> 
> 
> 
> -----Original Message-----
> From: lwip-users [mailto:address@hidden On Behalf Of Jan Menzel
> Sent: Wednesday, March 01, 2017 5:13 PM
> To: address@hidden
> Subject: Re: [lwip-users] PolarSSL and mbedTLS
> 
> Hi Noam!
>       I've designed a system with almost the same setup which works well 
> since a few years incl. firmware updates of a ~200kb.
>       Did you checked the memory consumption of the ip stack and the ssl max 
> content length setting? The default max content length setting is IIRC 16kb, 
> which means that data is hashed and encrypted in chunks of up to 16kb and can 
> only be verified and decrypted once the entire chunk has been received. The 
> firmware update on my system only works if the max content length is reduced. 
> With the default setting I faced memory issues on LPC1768 (which has just a 
> fraction of your F4xx).
>       I also had to fiddle around a little bit with errno in the interface 
> between mbedtls and lwip. One last advice: carefully check your stack usage. 
> mbedtls uses lots of function pointers which Keils static call graph analysis 
> can not see and does not warn about.
> 
>       Jan
> 
> On 01.03.2017 14:01, Noam Weissman wrote:
>> Hi,
>>
>>  
>>
>> I have a client, single task using the socket API using and also 
>> PolarSSL for SSL support.
>>
>>  
>>
>> The client is WebSocket client and all seems to work ok.
>>
>>  
>>
>> When I try to send small messages from the server to my client all is 
>> working ok but when I try to push a large
>>
>> message 6K and up my ssl_read function fails with a read error?.
>>
>>  
>>
>> The ssl_read is actually calling lwip_read internally.
>>
>>  
>>
>> For some reason the SSL code is trying to read a large buffer 8-16K 
>> bytes and the read function fails.
>>
>>  
>>
>> Normally when we read from a socket more than is available the return 
>> value should be the number
>>
>> of bytes actually read and not an error ?.
>>
>>  
>>
>> The processor is STM32F427 using CCM for heap and Keil IDE
>>
>>  
>>
>> My main project uses Lwip 1.41, FreeRTOS 8.0.1 and PolarSSL 1.0.0
>>
>>  
>>
>> I have created two almost identical projects to the one I use. The 
>> first
>> uses:
>>
>> Lwip 2.01, FreeRTOS 9.0
>>
>>  
>>
>> The second project is the same as the one with Lwip 2.01 but instead 
>> of PolaSSL I switched to mbedTLS 2.4.0
>>
>>  
>>
>> In none secure mode everything works as expected and have no problems 
>> getting a large message (600K)
>>
>> In secured mode I get a read fail on the first packet ??
>>
>>  
>>
>> Anyone has an idea what I am doing wrong or what setting are not correct ??
>>
>>  
>>
>> A second question for Simon or anyone that can assist. I tried to set 
>> LWIP_DEBUG to 1 and my total used RAM (compiler) dropped
>>
>> about 30K ?? Why is that ?... I understood that debug should take more 
>> RAM not Less ?
>>
>>  
>>
>> Thanks,
>>
>> Noam.
>>
>>  
>>
>> cid:image001.jpg@01D26A92.68494F10
>>
>>      
>>
>> Noam Weissman
>>
>> Software Engineer
>>
>> SILORA R&D
>>
>> p:
>>
>>      
>>
>> +972-4-9554915 m: +972-52-5786135
>>
>> w:
>>
>>      
>>
>> www.silrd.com <http://www.silrd.com/>  e: address@hidden 
>> <mailto:address@hidden>
>>
>> cid:image002.png@01D26A92.68494F10
>> <https://www.facebook.com/SiloraRD/>  
>> cid:image003.png@01D26A92.68494F10
>> <https://twitter.com/SiloraRD>  cid:image004.png@01D26A92.68494F10
>> <https://www.linkedin.com/company/silora-r&d>
>>
>>  
>>
>>  
>>
>>
>>
>> _______________________________________________
>> lwip-users mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]