No... I'm not Microsoft-bashing (today)... not really. After all, this issue is seen on other operating systems as well. I recorded information about this in the things that perplexes many new and experienced analysts.You may be aware that Wireshark has an Expert Info Composite entry for "Window is Full" and "Frozen Window" but unfortunately, this condition can be occurring on your network without Wireshark catching it.
You can set up a butt-ugly color filter and a display filter to alert you to this condition. Let me explain...
In the picture above, I've added column for the receive window size value set in the TCP headers of each packet. It's a custom column using the syntax tcp.window_size. I also added a column for the tcp.len value so I can see how much data is contained in each packet.
Notice in packet 361 that 10.0.52.164 is advertising a window size of 2,920 bytes - enough for two 1460-byte segments to fill as Wireshark notes in packet 363 [TCP Window Full]. The full receive buffer leads the client to begin advertising a receive window size of 0. Ok... duh... We can spot that one easily!
Now look at this screenshot. This delay is caused by a window sized problem as well - but this time the window size field didn't go alt the way down to zero - its at 536 (packet 374). That's too small for the queued up TCP segment at the other side so you might as well have said "shut up" with a window zero setting.
So what can we do about this? How can we easily see that we are having this problem when Wireshark doesn't have an Expert Notification for this? Aha! Here's where your butt-uglies come into play. Make a butt ugly filter for:
(tcp.window_size < reset ="="">
Check out the Trace File Analysis: TCP In-Depth course for more information on working with TCP traffic!
Laura
Enjoy life one bit at a time!
