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

[Andre Puschmann]

Kieran Mansley wrote:
> 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 pac ikets (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.

You're right. I guess I was a bit confused about this large number of
packets.

>> 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.

I mean to lwip it looks like the first of two packets always gets lost.
Its true that windows drops this packet because of a bad checksum, but
after lwip retransmitted the packet (with the same checksum) it's ok for
windows, that confuses me. I can't see any differences between those two
packets.


> Hope that helps,
> 
> Kieran

Kind Regards

André