Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 5541] Custom Window Size Column Shows Two Values and Doesn

Date: Mon, 3 Jan 2011 12:30:23 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5541

--- Comment #6 from Sake <sake@xxxxxxxxxx> 2011-01-03 12:30:22 PST ---
(In reply to comment #5)
> The problem I had with the old implementation was that Wireshark showed the
> scaled value without even putting the [Generated item] brackets around it, and
> did not show the packet's actual value, leading to extra work and possible
> confusion when trying to figure out the packet's actual value.

Indeed, it needed an update :-)

> Each of these is filterable, with the ones specific to the window size option
> being tcp.options.wscale.shift and tcp.options.wscale.multiplier.

These are really nice, but only available in the SYN-packets where the options
are present...

> How about something like this:
> 
> ...with scaling:
> 
>     Window size value: 258                       <--- tcp.window_size_value
>     [Calculated window size: 66048 (scaled)]     <--- tcp.window_size
> 
> ...without scaling:
> 
>     Window size value: 258                       <--- tcp.window_size_value
>     [Calculated window size: 258]                <--- tcp.window_size

Sounds good to me!

The only thing I'm missing is being able to interpret the window_size when it
is the same as the size_value. This can be caused by three things:

1) At least one of the endpoints did not support scaling and therefore scaling
is not used

2) The particular flow uses a scaling factor of 1

3) The 3WHS was not seen by wireshark and therefore it defaults to using the
window_size_value as its best bet.

For 1) and 2) the tcp.window_size show the correct value used by the two
endpoints. For 3) the value might not represent the actual value being used by
the endpoints. It would be nice to be able to distinguish this situation from
the other two.

This can be either done by changing the value itself (making it 0, -1 or
-window_size_value), but that would confuse people I'm sure... So having a
third field that reveals this info would be nice to have.

Stephen, if you do the proposed extra field for tcp.window_size_value, I'll add
the code for the extra tcp.window_size_scalefactor (unless someone really
objects to it).

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.