2026-06-02

TCP CLOSE_WAIT and FIN_WAIT PCAP Analysis: Finding Connection Leaks, Half-Closes, and Shutdown Bugs

How to analyze TCP CLOSE_WAIT, FIN_WAIT, TIME_WAIT, half-close behavior, connection leaks, missing close calls, FIN packets, RST packets, and shutdown timing in packet captures.

tcp close_wait, fin_wait, time_wait, connection leak, tcp fin, pcap analysis

TCP connection shutdown problems can fill servers with CLOSE_WAIT, create too many TIME_WAIT sockets, leak file descriptors, break connection pools, and cause intermittent failures under load. Users search for "TCP CLOSE_WAIT pcap", "FIN_WAIT analysis", "connection leak packet capture", "TCP half close", and "server stuck CLOSE_WAIT" when socket state looks wrong but application logs are not enough.

PCAP Surgery is useful because shutdown bugs are timing and direction problems. You need to know who sent FIN, who ACKed it, who failed to close, and whether a reset or timeout followed.

Normal TCP close

A graceful TCP close often uses FIN in both directions:

Peer A -> Peer B: FIN
Peer B -> Peer A: ACK
Peer B -> Peer A: FIN
Peer A -> Peer B: ACK

This four-step close can vary, but direction matters.

CLOSE_WAIT

CLOSE_WAIT means the local application received a FIN from the peer and acknowledged it, but the local application has not closed its side yet.

If many sockets remain in CLOSE_WAIT, the peer already initiated close. The local application likely did not close the socket.

Packet evidence:

  • Peer sends FIN.
  • Local host ACKs FIN.
  • Local host does not send FIN for a long time.

That is often an application resource leak or shutdown-path bug.

FIN_WAIT

FIN_WAIT states occur on the side that initiated close. Long FIN_WAIT may indicate the peer did not acknowledge or did not send its own FIN as expected.

Packet evidence helps identify whether packets were lost, the peer is slow, or application shutdown is incomplete.

RST instead of FIN

Some applications abort with RST instead of graceful FIN. A reset can be normal for error paths, but it may also indicate crashes, unread data on close, load balancer behavior, or timeout policy.

Do not treat FIN and RST as the same. They have different meanings.

Checklist

Use this workflow:

  1. Identify the TCP conversation.
  2. Find the first FIN or RST.
  3. Identify sender.
  4. Check whether FIN was ACKed.
  5. Check whether the other side sent its own FIN.
  6. Measure delay between FIN and final ACK.
  7. Correlate with socket states on hosts.
  8. Look for repeated CLOSE_WAIT patterns.
  9. Preserve shutdown packets when trimming.
  10. Combine pcap with application close-path logs.

Final diagnosis

TCP CLOSE_WAIT and FIN_WAIT issues are shutdown-state problems. Packet captures can show who initiated close, who acknowledged, who failed to finish, and whether the connection ended gracefully or by reset.

PCAP Surgery helps preserve the exact close sequence so connection leaks and half-close bugs can be diagnosed from packet evidence instead of socket-state snapshots alone.