Wireshark-bugs: [Wireshark-bugs] [Bug 4716] tcp dissector doesn't decode TCP segments of length
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4716
Chris Maynard <christopher.maynard@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #6590| |review_for_checkin?
Flag| |
--- Comment #2 from Chris Maynard <christopher.maynard@xxxxxxxxx> 2011-06-29 22:15:22 PDT ---
Created an attachment (id=6590)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=6590)
Initialize analysis windows to G_MAXUINT32 instead of 0. Display zero window
probe data.
This patch provides an alternative method for resolving this bug without having
to disable sequence number analysis. It does this by initializing the analysis
windows to the maximum value instead of the minimum value.
But I also noticed that if the packet was a zero window probe, the single byte
of data wasn't being displayed in the tree. The comments in the code indicated
that "zwp contain too little data (1 byte) so why bother", but I disagree. I
think Wireshark should display it even if it's only 1 byte.
The comment also indicates that TCP keepalives just contain "garbage" so don't
display that data either. I have left this part alone for now, but wonder if
it might be worth displaying that too? The 1 byte of data, if present,
*should* be garbage, but in theory could be used to transfer actual data.
Recently, a similar change was made for other TCP fields in r37721 (see
http://anonsvn.wireshark.org/viewvc?view=revision&revision=37721), so I wonder
if we should do the same here?
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
