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.
