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
