Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 3311] New: tcp.analysis.acks_frame and tcp.analysis.ack_rtt is not reliable

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3311

           Summary: tcp.analysis.acks_frame and tcp.analysis.ack_rtt is not
                    reliable
           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 #2821|                            |review_for_checkin?
               Flag|                            |


Created an attachment (id=2821)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2821)
DIFF file containing my patch

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
--
The tcp.analysis.ack_rtt and tcp.analysis.acks_frame SEQ analysis information
is only populated in a fraction of valid TCP acknowledgements.  In some
captures of TCP bulk data transfers I have noticed less than 2% of viable ACKs
contain this information.

After reviewing the code it looks like this information will only be populated
if the ACK happens to acknowledge the most recent segment sent by the TCP peer.
 In a bulk data transfer, where data is streaming, this will almost never be
the case.

I have attached a patch for review.  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.