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

I was wondering if anyone had any advice for what i'm seeing in our network.

I was looking at some captures and noticed that the window scale factor for anything coming back through the blue coat was a scale factor of 0. Which means I support it..but I wont scale.. That was just odd me to and I started to do some digging. I couldn’t see how every site coming back had a scale factor of zero. Which made me thing the bluecoat was doing something fishy.

I setup a small http webserver on my home laptop just so I can connect and get the 3-way handshake and see what was really going on. And what I saw was, in fact when the server sends a response to back to the client its not zero at all, it sent a scale factor but when it went through the blue coat and back to the client, the bluecoat told the client the scale factor was zero, so it stripped it. I’m thinking scaling is turned off on the bluecoats or it’s a bug..

Example:

Host A / Window scale 4 > Bluecoat / Strips windows scale 4 makes it 0 > Server B = sees client window scale 0 but sends its own scale factor of 7

Server B / Window scale 7 > Bluecoat / Strips window scale 7 makes it 0 > Host A = sees server window scale 0 but sends its own scale factor of 4

So Host a sent window scale of 4, blue coat stripped it and made it 0, when server get the packet with the window scale its now 0 instead of 4. Same thing with Server B, instead of Host A seeing Window scale of 7 it sees that it’s a window scale of 0.

So my question is.. Is Window scaling happening at all? One side believes its has a window scale factor of X and is telling the other end, but that end only sees 0. I see the calculated window size on the client end goes above 65k as the captures go on, but ofcourse the return traffic end doesnt go above 65k.

asked 15 Aug '12, 13:17

HCA1234's gravatar image

HCA1234
1112
accept rate: 0%

edited 15 Aug '12, 13:21

I actually looked at the other end a bit better and saw this.

What i said here is still correct : "I see the calculated window size on the client end goes above 65k as the captures go on, but ofcourse the return traffic end doesnt go above 65k."

But if i look at that window size as it comes across to the server..the window size is actually 65k or less, so before it leaves the proxy i.e the client will say my window size is above 65k such as 131920, but after the server gets it, the window size is 65k or less after the proxy sends it to the server.

So i'm quite sure Window scaling has been interrupted because of the proxy, and most likely its disabled on the proxy end. Thoughts?

(15 Aug '12, 14:23) HCA1234

You don't say what Bluecoat device you have, but yes, it sounds like window scaling is disabled on the Bluecoat proxy. I suggest you search the Bluecoat Knowledge Base for "window scale" or "rfc 1323". This link is for the Bluecoat ProxySG and it describes exactly what you're seeing: The Bluecoat device changing the window scale factor to 0 because window scaling is disabled. The article gives the commands for enabling and disabling window scaling, at least on the ProxySG, and it says that when window scaling is enabled, the ProxySG will use a scale factor of 6 by default.

permanent link

answered 15 Aug '12, 20:00

Jim%20Aragon's gravatar image

Jim Aragon
7.2k733118
accept rate: 24%

I find it strange that the window scaling option value is set to 0. That means both sides are not aware of the real receive buffer on the other side. Instead the BlueCoat should just remove the window scale option from the TCP header altogether. I would consider this a bug and would file it to BlueCoat support.

Are you able to share the captures of both sides of the BlueCoat on www.cloudshark.org? I'd like to see this peculiar behavior myself :-)

(15 Aug '12, 23:47) SYN-bit ♦♦

It's a waste of time to argue with Blue Coat support about RFC feature interpretation/implementation. I've done it a few times and never got anywhere. Perhaps their installed base is to big to make fundamental changes to the system, which allways carries the risk of breaking things that used to work in most environments.

In this special case, they will refuse start a discussion, as RFC 1323 states:

The value 'shift.cnt' may be zero offering to scale, while applying a scale factor of 1 to the receive window).

So, what they do is RFC compliant, but may cause problems with other devices.

(16 Aug '12, 01:18) Kurt Knochner ♦

Whether it is RFC compliant depends on the working of the BlueCoat. If it is an application layer proxy having it's own TCP buffers on both sides of the connection, than indeed it is RFC compliant (I was not fully awake when writing my last comment I guess). So if it is a ProxySG, then it is compliant.

When it is a non-buffering device that does this, it is not RFC compliant. I don't know what kind of BlueCoat device it is, I can imagine their trafficshaper to not buffer so that could be a problem.

(16 Aug '12, 01:32) SYN-bit ♦♦

I assume it is a ProxySG, as it is mentioned in the title of the question.

(16 Aug '12, 02:47) Kurt Knochner ♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×55
×41
×10
×9

question asked: 15 Aug '12, 13:17

question was seen: 7,508 times

last updated: 16 Aug '12, 02:47

p​o​w​e​r​e​d by O​S​Q​A