lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] altcp_tls_mbedtls


From: Simon Goldschmidt
Subject: Re: [lwip-users] altcp_tls_mbedtls
Date: Fri, 22 Feb 2019 09:43:14 +0100

Giuseppe Modugno wrote:
> I'm trying to integrate lwip and mbedTLS on a project running on LPC1769 
> MCU from NXP. This MCU features 64kB SRAM in two separate banks of 32kB.

If it works at all, it will certainly get *very* hard. Aside from the
input buffer, we saw really many small allocations (especially at
connection startup time) that summed up to some amount. I can't remember
exactly how the numbers were, but we're running it with more than 64 kB.

But then again, we need to support more than 1 connection to do being a
https server...

> As you can understand, I'm fighting putting all together with so small 
> SRAM. I'm not sure mbedTLS+lwip could really work in 64kB. I'm 
> interested in creating only one TLS connection with a MQTT server 
> (Amazon IoT or similar service). I'd like to know some experience about 
> a similar application in similar hw platform.
> 
> The first thing I made to reduce RAM requirements was decreasing 
> MBEDTLS_SSL_OUT_CONTENT_LEN from 16384 to 2048 (I understood output 
> buffer is under my control, so I can reduce it without letting informed 
> the server about this, differently from IN_CONTENT_LEN that must be at 
> least 16384).
> 
> My mbedTLS config.h:
> 
> #define MBEDTLS_SSL_IN_CONTENT_LEN              16384
> #define MBEDTLS_SSL_OUT_CONTENT_LEN             2048
> //#define MBEDTLS_SSL_MAX_CONTENT_LEN
> 
> In mbedtls/ssl.h appears:
> 
> #if !defined(MBEDTLS_SSL_MAX_CONTENT_LEN)
> #define MBEDTLS_SSL_MAX_CONTENT_LEN         16384   /**< Size of the 
> input / output buffer */
> #endif
> 
> So MBEDTLS_SSL_MAX_CONTENT_LEN is defined as 16384. Anyway it seems this 
> symbol is never used in mbedTLS code (it is useful only to define IN and 
> OUT content len when they aren't defined).
> 
> In altcp_tls_create_config() appears:
> 
>    if (TCP_WND < MBEDTLS_SSL_MAX_CONTENT_LEN) {
>      LWIP_DEBUGF(ALTCP_MBEDTLS_DEBUG|LWIP_DBG_LEVEL_SERIOUS,
>        ("altcp_tls: TCP_WND is smaller than the RX decryption buffer, 
> connection RX might stall!\n"));
>    }
> 
> Is this warning correct? I think TCP_WND should be compared with 
> MBEDTLS_SSL_IN_CONTENT_LEN or MBEDTLS_SSL_OUT_CONTENT_LEN or the maximum 
> of them (of course, I hope to compare it with OUT buffer only, because 
> it is smaller).

I think you're right: this should compare to the IN buffer. No that it
would help you here... :-)

> Another question, more TLS related. I know some servers don't implement 
> MFL (Maximum Fragment Length) extension in order to reduce input buffer 
> size too. Do you know of some way to understand if the server really 
> implement this extension? I'm interested in IoT services from Amazon, 
> Google, Microsoft or similar. It seems they don't explicit this feature, 
> so I have to check in other ways.

I don't think I can help you here.

Regards,
Simon



reply via email to

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