You Can’t Handle the Data!

Wireshark is a great tool but to my mind it’s only worth using when you’ve exhausted other avenues: firewall or event logs, browser developer tools or even tcpdump. However, there are some occasions when it’s all you have, especially if you don’t have access to intermediate network or filtering devices.

I encountered a scenario recently where it was very useful but first I’d like to do a quick refresher on tcp windows.

In a tcp session, the initiator (SYN sender) and responder (SYN/ACK sender) tell each other the amount of unacknowledged bytes they can accept in their buffer – otherwise known as the tcp window size.

So, for example, in the SYN packet below, the client defines its window size as 64240 bytes.

But that isn’t the whole story. The windows size is defined in a 16 bit field in the tcp header giving a top value of 65536 bytes which was probably OK in the early days but not now. So this is modified by a scaling factor or shift count of up to 14 which is a power of two: so in our SYN packet we have a scaling factor of 8 which Wireshark helpfully tells us means multiply by 256 (2 to the power 8)

So our window size is 64240 X 256 = 16,445,440 Bytes – which sounds a lot better.

In the second packet, (the SYN/ACK), the responder comes back with a lower value

Its scaling factor is also less ambitious.

So in this example, the client’s window size is 29200 x 128 = 3,737,600

Both sides of the tcp session have to agree to use windows scaling though, as seen above, they don’t have to agree to the same values and typically most tcp connections are assymetric with a lot more data flowing one way than the other.

In Wireshark there is a Wireshark-calculated field called ‘Calcuated Window size’ which is contrasted below against the window size to show the multiplier effect (Wireshark has to see the SYN/SYN ACK negotiation to give a calculated window size that’s accurate. If it hasn’t will show the scaling factor as -1 (unknown))

OK, to our problem which does not involve the hosts in the capture above.

A package manager was failing to download a file through a proxy. I have not included the ip addresses in order to protect the innocent and because they’re not really required. In the capture excerpts below the client is coming from a high port (52206) and talking to a proxy server on port 80. The window size is accurate as there is no scaling in play.

In the Wireshark trace the ‘expert info’ window showed a lot ‘TCP Window Full’, ‘TCP Zero Window’, and ‘TCP ZeroWindowProbes’ so jumping to one of these occurences:

(The columns from L to R are :Time since start of capture | Window size | Information)

In the first packet, Wireshark marks the packet ‘TCP Windows Full’ when it knows the packet it is sending will fill up the buffer/tcp window of the recipient: the client. The client’s window size does indeed go down to zero and stays there for a full 19 seconds before it sends an update with a new Window size (64800). saying its open for business again.

You’ll notice during this time the proxy was sending what Wireshark marks as ‘TCP ZeroWindowProbes’. These are packets with a length of one, presumably sent to see if the client will acknowledge them. If the client did acknowledge them it then it’s sequence number would match the previous packet’s ‘next sequence’ number (493101) but as you see below it stays resolutely on 493100. It will not be rushed.

After the tcp window update (the green packet in the first trace) the transfer rattled along happily for a little bit longer until the following occurred…

Almost exactly the same scenario as in the first trace excerpt, except this time the client didn’t send a tcp windows update in time and the proxy (or more accurately the destination server working through the proxy) became impatient and sent a tcp reset to abort the connection.

So, Wireshark didn’t solve the problem, but it did confirm that the network and its components were doing their job. The data was getting to the client but for some reason the client was signalling it couldn’t take any more data. There was no indication why this was the case or what the client was doing with the data but that’s not in Wireshark’s remit. And in the trace excerpt above, the red reset packet is the proxy rising to its metaphorical feet pointing at Tom Cruise and roaring, ‘you can’t handle the data!!’.