----- Original Message -----
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.