Re: [lwip-users] altcp_tls_mbedtls

[Simon Goldschmidt]

On 26.02.2019 17:15, Giuseppe Modugno wrote:
> Il 26/02/2019 09:58, Simon Goldschmidt ha scritto:
> > Giuseppe Modugno wrote:
[snip]
> > 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.
>
> Could you point me to the code that reopen the window after the block 
> has been decrypted? I couldn't find it, my shame.


There's not "the code" that does this. The raw tcp callback application 
does this by calling altcp_recved(), which is directly mapped through to 
the lower protocol (TCP in this case). The mbedtls layer only calls 
tcp_recved() for the overhead bytes that don't get handled by the 
application, so that it is ensured the window always reopens correctly.


> Isn't possible to reopen the window (call tcp_recved) even when a 
> partial TLS block is received? I couldn't understand why lwip needs to 
> reopen the window only when an entire block is received (and decrypted 
> by mbedTLS).
> Suppose 1kB of a 16kB encrypted block is received, altcp_tls_mbedtls 
> pass the data to the application mbedTLS that copy them in its buffer, 
> then frees the received pbufs. Now we can reopen the window. What's 
> wrong with this approach that can keep TCP_WND small?


That would also be possible. But then you would lose the ability for the 
application to throttle the remote host's sending speed (in case the 
application handles data slower than it possibly arrives - again, think 
of an upload programmed to flash).


You'd then just call tcp_recved for everyhing you successfully pass into 
mbedtls and ensure the altcp_recved() calls from the application don't 
get passed through to TCP.


> > 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.
>
> TCP_WND isn't a buffer, however I need to reserve a sufficiently sized 
> memory pools (I'm using memory pools for pbufs with 
> MEMP_MEM_MALLOC=0). And memory pools are statically allocated memory, 
> so I end up with 16kB allocated buffer for mbedTLS and 16kB memory 
> pools for storing at least TCP_WND bytes.
>
> In core/init.c there's an error:
>
> #if !MEMP_MEM_MALLOC && PBUF_POOL_SIZE && (TCP_WND > (PBUF_POOL_SIZE * 
> (PBUF_POOL_BUFSIZE - (PBUF_LINK_ENCAPSULATION_HLEN + PBUF_LINK_HLEN + 
> PBUF_IP_HLEN + PBUF_TRANSPORT_HLEN))))
> #error "lwip_sanity_check: WARNING: TCP_WND is larger than space 
> provided by PBUF_POOL_SIZE * (PBUF_POOL_BUFSIZE - protocol headers). 
> If you know what you are doing, define LWIP_DISABLE_TCP_SANITY_CHECKS 
> to 1 to disable this error."
> #endif


Yes, that's room for improvement :-)


You probably don't need to buffer a complete TCP_WND in the rx pbufs as 
I suppose mbedtls just copies the data into its buffers until a whole 
message is received...


Regards,

Simon