Wireshark-bugs: [Wireshark-bugs] [Bug 2221] TCP Retransmit packets identified incorrectly
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Tue, 9 Nov 2010 09:21:49 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2221

Chris Maynard <christopher.maynard@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #1 from Chris Maynard <christopher.maynard@xxxxxxxxx> 2010-11-09 09:21:40 PST ---
Here's the situation (only relevant frames and info shown here):
16) 64.14.35.122 -> 209.140.121.173 Seq=485, Len=44 <= Next expected Seq#=529
17) 209.140.121.173 -> 64.14.35.122 Ack=462         <= So far, so good
18) 209.140.121.173 -> 64.14.35.122 Ack=529         <= So far, so good
19) 209.140.121.173 -> 64.14.35.122 Ack=529 (+PSH)  <= So far, so good
20) 64.14.35.122 -> 209.140.121.173 Seq=758, Len=0 [Previous Segment lost]
21) 209.140.121.173 -> 64.14.35.122 Ack=529 (+PSH)  <= Should be Dup ACK 19#1
24) 209.140.121.173 -> 64.14.35.122 Ack=529 TCP Dup ACK 21#2
                                            <= Should be Dup ACK 19#2

Notice that 64.14.35.122 sent its first ACK=529 in frame 18, although its last
ACK before traffic is seen from 64.14.35.122 with an ACK of 529 came in frame
19.  Frame 21 is seen after frame 20, which indicates that there was a missing
segment, thus frame 21 is actually the 1st duplicate ACK for the ACK in frame
19.

This bug seems to be just a duplicate of bug 1847, so marking it as such.

*** This bug has been marked as a duplicate of bug 1847 ***

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