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é _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
