[lwip-users] TCP Dup ACKs and TCP Window full

[Adrian Figueroa]

I took some steps to see if the packet loss problem can be solved:

 

-          Migrated to ChibiOS 18.2 with Lwip 2.0.3

-          Used only internal ram of STM32 instead of SDRAM

 

Firstly, jumping to Lwip 2.0.3 made no difference at all. I think, this problem is not caused by Lwip itself but probably a configuration error or some buffer that runs full. Maybe even a speed issue of the processor.

 

However, when using internal ram of STM32, the packet losses are much decreased. I know SDRAM works slower than internal ram, but why would this be a problem?

 

I see that the TCP window gets fuller and fuller, as the host PC sends data quicker than the processor can evaluate. Even when no packets are dropped, I still get lots of TCP window full messages.

 

Here you find a complete transmission without errors, and one transmission with some errors (lost packet at frame 73).  I had to upload them here, because they were rejected as an attachment due to size.

 

(no errors)

https://packettotal.com/app/analysis?id=be214249b9478b1be3763a0f81e70312

 

(with errors)

https://packettotal.com/app/analysis?id=4bdc7a415da7708b95df2c2a637795fc

 

In both cases, internal ram is used on the STM32. Please filter with:

 

tcp.port==44000

 

Do you have some suggestions, how to improve the Lwip configuration settings? I attach them to this mail. This is a new version of configuration settings, adjusted to Lwip 2.0.3. Now, only those values are included that differ from the default settings.

 

Thanks in advance,

Adrian

 

 

Von: lwip-users <address@hidden> Im Auftrag von Adrian Figueroa
Gesendet: Monday, April 9, 2018 10:30 AM
An: Mailing list for lwIP users <address@hidden>
Betreff: Re: [lwip-users] TCP Dup ACKs and TCP Window full

 

Yes, I noticed but did not know what to make of it. I now disabled this offloading feature and have a new capture, attached to this mail.

 

192.168.0.101 is my host PC, 192.168.0.100 is the STM32.

 

The first Dup Ack happens at frame 40.

 

I am not sure why the TCP window is full at some point. Is the processor too slow to clear the receive buffers?

 

Best regards,

Adrian

 

 

Von: lwip-users <address@hidden> Im Auftrag von address@hidden
Gesendet: Friday, April 6, 2018 9:39 PM
An: Mailing list for lwIP users <address@hidden>
Betreff: Re: [lwip-users] TCP Dup ACKs and TCP Window full

 

On 06.04.2018 15:30, Adrian Figueroa wrote:

I am writing a bootloader application that receives data over ethernet for flashing the processor it runs on. This is implemented on an STM32F746 running the ChibiOS-RTOS and the HAL drivers that come with it. Consequently, the netconn-api is used. I run Lwip 1.4.1, because Lwip 2.X was not yet ported to ChibiOS and I cannot to do it myself.

 

Lwip is used to implement a simple TCP server. A python TCP client connects to it and sends a chunk of data (around 200k).

 

I moved Lwip pools and heap to external SDRAM, so I can store large amounts of packets without discarding them.

 

First, the TCP server thread waits for an incoming connection with “netconn_accept()”. Find this in “server.c”, attached to this mail. There is also a “helper” thread that cleans things up after a connection was closed (dynamic threads).

 

After “netconn_accept()”, the netconn is handed over to a thread that receives data. Find the receiver functionality in “receiver.c”.

 

The receiver constantly calls netconn_recv(), until the connection is closed. A netbuf is filled each time and chained to the previous netbuf. I also have an evaluation thread that works on the received netbufs, but it does not do anything at the moment. In the end, I have a long netbuf chain in memory, ready for evaluation.

 

The problem is that I lose some of the packets in the process. Find the dump from Wireshark attached. My lwipopts.h is also included in the mail. I chose very generous amounts of storage for all pools, because I have 32 MB of SDRAM available. I get no errors at all in lwip_stats.

 

Do you have any suggestions?

Are you aware that you seem to be using TCP segmentation offloading on your windows network card? The wireshark trace shows TCP segments with 5840 bytes although MSS is advertised as 1460 by lwIP. If you want (us) to debug network problems using wireshark, please ensure you change the driver settings to make wireshark let you see what's on the cable!

Simon

lwipopts.h
Description: Text document

smime.p7s
Description: S/MIME cryptographic signature