Re: [lwip-users] Duplicated ACK and retransmitted packets

[Kieran Mansley]

On Mon, 2010-02-08 at 19:46 +0100, Lou Cypher wrote:
> I've already read of someone having problems with duplicated ACKs, and I've 
> got
> a similar issue.
> Note that I'm debugging part of an application that could be bugged, though I
> think that the part giving the dup ACKs is quite simple.
> 
> I'm attaching (part of) a Wireshark capture as an example, where the (FTP)
> client is my embedded system running lwIP 1.3.2, and the (FTP) server is a PC
> running FileZilla Server.
> 
> The problem arises in the FTP file transfer, on the data connection; I tried
> separating the most of it, so now I have a couple of functions handling file
> reception, after I send the RETR command to server:

This looks like a driver problem, but you could check a few things to
verify.  It's not clear from your description which end in the trace is
lwIP and which is the PC.  It seems like whenever one end sends more
than one packet in a row to the other the second one is dropped.  This
should be easy to track down as it is very repeatable from the look of
it.

1) If lwIP is the receiver of the lost packets:

If you enable some of the logging in lwIP to print out a few details of
each packet when it is received (don't enable lots of stuff as otherwise
the messages will swamp things) like the TCP sequence number, or IP ID
field, that would show whether the packets are getting as far as lwIP or
being lost in the driver somewhere.

See if lwIP is throwing away received packets and for what reason.
Again some of the LWIP_DEBUG log messages might help here.

2) If lwIP is the sender of the lost packets:

This is perhaps the most likely, as I've heard of drivers in the past
that were unable to cope with a chain of packets and only sent the first
one, which matches the description.  Have a look at how the driver
handles a pbuf when given one from lwIP.  It should be iterating over
pbuf->next to send all the pbufs in that chain.

In both cases there might be something in the LWIP_STATS that helps.
Checking the handling of pbuf chains for the receiving side might also
be a good idea.

Kieran