[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
- [lwip-users] altcp_tls_mbedtls, Giuseppe Modugno, 2019/02/22
- Re: [lwip-users] altcp_tls_mbedtls,
Simon Goldschmidt <=
- Re: [lwip-users] altcp_tls_mbedtls, Giuseppe Modugno, 2019/02/22
- Re: [lwip-users] altcp_tls_mbedtls, address@hidden, 2019/02/25
- Re: [lwip-users] altcp_tls_mbedtls, Giuseppe Modugno, 2019/02/26
- Re: [lwip-users] altcp_tls_mbedtls, Simon Goldschmidt, 2019/02/26
- Re: [lwip-users] altcp_tls_mbedtls, Giuseppe Modugno, 2019/02/26
- Re: [lwip-users] altcp_tls_mbedtls, Simon Goldschmidt, 2019/02/26
Re: [lwip-users] altcp_tls_mbedtls, Andy Pont, 2019/02/22