I tested the latest patch in tcp_in.c and that does not solve the problem.
I'm not even sure if it is related? The problem is that when the remote sends a FIN+ACK while lwIP is in CLOSING state, lwIP does not accept the ACK as it's snd_nxt is actually one seq. lower than the received ack. In other words: The remote does ack. something that lwIP believes it hasn't yet sent? If you look at the Etherreal trace supplied in earlier posting, you can see that lwIP does not increment the sequence number in frame 22 when it sends a FIN after receipt of a duplicated ACK? Jan Ulvesten Senior Software Engineer SICOM AS Tel +47 72 89 56 55 Fax +47 72 89 56 51 Mob +47 416 62 033 -----Original Message----- From: Kelvin Lawson [mailto:[EMAIL PROTECTED] Sent: 14. desember 2005 11:10 To: [email protected] Subject: SPAM? [lwip-users] Duplicate FINs and CLOSE_WAIT state Hi, Jan's earlier message reminded me of a problem I've seen in tcp_in.c: When we receive a FIN, we do a +1 and send an ack as we should, and go into CLOSE_WAIT state. If we receive a duplicate FIN, however, we do another +1, and send another ack with the new ackno. This can lead to sticky situations - From memory, I think the effect I saw was a storm of network traffic, where both ends are acking each other constantly, with the LWIP end erroneously upping the ackno every time. The attached patch prevents the additional +1 if we receive duplicate FINs. Cheers, Kelvin. _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
