1. Introduction
By default, Wireshark’s TCP parser tracks the status of each TCP session and provides additional information when it detects issues or potential problems. Upon first opening a capture file, every TCP packet is analyzed in the order it appears in the packet list. This feature can be enabled or disabled through the “Analyze TCP sequence numbers” TCP parsing preference.
2. TCP Analysis Display
When conducting TCP analysis in a packet file, “TCP ACKed unseen segment” is typically displayed as follows: in the Packet List window, the Info column highlights it with a [TCP ACKed unseen segment] in red on a black background; in the Packet Details window, under the TCP protocol tree, it is defined in [SEQ/ACK analysis] -> [TCP Analysis Flags].
3. TCP ACKed Unseen Segment Definition
The definition of TCP ACKed unseen segment in TCP analysis is quite straightforward: it is set when the expected next acknowledgment number for the reverse direction is defined and is less than the current acknowledgment number.
The relevant code involves a somewhat complex TCP analysis logic, as it deals with the calculation of sequence and acknowledgment numbers in different directions, including a special scenario involving zero window recovery. Essentially, the code identifies and processes situations where “lost packets are acknowledged” in the TCP data stream, adjusting the maxseqtobeacked variable to reflect the maximum sequence number that has been acknowledged, thereby accurately tracking and analyzing the status of the TCP connection.
/* ACKED LOST PACKET
* If this segment ACKs beyond the 'max seq to be ACKed' in the other direction,
* then that means we have missed packets going in the other direction.
* It might also indicate we are resuming from a Zero Window,
* where a Probe is just followed by an ACK opening again the window.
* See issue 8404.
*
* We only check this if we have actually seen some seq numbers
* in the other direction.
*/4. Packetdrill Example
Based on the definition and code explanation for TCP ACKed unseen segment, simulating TCP communication with Packetdrill can be challenging since this phenomenon usually occurs when the acknowledged data segments are not captured. The first step is to simulate a complete data communication via Packetdrill, and then capture the packets with tcpdump. For instance:
# cat tcp_acked_unseen_segment.pkt
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
+0 < S 0:0(0) win 16000 <mss 1460>
+0 > S. 0:0(0) ack 1 <...>
+0.01 < . 1:1(0) ack 1 win 16000
+0 accept(3, ..., ...) = 4
+0 < P. 1:21(20) ack 1 win 15000
+0 < P. 21:41(20) ack 1 win 15000
+0 < P. 41:61(20) ack 1 win 15000
+0.1 read(4, ..., 60) = 60 
Next, by ignoring packet No. 6 in Wireshark, it indicates that the TCP flow did not capture that segment, leading to the classification of packet No. 7 as [TCP ACKed unseen segment] because the maximum acknowledgment number in the reverse direction is from packet No. 4, which is less than the ACK number of packet No. 7.
5. Examples of TCP ACKed Unseen Segment
Instances of TCP ACKed unseen segments are commonly observed during regular packet captures and are typically considered as missing acknowledged data segments. However, various scenarios may also present related messages like TCP Previous segment not captured and TCP Spurious Retransmission.
5.1 Uncaptured Data Segment: The most frequent scenario occurs when one or more data segments are not captured. For instance, in a TCP flow, if the reverse direction does not capture a segment from Seq 1 to NextSeq 2401, packet No. 120 will be marked as [TCP ACKed unseen segment] because the maximum acknowledgment number is less than the ACK number.
5.2 Zero Window Special Case:
Regarding the recovery from a zero window probe state, the code checks if the following three conditions are met: the ACK value is exactly one more than the last ACK value, the current sequence number equals the expected next sequence number, and the previous segment is a zero window probe packet. If these conditions are satisfied, the current packet is marked as a Window Update, and some sequence number-related variables are updated. In this case, it is not considered an “ACKed lost packet.”
The explanation above covers the code segment for zero window probe state recovery. Looking at the following actual case, there was no occurrence of packet loss, which is why I initially found it confusing that No. 12 was labeled as [TCP Window Update]. This is because it needs to satisfy GT_SEQ(ack, tcpd->rev->tcp_analyze_seq_info->maxseqtobeacked), meaning the ack number 15622 must be greater than maxseqtobeacked, which should be the NextSeq Number 15622 from No. 11, right? Since they are equal, there shouldn’t be any subsequent code logic executed, and it shouldn’t be marked as [TCP Window Update].
But why does [TCP Window Update] actually appear? After seeking help from various sources and continuously looking for examples, I finally found relevant explanations in the code. It turns out to be a special case of the zero window. In simple terms, the NextSeqNum of the [TCP ZeroWindowProbe] is excluded and does not update maxseqtobeacked. Therefore, for the above case, the value of maxseqtobeacked remains the NextSeqNum of No. 5, which is 15621, so GT_SEQ holds true.
5.3 TCP Keep-Alive Special Case: Instances may arise where TCP packets are judged as [TCP ACKed unseen segment] without actually capturing lost segments.
For example, if the maximum acknowledgment number in the reverse direction is less than the current ACK number, it may trigger this classification even when the data was successfully received.
5.4 Disappearing TCP ACKed Unseen Segment: Current versions indicate that packet No. 6 will not be marked as [TCP ACKed unseen segment], even though it should clearly show uncaptured segments between No. 4 and No. 5. This presents a potential bug or an area where TCP parser functionality might need enhancement.
6. Conclusion
In summary, [TCP ACKed unseen segment] reflects an important aspect of TCP analysis in Wireshark, highlighting situations where acknowledged data may not have been captured. Understanding the underlying logic and conditions for this classification can provide valuable insights into TCP traffic behavior.