Re: [lwip-users] endless loop after window updates

[Kieran Mansley]

On Mon, 2006-11-13 at 20:20 +0100, Andre Puschmann wrote:
> Hey folks,
> I still have those (at least for me) curious problems with the stack. I
> did some more research and figured out a way to turn lwip into kind of
> endless loop with only 2 packets every 1500ms.
> If I send many packets very quickly to a windows box and then produce
> some load on it (e.g. write the received data into a file) windows xp
> decreases its receive_wnd with every single ACK. This is o.k. to lwip up
> to the certain point where windows resets its receive_window (e.g.
> 13720bytes .. packet #226 in trace).
> lwip now sends as many packets as fit into the new window, which
> properly isn't the right behavior, isn't it?

Looks fine to me - there's no obvious sign of congestion, so it can send
as many packets (up to the advertised receive window) as it likes.  The
other end continues to advertise more space to send into, and so lwIP
carries on sending.  No problems here as far as I can see.

> After the following ACK lwip continues bursting out packets regardless
> of the seq-no's xp is expecting.
> I am still wondering why the whole systems now gets into the this
> endless loop with 1 packet per second transfer rate.
> It is always the first of two transmitted packets which gets lost, which
> seems, at least to me, to be very odd.

No packets are getting lost.  In each burst there are three packets from
lwIP.  This first is a retransmission of a previous packet, the second
has a bad checksum (and so will need to be retransmitted as the receiver
will throw it away; the retransmission forms the first packet of the
next burst) and the third is fine.  There is then a delay while lwIP
waits to see if it gets acknowledgements for the data.  Because one was
thrown away, it doesn't and so it retransmits the missing packet, and
can then carry on - this is the start of the next burst.  Because it
interprets having to retransmit as a clue about congestion it can now
only send a few packets at a time, rather than the long streams it was
before.  The connection would "heal" automatically if it didn't keep
sending packets with bad checksums.

I've not seen something get into this very repetitive and regular state
before.  There is something clearly wrong.  It is almost as if the act
of retransmitting a packet is causing another one to get a bad checksum.
That is the sort of thing I think you need to look into.

Hope that helps,

Kieran