Re: [lwip-users] TCP Close State

[Rick Culver]

David,

Thanks for the prompt reply, this was helpful.  My slow timer is working just fine and I discovered that if I wait for 2 minutes the state does eventually change to CLOSED.  Is it valid to conclude that when the state goes to TIME_WAIT that the connection is properly closed at that point and can be openned again?  Or do I have to wait for the timeout to complete before attempting to start a new connection?  What do you think?

Rick

 

----- Original Message -----

From: David Empson

To: Rick Culver ; Mailing list for lwIP users

Sent: Wednesday, February 13, 2008 4:00 PM

Subject: Re: [lwip-users] TCP Close State

Rick Culver wrote:

I am using CALLBACK API and a single TCP connection.  If I close the connection from the remote end everything is fine the state eventually goes back to CLOSED.  However, if I try to close the connection from my end with tcp_close()  the state goes from 4 to 5 to 6 to 10 and never goes to the CLOSED (0) state.  Am I missing a step in closing the connection or what seems to be the problem.  I appreciate any help you can provide.

Using symbolic names, that's ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, then TIME_WAIT.

 

This means you have sent FIN, received ACK, received FIN and sent ACK, so the connection is fully closed. The TIME_WAIT state is there to deal with ACKing retries of the received FIN if your first ACK reply was lost. It transitions automatically to CLOSED after a timeout.

 

If the connection is closed by the other end first, a different series of states are used: CLOSE_WAIT, LAST_ACK, then CLOSED. The events are receive FIN, send ACK, close() called locally, send FIN, receive ACK. The TIME_WAIT state is not used, but the LAST_ACK state also has a timeout (if the ACK never arrives).

 

From a quick glance at the source code in lwip 1.2.0, the timeout in the TIME_WAIT and LAST_ACK states is handled by tcp_slowtmr(), based on the _expression_ 2 * TCP_MSL (two minutes) divided by TCP_SLOW_INTERVAL.

 

If your timer implementation has a problem, e.g. tcp_slowtmr() isn't being called at all, or isn't being called at the rate specified in TCP_SLOW_INTERVAL, then this would explain a timeout never occurring, or taking much longer than expected.