Wireshark-bugs: [Wireshark-bugs] [Bug 3312] New: TCP bytes_in_flight issues
Date: Sat, 7 Mar 2009 06:10:01 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3312

           Summary: TCP bytes_in_flight issues
           Product: Wireshark
           Version: SVN
          Platform: PC
        OS/Version: Windows Vista
            Status: NEW
          Severity: Normal
          Priority: Medium
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: chcosta75@xxxxxxxxxxx



Chris Costa <chcosta75@xxxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2824|                            |review_for_checkin?
               Flag|                            |


Created an attachment (id=2824)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2824)
Patch containing my fixes for these bytes_in_flight issues.

Build Information:
TShark 1.1.3-TEST (SVN Rev unknown)

Copyright 1998-2009 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled with GLib 2.18.4, with WinPcap (version unknown), with libz 1.2.3,
without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8, with c-ares
1.6.0,
with Lua 5.1, with GnuTLS 2.6.4, with Gcrypt 1.4.4, with MIT Kerberos, with
GeoIP.

Running on Windows Vista Service Pack 1, build 6001, with WinPcap version 4.0.2
(packet.dll version 4.0.0.1040), based on libpcap version 0.9.5, GnuTLS 2.6.4,
Gcrypt 1.4.4.

Built using Microsoft Visual C++ 9.0 build 30729
--
I've noticed a few minor issues with the new TCP tcp.analysis.bytes_in_flight
information.

1)  At the start of a traffic capture, if a TCP transfer was already underway,
the segments at the beginning of the capture show a very low bytes_in_flight
measurement, even if many more bytes were actually in flight

2)  If there is a prolonged period of time where frames are missing from the
traffic capture, the bytes_in_flight measurement will show as too high in the
segments immediately following that event.

3)  In a general sense, I'm noticing a lot of examples where the
bytes_in_flight measurement is off (too high) by up to a couple segments worth
of data.

I'm attaching a patch containing my fixes for these minor issues.  This patch
has been fuzz tested.


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