1. Introduction
By default, Wireshark’s TCP parser tracks the status of each TCP session and provides additional information when issues or potential problems are detected. When a capture file is first opened, each TCP packet is analyzed in the order they appear in the packet list. This functionality can be enabled or disabled through the “Analyze TCP sequence numbers” TCP parser preference.
2. TCP Analysis Overview
In TCP analysis, three key pieces of information are related to TCP Zero Window: TCP ZeroWindow, TCP ZeroWindowProbe, and TCP ZeroWindowProbeAck. In real-world scenarios, these may occur individually, such as TCP ZeroWindow, or together, indicating a zero window followed by necessary probes and acknowledgments for window recovery. When performing TCP analysis in packet files, “TCP ZeroWindow” typically displays as [TCP ZeroWindow] in the Info column of the Packet List window, while in the Packet Details window, it is defined under [SEQ/ACK analysis] -> [TCP Analysis Flags].
3. TCP ZeroWindow Definition
The definition of TCP ZeroWindow in TCP analysis is relatively straightforward. It is set when the receive window size is 0 and none of the SYN, FIN, or RST flags are set, indicating that the receiver is notifying the sender to pause data transmission.
The window field in each TCP header advertises the amount of data a receiver can accept. If the receiver can’t accept any more data, it will set the window value to zero, signaling the sender to pause its transmission. In some cases, this is normal — for instance, a printer might use a zero window to pause while loading or reversing a sheet of paper. However, in most cases, it indicates a performance or capacity issue on the receiving end. Resuming a paused connection can take a long time, sometimes several minutes, even if the underlying issue that caused the zero window resolves quickly.
4. Code Example
The following code represents a key part of Wireshark’s analysis of TCP traffic handling zero window notifications, aiding in the correct interpretation and display of TCP connection status and control information. When both conditions—receive window size being 0 and none of the SYN, FIN, or RST flags being set—are met, the packet is classified as a zero window notification. This indicates that the receiver has no available buffer space for incoming data and thus notifies the sender to pause transmission.
/* ZERO WINDOW
* a zero window packet has window == 0 but none of the SYN/FIN/RST set
*/
if (window == 0 && (flags & (TH_RST | TH_FIN | TH_SYN)) == 0) {
if (!tcpd->ta) {
tcp_analyze_get_acked_struct(pinfo->num, seq, ack, TRUE, tcpd);
}
tcpd->ta->flags |= TCP_A_ZERO_WINDOW;
}5. Packetdrill Example
Based on the above TCP ZeroWindow definition and code explanation, the logic of TCP analysis is simple, making it easy to simulate relevant phenomena using Packetdrill.
# cat tcp_zero_window.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 1000 <mss 1460>
+0 > S. 0:0(0) ack 1 <...>
+0.01 < . 1:1(0) ack 1 win 1000
+0 accept(3, ..., ...) = 4
+.1 write(4, ..., 1000) = 1000
+0 > P. 1:1001(1000) ack 1
+0.1 < . 1:1(0) ack 1001 win 0Wireshark displays the information such that No.6 is marked as [TCP ZeroWindow] because the window is 0 and none of the SYN, FIN, or RST flags are set.
6. Instances of TCP ZeroWindow
Examples of TCP ZeroWindow instances are not commonly seen in everyday packet captures. However, when observed, they indicate that the receiving window is 0, meaning the receiver cannot accept data due to performance or capacity issues, signaling the sender to pause transmission. If the window recovery time is long, the TCP transmission rate will naturally decline, and repeated occurrences will noticeably slow application transmission. Various scenarios may also be accompanied by TCP Window Update, TCP ZeroWindowProbe, and TCP ZeroWindowProbeAck messages.
6.1. TCP Window Full + TCP ZeroWindow + TCP Window Update
A common zero window scenario involves a brief instance where the receiving window is 0, immediately followed by a window update message. Initially, the server sends data, detects a full client receive window, and marks it as [TCP Window Full]. Subsequently, the client, marked as [TCP ZeroWindow] due to the window being 0, sends a [TCP Window Update] message 12ms later, restoring the window to 4536.
6.2. TCP Window Full + TCP ZeroWindow + TCP ZeroWindowProbe + TCP Window Update
In another zero window scenario, the receiving window becomes 0, and the TCP ZeroWindow notification is sent. After some time, the sender sends a TCP ZeroWindowProbe packet. Upon receiving the probe, the receiver replies with a TCP Window Update, confirming the window’s restoration.
6.3. TCP Window Full + TCP ZeroWindow + TCP ZeroWindowProbe + TCP ZeroWindowProbeAck + TCP Window Update
This scenario includes all five TCP analysis flags. The client sends data, discovers that the server’s receive window is full, and marks it as [TCP Window Full]. The server then marks No.7 as [TCP ZeroWindow]. After a wait of about 2 seconds, the client sends a TCP ZeroWindowProbe, and the server responds indicating the zero window has not yet recovered, marked as [TCP ZeroWindowProbeAck] + [TCP ZeroWindow]. Following another 300ms, the server sends a TCP Window Update, restoring the window to 14600, completing a full cycle of zero window occurrence, probing, and recovery.
Similar scenarios are as follows:
7. Conclusion
In summary, while TCP Window Full does not necessarily indicate a TCP ZeroWindow occurrence, the presence of a TCP ZeroWindow suggests there must have been a prior TCP Window Full event.