|
From: | Kieran Mansley |
Subject: | Re: [lwip-users] TCP CLOSING State |
Date: | Wed, 20 Jul 2005 11:03:33 +0100 (BST) |
On Wed, 20 Jul 2005, Jan Ulvesten wrote:
During this test I lost contact with my target on TCP level, checks showed that all TCP PCB's was allocated by in the CLOSING state. It seemed like they never timeout out from this state. I had contact with ping and was able to route IP packets through, by not to create a TCP connection.
CLOSING should be a relatively rare state. The most obvious way for it to occur is that both ends call close at the same time. However, both ends should then acknowledge the other's FIN, and then they should move into TIMEWAIT. In your scenario somehow the acknowledgement of the FIN isn't getting through, so it remains in CLOSING. What should happen is then the FIN is retransmitted, and will eventually get acked. I'm not sure why this isn't happening, or why the ack is getting lost in the first place.
I have no clue about the real cause for this. I use the raw API and no op.sys. My target is pretty loaded with other stuff so it might be a performance problem.
It does sounds like this could be a contributing factor - e.g. causing the ack to get lost.
To debug it further, and establish if there's a problem in our handling of this situation, a packet dump (from something like ethereal) would be handy.
Hope that helps, Kieran
[Prev in Thread] | Current Thread | [Next in Thread] |