[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Adrian Figueroa
Subject: Re: [lwip-users] TCP Dup ACKs and TCP Window full
Date: Mon, 9 Apr 2018 08:29:42 +0000

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. is my host PC, 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,




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!


Attachment: dump_long.pcapng
Description: Binary data

Attachment: smime.p7s
Description: S/MIME cryptographic signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]