Re: [lwip-users] altcp_tls_mbedtls

[Simon Goldschmidt]

Giuseppe Modugno wrote:
> An: address@hidden
> Betreff: Re: [lwip-users] altcp_tls_mbedtls
>
> Il 25/02/2019 20:19, address@hidden ha scritto:
> > Am 22.02.2019 um 10:24 schrieb Giuseppe Modugno:
> >> Il 22/02/2019 09:43, Simon Goldschmidt ha scritto:
> >
> > [snip]
> >
> >>>> 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.
> >
> > TCP_WND is what we announce to the remote host to be able to buffer 
> > for RX.
> >
> > For TX, what we buffer is the minimum of what the remote host tells us 
> > to be able to buffer and the memory we have/allow (both available heap 
> > memory and the limitation defines SND_BUF and SND_QUEUE_LEN).
> 
> Ok, but I couldn't understand the relation between lwip receiving window 
> and TLS incoming buffer. If MBEDTLS_SSL_IN_CONTENT_LEN is 16kB, should I 
> need a TCP_WND at least 16kB, for a total of 32kB of memory only to 
> handle incoming TLS traffic?

No. TCP_WND is not something you have allocated. It's the amount of data
the remote host can send before we reopen the window.

In the altcp TLS case, the data is received and ACKed, then the TLS
adaption layer passes it into mbedtls and frees the buffer. However, the
window update is sent by the application code that is TLS-agnostic. So
the window update is only sent after the block has been decrypted. And
since such a block may be up to 16 kByte, the tcp window has to be at
least that big, too, or you can get a deadlock.

> Suppose I have a TCP_WND of only 2kB and incoming TLS buffer of 16kB. 
> The TLS transmitter could send maximum 2kB of data that are buffered in 
> the lwip receiving window. lwip calls altcp_recv(), so 
> altcp_mbedtls_lower_recv() with received data (2kB maybe segmented in 
> small pbufs and pbuf chains).
> 
> I can't follow the code, but I expect those data are immediately passed 
> to mbedTLS library that should copy those data to its 16kB incoming 
> buffer, freeing receiving window. I think the lwip TCP receiving window 
> could be smaller than mbedTLS incoming data buffer.

To make the receiving window smaller, you'd have to change the code.
However, you would gain nothing: TCP_WND is *not* a buffer. The actual
buffer is in mbedtls and you can't shrink that. TCP_WND just describes
this behaviour.

The only downside I see is that this way, all other non-TLS applications
get a bigger TCP_WND too. That's why we want to add code to control TCP_WND
at runtime per pcb.

Regards,
Simon