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