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: Sun, 2 Jan 2011 02:19:26 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5541

--- Comment #3 from Sake <sake@xxxxxxxxxx> 2011-01-02 02:19:23 PST ---
(In reply to comment #1)
> (In reply to comment #0)
> 
> > Shouldn't the two window size fields be identified by different field names so
> > that they can be filtered on or added to custom columns independently? This
> > would also correct the sorting issue.
> 
> You can use the "field occurrence" setting when adding custom columns to make
> it show only the first (always the actual value from packet) or second (always
> the scaled value or blank if it can't be computed) by changing field occurence
> from "0" (all occurrences) to "1" or "2".

Even though you can now display a specific occurrence, you can not filter on it
(yet). Using the same field name for things that are actually different
entities is something I'm not in favor of. 

Also, when there has been some tunneling and multiple TCP layers are present,
one with and one without scaling, you are not in control anymore with the
occurrence index to show exactly what you need.

I would vote for three field names:

- tcp.window_size : contains the scaled window_size if scaling was enabled in
the 3-way-handshake and window_size from the packet if the 3WHS was not seen or
scaling was not negotiated
- tcp.window_size_value : always contains the window_size from the packet
- tcp.window_size_scalefactor : contains the calculated scale_factor from the
3WHS (can be different for both flows of the connection)

The last field could contain the following special values to indicate the
validity of the tcp.window_size field:

- value -1 : the 3WHS was missing, so actual window_size is unknown
- value 0  : no scaling negotiated, so using the real value
- value 1 and higher powers of 2 : scaling has been negotiated and the
window_size has been calculated accordingly

This way, you know that when tcp.window_size_scalefactor is anything but -1,
the tcp.window_size field is showing the actual value used by the involved
systems.

Just my $0.02

PS  Hmmm.. one nice side-effect of this is that you can now extract all
sessions that have their 3WHS in the tracefile by using
"tcp.window_size_scalefactor!=-1" :-)

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