Re: [lwip-users] Handshake trouble when packet is lost

[Kieran Mansley]

On Tue, 2011-05-03 at 15:17 +0200, Enrico Murador - Research &
Development - CET wrote:
> 
> Can someone take a look and tell me if the described situation could
> be normal in case of packet collisions, or if there is effectively an
> issue?

The example packet capture you've sent looks OK to me.  Here's a table
of the frame number's in the packet capture, and the TCP sequence space
that they cover for the packets sent by lwIP in the area you're
concerned:

10348: 27405-27631
* segment lost - we can see this because of gap in sequence space and
missing IP packet ID 2105 *
10464: 27857 (no data)
10541: 27857 (no data)
10542: 27857-28083
10646: 28083-28309
10685: 27631-27857 <- missing segment retransmitted.
10687: 27857-28083 <- unnecessary retransmission, but benign

I.e. one segment (covering 27631-27857) is lost in the network.  The PC
responds by sending repeated ACKs for sequence 27631.  In the mean time
lwIP continues to send new data (as it should).  After 1 second, lwIP
appears to give up waiting for an ACK for the missing segment and
retransmits it.  This is probably as a result of the retransmission
timer firing.  The PC then acknowledges all the outstanding data and
they carry on.

The set starting at frame 11114 is identical, with again the missing
packet being retransmitted after a timeout of just over 1 second.  This
looks fine.  It worries me that you say the PC gave up on the connection
at this point; 1 second is a very small amount of time to wait to give
up on a TCP connection.

TCP would do better if you had more data in flight at one time as if it
had 3 duplicate ACKs after the loss (each duplicate ACK triggered by the
PC receiving a packet after the missing one) it would immediately do a
fast retransmission rather than waiting for the timer to expire.
However this is often a problem with lwIP projects as small memory tends
to mean few packets in flight.

So while these exchanges seem a bit lengthy, they're probably correct,
and as it all sorts itself out within a second or so I'm surprised that
your application noticed them.  It is this that I think is worth looking
into.  If there are cases where the missing packet is not retransmitted
within a second or two then let me know (ideally with a capture) and
I'll take a look.

Thanks

Kieran