https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5541
--- Comment #4 from Jim Aragon <Jim@xxxxxxxxxxxxxxxxx> 2011-01-02 10:48:56 PST ---
I think Sake has identified the crux of the matter. Using the same field name
for things that are actually different entities results in unwanted effects.
If I'm filtering on the window size in an attempt to identify instances where
the data transfer has stopped because the client is not emptying the TCP
receive buffer in a timely manner, a filter such as "tcp.window_size < 1460"
will see both instances of the tcp.window_size field and will show me packets
whose true (scaled) window size is actually larger than 1460 bytes but whose
window size value in the TCP header is less than 1460. This is clearly not what
I'm looking for in this circumstance.
In fact, I can now create a filter such as:
tcp.window_size < 1460 && tcp.window_size > 1460
In Wireshark 1.4.2, this is an impossible situation (absent multiple TCP
layers) and the filter will not show me any packets; in Wireshark
1.5.0-SVN-35322 it WILL show me packets. The filter is working correctly based
on the two occurrences of the field name, but it is not helpful in analyzing
network communications.
I like the idea of three different field names. In particular, I like the idea
of tcp.window_size containing the scaled window size if Wireshark is able to
calculate the scaled window size, and containing the window size value from the
packet if the three-way handshake was not seen.
This takes us back to the situation where Wireshark has a single field that
sorts properly and that contains Wireshark's best idea of the window size, even
though, due to a missing three-way handshake, we may not always know if the
window size should have been scaled.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.