Re: [lwip-users] altcp_tls_mbedtls

[Giuseppe Modugno]

Il 22/02/2019 09:43, Simon Goldschmidt ha scritto:
> 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.

Unfortunately we already have a board with LPC1769 and we'd like to add 
TLS support to it.

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

In my case, the device is a client so it needs to create a single 
persistent connection to a MQTTs 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... :-)

I'm not an expert here, so my question could be very stupid. TCP_WND is 
the TCP window that is used to avoid continuous ack for small data. The 
transmitter sends data filling the window and then waits for the ack.

So the *transmitter* should have a capable buffer of at least TCP_WND 
per connection. So I imagine the TCP_WND should be compared with the 
*output* buffer (in my case 2kB). Why do you say TCP_WND should be 
compared with *input* buffer? Is it related to the possibility that TCP 
segments could arrive in a different order (in the worst case the 
receiver could receive the last segment as the first segment in the 
window)? However doesn't TCP allow the receiver to communicate the 
receiver window to the transmitter? How the receiveing TCP window size 
related to the TLS input buffer?

> 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 mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users