This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

The transmission window is now completely full

0

I have run into the TCP Window Full message and want to be clear about which side the issue is on. I am running a capture on a server and it is capturing traffic being sent from a remote site over a site to site VPN. When I see the message the packet its in is showing source as the server and destination as the remote site firewall... Does this mean the server is running dry and processing power and reporting its buffer is full. I note I see a TCP update window a few packets later from the firewall sending it to the server which then confuses me, maybe its unrelated to the buffer being full on the server. Also is this the same as a zero windows condition? Thanks I'd like to get as much info as possible around this : ) thanks

asked 11 Mar '15, 03:04

Costello's gravatar image

Costello
30448
accept rate: 0%

It's near to impossible to do network troubleshooting based on a text description of what you are seeing.

Can you please upload the capture file somewhere (google drive, dropbox, cloudshark.org), possibly anonymized with tracewrangler.com, and then post the link here?

(11 Mar '15, 03:37) Kurt Knochner ♦

2 Answers:

2

"Window Full" from Wireshark means that Wireshark has calculated that the current packet will fill the receiver's buffer. In order to calculate this correctly, Wireshark has to have captured the TCP three-way handshake so that it knows if window scaling is in use, and if so, what the scale factor is. Window Full is normally, but not always, followed by zero window from the receiver.

The receiver's window is filling up because the application is not reading the data out of the receive buffer as fast as it is coming in from the network. The application is not keeping up. Sometimes Window Full might not be followed by zero window because right at that point the application swoops in and starts reading data out of the receive buffer while the packet with the Window Full message is in transit, so the receive buffer doesn't actually fill up, although it comes close.

However, most of the time, Window Full will be followed by zero window. If you see a lot of Window Full messages, and they are not followed by zero window, and you didn't capture the three-way handshake, then that is a clue that window scaling is in use and the Window Full message is wrong, because Wireshark is not able to calculate the true window size.

When you're analyzing TCP, always try to capture the communication from the beginning, so that you have the three-way handshake in the trace.

answered 11 Mar '15, 09:55

Jim%20Aragon's gravatar image

Jim Aragon
7.2k733118
accept rate: 24%

edited 13 Mar '15, 14:26

This is really great information thank you very much.

(12 Mar '15, 01:06) Costello

1

The "[TCP Window Full]" message from Wireshark means that the system sending this TCP segment has filled up the receive window of the other end with the tcp segment in this packet.

Or put differently: the last received window size of the other end is equal to the length of the tcp segment in this packet.

What it means for your connection can only be determined when seeing the surrounding packets.

answered 11 Mar '15, 03:55

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

If I don't see a zero window condition after a TCP full, this indicate anything?

(11 Mar '15, 07:59) Costello

That all depends on your capture point (near the sender or near the receiver) and the other packets surrounding this packet. So the answer would be: "It depends" ;-)

(11 Mar '15, 09:41) SYN-bit ♦♦

Wow wireshark sure is tricky. I'm only learning but it seems to be difficult to be confident when identifying an issue. There are so many other factors that come into play (lots of red herrings!). I'm using the chappellU videos but is there any where else worth looking at to upskill. I've met quite a few people that have a knowledge of wireshark functionality but none that were confident to pinpoint problems and provide wireshark data to back it up : )

(12 Mar '15, 15:06) Costello