Actually there is a way to kill a connection – killcx. They claim it works in any state of the connection (which I have not verified). You need to know the interface where communication happens though, it seems to assume eth0 by default.
UPDATE: another solution is cutter which comes in some linux distros’ repositories.
Let me elaborate. Transmission Control Protocol (TCP) is designed to be a bidirectional, ordered, and reliable data transmission protocol between two end points (programs). In this context, the term reliable means that it will retransmit the packets if it gets lost in the middle. TCP guarantees the reliability by sending back Acknowledgment (ACK) packets back for a single or a range of packets received from the peer.
This goes same for the control signals such as termination request/response. RFC 793 defines the TIME-WAIT state to be as follows:
TIME-WAIT – represents waiting for
enough time to pass to be sure
the remote TCP received the acknowledgment of its connection
See the following TCP state diagram:
TCP is a bidirectional communication protocol, so when the connection is established, there is not a difference between the client and the server. Also, either one can call quits, and both peers needs to agree on closing to fully close an established TCP connection.
Let’s call the first one to call the quits as the active closer, and the other peer the passive closer. When the active closer sends FIN, the state goes to FIN-WAIT-1. Then it receives an ACK for the sent FIN and the state goes to FIN-WAIT-2. Once it receives FIN also from the passive closer, the active closer sends the ACK to the FIN and the state goes to TIME-WAIT. In case the passive closer did not received the ACK to the second FIN, it will retransmit the FIN packet.
RFC 793 sets the TIME-OUT to be twice the Maximum Segment Lifetime, or 2MSL. Since MSL, the maximum time a packet can wander around Internet, is set to 2 minutes, 2MSL is 4 minutes.
Since there is no ACK to an ACK, the active closer can’t do anything but to wait 4 minutes if it adheres to the TCP/IP protocol correctly, just in case the passive sender has not received the ACK to its FIN (theoretically).
In reality, missing packets are probably rare, and very rare if it’s all happening within the LAN or within a single machine.
To answer the question verbatim, How to forcibly close a socket in TIME_WAIT?, I will still stick to my original answer:
Practically speaking, I would program it so it ignores TIME-WAIT state using SO_REUSEADDR option as WMR mentioned. What exactly does SO_REUSEADDR do?
This socket option tells the kernel
that even if this port is busy (in
the TIME_WAIT state), go ahead and
reuse it anyway. If it is busy, but
with another state, you will still get
an address already in use error. It
is useful if your server has been shut
down, and then restarted right away
while sockets are still active on its
port. You should be aware that if
any unexpected data comes in, it may
confuse your server, but while this
is possible, it is not likely.
I don’t know if you have the source code of that particular program you’re running, but if so you could just set SO_REUSEADDR via
setsockopt(2) which allows you to bind on the same local address even if the socket is in TIME_WAIT state (unless that socket is actively listening, see
For more information on the TIME_WAIT state see the Unix socket FAQ.