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

[Kieran Mansley]

On Fri, 2011-05-06 at 13:21 +0200, Enrico Murador - Research &
Development - CET wrote:
>    Did it happen because the PC network stack was "locked" waiting the
> data in the lost reply? If it is the case, should I expect that the
> data
>    in this packet will be passed to the PC application after receiving
> (and passing to the application) the lost data?

Sort of; not locked as such but TCP will not deliver any further data to
the application until it has received the missing bytes.  TCP guarantees
in-order delivery, so if there is a gap, it holds on to any subsequent
bytes until the gap is filled.  Once the gap is filled the subsequent
bytes will be passed to the application.  

> - Now the PC sends a "duplicate ACK" (p. 10543) wit seq = 27631. If
> I'm not wrong, this is caused by the PC's TCP layer
>    that "sees" the over-than-expected device's data pointer and
> requests missing data (from 27631). 

Yes.

> But we can consider this is also an aknowledgment
>    for the data sent by device on packet 10542?

No.  The ACK in 10543 is sent in response to receiving 10542, but it
does not acknowledge the data in that packet.  It can't acknowledge the
new data until the gap caused by the lost packet is filled.  That is why
it is a duplicate ACK, as it is a repeat of an earlier acknowledgement.

> - On packets 10645, 10646 and 10647 the last two points repeat.
> - When finally the device repeats the missing packet (p. 10685), the
> PC sends an acknowledgment (packet 10686) with ack = (28083 + 226) =
> 28309.
>    Now the data sent by the device in packet 10646 is surely
> acknowledged, right?

Yes.

> - But now, why the device repeats (with packet 10687) the data from
> byte 27857? Because it has not received an acknowledgment for that
> packet

That retransmission is a little confusing.  You are capturing packets at
the PC end, and have to remember that data will take a little time to
get to and from the device end, and so packets may appear to occur in
different orders at the device.  In this case, you see packet 10686 come
before 10687, but the lwIP device probably sees them the other way
around.  I.e. it sends 10687 before it has seen and processed 10686 and
so isn't aware that it doesn't need to send this packet.

>    (so it was not implicit in acknowledgment sent with packet 10543)?
> And if yes, why the PC's TCP layer as not sent the acknowledgment to
> packet 10542?

It has: packet 10542 was acknowledged by 10686.  Acknowledgements are
cumulative and acknowledge all sequence bytes that come before that
value.

Kieran