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

[Enrico Murador - Research & Development - CET]

Thank you Kieran!

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.

Thank you for explanation, now it is a bit clearer. I still do not understand why packet 10464 contains seq = 27857.
lwIP device replies to a retransmission with ack = 27631 despite it never receives ack = 27857.
Perhaps I miss something.

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.

Ok. This timeout was set only for testing purposes... It is simpler to "catch" a collision with many devices connected and with a short timeout.
There is no problem to wait more (but I think no more than 3 seconds...).

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.

If waiting no more than two or three seconds is ok, we can try easily.

Thanks

Kieran

Thank you very much
Enrico

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

--
Enrico Murador
R&D

CET Electronics via E. Fermi, 1 31050 Zenson di Piave (TV) Italia Phone: +39 0421 344100 Fax: +39 0421 464042 Web: http://www.cet-electronics.com/