Understanding TCP Window Full in Wireshark

---

1. Overview of TCP Window Full Analysis

Wireshark’s TCP dissector, by default, monitors the state of each TCP session and provides insights when it detects problems such as “TCP Window Full” or other potential issues. When you open a capture file, Wireshark analyzes each TCP packet sequentially as they appear in the packet list. This feature can be controlled through the “Analyze TCP sequence numbers” setting in the TCP preferences, allowing users to enable or disable the analysis based on their troubleshooting needs.

2. Background on TCP Window Full Conditions

When conducting TCP analysis on packet files, the “TCP Window Full” alert typically appears as follows:

• 2.1 Packet List Window: In the Info column, “[TCP Window Full]” is highlighted in red text on a black background.
• 2.2 Packet Details Window: In the TCP protocol tree, under [SEQ/ACK analysis] -> [TCP Analysis Flags], the analysis of the TCP packet is explained.

3. Defining TCP Window Full

In simple terms, a “TCP Window Full” condition occurs when the size of a TCP segment sent by the sender exceeds the receiver’s advertised window size. This limitation is due to the receiver’s window size, which is a condition marked by the sender, not the receiver.

When the segment size is non-zero, and the window size in the reverse direction is known, if the segment size exceeds the reverse window size, the “TCP Window Full” flag is set.

Here’s an example of code that detects the “Window Full” condition in TCP data streams. The flag is set when the current data segment reaches the boundary of the receiver’s advertised window:

/* WINDOW FULL
 * If we know the window scaling
 * and if this segment contains data and goes all the way to the
 * edge of the advertised window
 * then we mark it as WINDOW FULL
 * SYN/RST/FIN packets are never WINDOW FULL
 */
if( seglen>0
&&  tcpd->rev->win_scale!=-1
&&  (seq+seglen)==(tcpd->rev->tcp_analyze_seq_info->lastack+(tcpd->rev->window<<(tcpd->rev->is_first_ack?0:(tcpd->rev->win_scale==-2?0:tcpd->rev->win_scale))))
&&  (flags&(TH_SYN|TH_FIN|TH_RST))==0 ) {
    if(!tcpd->ta) {
        tcp_analyze_get_acked_struct(pinfo->num, seq, ack, TRUE, tcpd);
    }
    tcpd->ta->flags|=TCP_A_WINDOW_FULL;
}

4. Packetdrill Example

The logic for TCP analysis is straightforward, making it easy to simulate the “TCP Window Full” condition using packetdrill. Here’s an example:

# cat tcp_window_full.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, ..., 500) = 500
+0 > P. 1:501(500) ack 1
+0.1 < . 1:1(0) ack 501 win 1000

+.1 write(4, ..., 1000) = 1000
+0 > . 501:1001(500) ack 1
+0 > P. 1001:1501(500) ack 1
+0.1 < . 1:1(0) ack 1501 win 1000

After capturing packets with tcpdump and analyzing them in Wireshark, it becomes evident that since the client (No. 5) advertised a window size (Win) of 1000, the server can only send data segments up to 1000 bytes. Consequently, the server sends two packets (No. 6 and No. 7), each with a length (Len) of 500 bytes. In packet No. 7, Wireshark flags it as “[TCP Window Full]” because the total size of the sent bytes has reached the window size advertised by the client.

The BIF size is 1000, and the expert information indicates that the TCP window specified by the receiver is now completely full.

5. Problem Analysis Using TCP Window Full Indicators

Regarding examples of TCP Window Full, under normal circumstances, considering the release speed of the receiver’s window and the presence of Window Scaling, the occurrence of a TCP Window Full condition is relatively uncommon. However, in different scenarios, related events such as TCP Window Update, TCP ZeroWindow, TCP ZeroWindowProbe, and TCP ZeroWindowProbeAck may also appear.

5.1 Window Full

It can be seen that the client at No. 277 declared a window size (Win) of 8712, while the server at No. 278 marked [TCP Window Full] because the in-flight bytes reached 8712.

Later in the communication process, the client’s window size dropped to 0, leading to the marking of [TCP ZeroWindow] at No. 281. As the receive window was released, an ACK with a window size of 4356 was sent at No. 282. When the server sent the next data segment at No. 283, [TCP Window Full] was once again marked, for the same reason: the in-flight bytes reached 4356.

In this case, the client does not support Window Scaling, as the option was not included in the TCP SYN.

5.2 Special Cases of Window Full

When the TCP communication rate is slow, and you suspect that one end’s receive window is full or problematic, but there’s no clear [TCP Window Full] indication, trust your judgment—it could very well be a TCP window full issue. The absence of a [TCP Window Full] marker might simply mean that the packet capture or TCP stream is incomplete, missing information from the TCP three-way handshake. Without this data, you can’t determine whether the stream supports Window Scaling or know its exact value. Without this info, it’s impossible to calculate the actual window size based on the Win field in the packet, so you can’t assess when a window full event occurs. For instance, if the only information available is a receive window of 250, without knowing that the Window Scale factor is 4, how would you calculate the Win size as 1000?

