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

[Lou Cypher]

I made some more tests, and found a couple of different things going on, one on
my side (data buffering), the other /apparently/ in lwIP.

Take as a reference the extract of Wireshark's trace in the OP, at least with
the packets
 28 PC -> lwIP (FTP command reply)
 29 PC -> lwIP (data)
 30 PC -> lwIP (data)   (**lost in buffering**)
 31 lwIP -> PC (ACK)
 32 PC -> lwIP (data)
 33 lwIP -> PC (ACK)    (duplicated)
 34 lwIP -> PC (ACK to command reply)
 35 PC -> lwIP (data)   (retransmission)

1. Retransmission
The TCP retransmission packets are there because of a data buffering error. The
MAC I'm using has been instantiated in an FPGA with just *one* packet buffer:
when a second packet arrives, and I'm still handling the first one, the new one
gets lost.
In that trace: packet 29 (data, server -> client) makes it through, but packet
30 is not seen by lwIP.
I talked to the FPGA guy, and probably I could get double buffering for the MAC,
so that things become faster.

In the meanwhile (having TCP_MSS = 1460) I reduced the TCP_WND, and made it
exactly the size of MAC rx buffer (2048 bytes), such that only a single packet
(1460 + stuff) can be sent at once... Retransmissions have mostly disappeared --
small packets are still sent /sometimes/, when their size is <= 2048 - (1460 +
stuff).
Is my assumption correct?

2. Duplicated ACK
They do exist, yes. It can be seen in trace packets 31 and 33.
Packet 31 is a legitimate ACK, has IP packet ID = 105, and ACKs TCP packet 29,
with acknowledgement number 1461.
Packet 33 has IP packet ID = 106, and for TCP it ACKs *again* 1461, so this is a
duplicated ACK. Note how it is also a valid packet packet, with valid checksum,
so it can only have been generated by lwIP.
Looks like it should have ACKed packet 32.
Again: does it make sense?


~ Lou