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

A server accumulating CLOSE_WAIT, a peer stuck in FIN_WAIT, or a connection pool that exhausts file descriptors needs packet-level shutdown chronology. Determine who sent the first FIN, whether it was acknowledged, whether the other half ever closed, and whether a reset or retransmission interrupted the four-way teardown. A PCAP can prove TCP half-close behavior and packets on the wire; only host socket state and process evidence can show why an application left a received FIN in CLOSE_WAIT.

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.