In such cases, what you observe is one side announcing a small Win value, but the other side sending in-flight data that exceeds this value. You can infer that the TCP three-way handshake is missing. It’s important to note that Wireshark cannot make this judgment because the packet capture is incomplete. However, in a real data stream where both sides support Window Scaling, the communication flow would proceed with both sides using their respective scaling factors to calculate and transmit data. This can be easily simulated by omitting the first three packets of the TCP handshake in the packetdrill example. In such a case, by No. 7, the [TCP Window Full] marker no longer appears, even though the peer at No. 5 advertised a Win of 1000. The Window size scaling factor is marked as -1 (unknown), and the [TCP Window Full] code (tcpd->rev->win_scale = -1) has no further basis for judgment, so the marker doesn’t reappear. Note the distinction from a Window size scaling factor of -2 (no window scaling used), which indicates that the packet capture is complete, including the TCP three-way handshake, but both sides opted not to use Window Scaling.

How do you verify this? If possible, reproduce the TCP connection and capture the TCP three-way handshake again. Whether the scaling factor is -2 (not supported) or some other value, knowing this won’t allow you to manually set the Window Scale value and trigger the [TCP Window Full] marker again.

5.3 First ACK and Window Full

This brings us to the earlier code segment involving tcpd->rev->is_first_ack. As shown below, if is_first_ack is true, the offset for the Window, i.e., the Window Scale, is set to 0 instead of using the Window Scale value from the TCP three-way handshake.

tcpd->rev->window << (tcpd->rev->is_first_ack ? 0 : (tcpd->rev->win_scale == -2 ? 0 : tcpd->rev->win_scale))

The is_first_ack flag is specifically set during the TCP three-way handshake, meaning it’s initialized as True for both SYN and SYN/ACK packets.

if(tcph->th_flags & TH_SYN) {
    if(tcph->th_flags & TH_ACK) {
        expert_add_info_format(pinfo, tf_syn, &ei_tcp_connection_synack,
                               "Connection establish acknowledge (SYN+ACK): server port %u", tcph->th_sport);
        /* Save the server port to help determine dissector used */
        tcpd->server_port = tcph->th_sport;
    } else {
        expert_add_info_format(pinfo, tf_syn, &ei_tcp_connection_syn,
                               "Connection establish request (SYN): server port %u", tcph->th_dport);
        /* Save the server port to help determine dissector used */
        tcpd->server_port = tcph->th_dport;
        tcpd->ts_mru_syn = pinfo->abs_ts;
    }
    /* Remember where the next segment will start. */
    if (tcp_desegment && tcp_reassemble_out_of_order && tcpd && !PINFO_FD_VISITED(pinfo)) {
        if (tcpd->fwd->maxnextseq == 0) {
            tcpd->fwd->maxnextseq = tcph->th_seq + 1;
        }
    }
    /* Initialize the is_first_ack */
    tcpd->fwd->is_first_ack = TRUE;
}

In the following case, No. 79 is marked as [TCP Window Full]. At first glance, this seems odd since the TCP three-way handshake clearly indicates that both sides support Window Scaling, and both have a large scaling factor of WS 128. Yet, after transmitting just 10 MSS 1448 segments between No. 70 and No. 79, the window full condition occurs.

No. 79 shows a BIF size of 14480, which equals the Win value advertised in the SYN/ACK (Win 14480), but Window Scaling was not applied. Instead, for the [TCP Window Full] evaluation, a scaling factor of 0 was used rather than WS 128.

This happens because, for the client at No. 79, tcpd->rev->is_first_ack corresponds to the is_first_ack value on the server side. Since the only packet in the rev direction is the No. 68 SYN/ACK, is_first_ack remains True. As a result, the Window offset (i.e., Window Scale) is set to 0, leading to the final determination of [TCP Window Full].

5.4 Continuing the Discussion on Special Cases of Window Full

Here’s another case: the server’s packet No. 5 is flagged as [TCP Window Full]. This occurs because the client’s packet No. 3 advertised a Win of 1000, which means the Win value of 250 was multiplied by a Window Scale of 4. As a result, the server could send two 500-byte data segments in packets No. 4 and No. 5, and No. 5 was marked with [TCP Window Full].

This means that when analyzing packet No. 5 on the server side, the Window Scale value in the reverse direction was correctly interpreted as 4, not 0, which indicates that the client’s is_first_ack value was False. This is achieved while analyzing the client’s ACK packet No. 3 through the following code:

/*
 * Remember if we have already seen at least one ACK,
 * then we can neutralize the Window Scale side-effect at the beginning (issue 14690)
 */
if(tcp_analyze_seq
    && (tcph->th_flags & (TH_SYN | TH_ACK)) == TH_ACK) {
    if(tcpd->fwd->is_first_ack) {
        tcpd->fwd->is_first_ack = FALSE;
    }
}

6. Conclusion

In summary, understanding the “TCP Window Full” condition and its implications in TCP analysis is crucial for effective troubleshooting. By carefully interpreting window sizes and packet flows, Wireshark users can identify bottlenecks and optimize network performance.