Window Update Not From Microsoft

Posted 11-17-2010

The topic of Window Update packets surfaced at ask.wireshark.org recently.

"Is it normal to see tcp window update packet (tcp.analysis.flags as a filter) for
EVERY get/post request from a client workstation on the same LAN?"

The answer is... maybe. First let's talk about the infamous Window Update
designation in Wireshark.

As TCP data packets arrive, their data is placed in the TCP receive buffer space
until an application pulls that data out. If the data is sluggish at pulling the data
out, the TCP receive buffer size begins to decrease. This is seen in every ACK
packet sent by the host that is receiving data.

Wireshark doesn't alert you to the shrinking TCP window size or any window size
problems until a host gets down to a window size of zero. Then Wireshark
screams that there is a Window Zero condition.

After an application picks up data from the TCP receive buffer there is more
space available and the sender increases their window size field value. THIS is
what triggers Wireshark to mark the packet as a Window Update packet. It's a
good thing.

The figure below shows the Wireshark Expert Infos window Chats tab which is
where the Window Update notices are displayed. They've moved from the more
alarming Warnings or even Notes section to this boring location.

How can you quickly find if you have Window Update packets in your trace file?
Apply a display filter for expert.message == "Window update" - it's a simple
and elegant filter.

If you have the Wireshark Network Analysis book, check out Chapter 13,
Wireshark's Expert System, for a definition of all the TCP expert notifications.

Now what about seeing a TCP Window Update packet for EVERY GET/POST
request from a client workstation on the same LAN? Well - it simply means that
the HTTP application is pulling the data out at the time a GET/POST is issued. Is
that a problem? Nope. Is it normal? Nope - buy hey! It's not a Window Zero issue
and there's still buffer space available!

Enjoy!

Laura