My immediate thought was, well, after sending its FIN, A enters the FIN_WAIT_1 state. If B’s acknowledgment is lost, A remains in FIN_WAIT_1 because its FIN has not yet been acknowledged. If the retransmission timer expires before an acknowledgment arrives, A retransmits its FIN.
But, thinking about it some more, wouldn’t A retransmit?
I wondered if my gut response was right, so I sketched it out:
The assumption in my sketch is that A’s FIN retransmission timer expires before B sends its own FIN, and before A receives any other acknowledgment of its original FIN.
Here’s the sequence:
- A → B: FIN, ACK — A initiates the active close and enters
FIN_WAIT_1. - B → A: ACK — B acknowledges A’s FIN and enters
CLOSE_WAIT, but this ACK is lost. - A → B: FIN, ACK (retransmission) — Because A has not received acknowledgment of its FIN, A retransmits it when its retransmission timer expires.
- B → A: FIN, ACK — B initiates its own close and acknowledges A’s FIN. B enters
LAST_ACK. - A → B: ACK — A acknowledges B’s FIN, enters
TIME_WAIT, and B entersCLOSEDwhen it receives this ACK.
However, there’s an important timing consideration.
If B sends its own FIN, ACK before A’s retransmission timer expires, and that packet reaches A, then A does not retransmit its FIN. B’s FIN includes the acknowledgment of A’s original FIN, satisfying the outstanding acknowledgment.
So both sequences are valid:
- Delayed B FIN: A retransmits its FIN.
- Prompt B FIN: A receives B’s FIN/ACK and does not retransmit.
In neither case would B retransmit its ACK simply because the ACK was lost. An important distinction here is that TCP does not maintain a retransmission timer for a standalone ACK. If B’s ACK is lost, B does not automatically retransmit that ACK simply because A never received it.
However, if A retransmits its FIN, B may respond by generating another ACK. That is a new acknowledgment triggered by receiving the duplicate FIN, not a timer-driven retransmission of the original ACK.
I created a synthetic packet capture with the following characteristics:
- Host A:
192.0.2.10, TCP port 49152 - Host B:
192.0.2.20, TCP port 8080 - A complete three-way handshake and bidirectional data exchange.
- A initiates the active close with
FIN, ACK. - B’s standalone ACK is intentionally absent, representing the packet lost between B and A.
- A retransmits its FIN after approximately one second.
- B sends
FIN, ACK, acknowledging A’s FIN and closing its own sending direction. - A sends the final ACK.
One detail worth mentioning about this synthetic PCAP: it illustrates a possible TCP closing sequence, not every variation we might encounter with real TCP implementations.
For example, B might generate another standalone ACK when it receives A’s retransmitted FIN, before the application on B closes its side of the connection. Alternatively, B’s FIN/ACK might arrive first and eliminate the need for A to retransmit.
The important lesson is that TCP acknowledgment processing, retransmission timing, and application-driven connection closing all influence the sequence of packets we observe.
What to examine in Wireshark
| Frame | Event |
|---|---|
| 8 | A sends original FIN |
| 9 | A retransmits FIN |
| 10 | B sends FIN, ACK |
| 11 | A acknowledges B’s FIN |
Open the PCAP – pay particular attention to frames 8–11.
Wireshark should identify frame 9 as a TCP retransmission, subject to its TCP analysis settings.
One important point: A packet capture taken at A cannot prove that B’s ACK was transmitted and subsequently destroyed. It can only show that the ACK was not observed. A simultaneous capture at B would provide the evidence needed to establish packet loss in transit. But I am not going down that wormhole.
A Question for the Network Scientists
Look closely at the FIN and ACK sequence numbers in frames 8 through 11.
Remember that a TCP FIN consumes one sequence number, even though it contains no application data.
Now consider this: if B’s FIN/ACK had arrived at A before A’s retransmission timer expired, what would A’s state transition have been? Would A ever have entered FIN_WAIT_2?
This is a useful example of why understanding TCP states matters when analyzing packets. The flags tell part of the story, but the sequence numbers, acknowledgment numbers, and timing complete it.
Here are some helpful references:
CellStream TCP Troubleshooting Profile – a useful Wireshark profile for examining retransmissions and ACK behavior
CellStream TCP Articles – my broader TCP training material
RFC 9293 — TCP – an authoritative technical reference
The answer to that last network science question is particularly interesting: if B’s FIN/ACK acknowledges A’s FIN and carries B’s own FIN, A can transition directly from FIN_WAIT_1 to TIME_WAIT, without entering FIN_WAIT_2
If you would like to help support the continued development of independent networking, broadband, Wi-Fi, VoIP, and packet analysis content, please consider joining our Patreon community where you will gain access to exclusive technical resources, downloadable labs and PCAPs, bonus course content, troubleshooting guides, and additional member-only material. Comments and technical discussion are always welcomed at our Patreon community or on our Discord server. You can also support our work by simply buying us a coffee — every contribution helps us continue creating practical, real-world network science education for professionals and enthusiasts alike.