Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 1847] New: TCP Duplicate ACK's not being marked as such in "Expert Info".

[bugzilla-daemon@xxxxxxxxxxxxx]

http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1847

           Summary: TCP Duplicate ACK's not being marked as such in "Expert
                    Info".
           Product: Wireshark
           Version: SVN
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: High
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: christopher.maynard@xxxxxxxxx


Build Information:
SVN 22858
--
So I’ve been using the “Expert Info” a lot more lately and yesterday I
was helping to troubleshoot some network performance problems when I was
analyzing a trace and noticed a problem with Wireshark’s TCP SEQ/ACK analysis
feature.

During a TCP transfer of data, if the receiving side misses a TCP segment, it
will send a "duplicate ACK" to the sender so that the sender will resend that
segment.  If the sender is streaming a bunch of data though, it might not
resend that segment immediately.  So while streaming new data, after every
segment is received, the receiver will send another "duplicate ACK".  In the
"Expert Info", these show up as "Duplicate ACK (#X)".  Everything is fine as
long as the receiver isn't also sending back data itself, in which case the
receiver's "duplicate ACK" packet might also have its PSH flag set with data
accompanying it for the sender.  When that occurs, the "Duplicate ACK" is no
longer marked as such.

I suspect that the algorithm that marks the packet as a "Duplicate ACK" is
taking into account both the sequence number and the ACK number when
determining a "Duplicate ACK" status, but I don't think this is correct at all.
 The packet is still a "Duplicate ACK", regardless of whether or not there is
also data flowing in the other direction at the same time.  By taking into
account both the SEQ# and ACK, it makes it very difficult to analyze the
"Expert Info" and figure out exactly how many "Duplicate ACK's" are occurring
before the missing segment is eventually resent.

My recommendation is to eliminate the seq # from the algorithm, and only use
the ACK # when determining a "Duplicate ACK" status.


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