RE: SPAM? [lwip-users] Duplicate FINs and CLOSE_WAIT state

[Jan Ulvesten]

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:address@hidden 
Sent: 14. desember 2005 11:10
To: address@hidden
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.