Wireshark-bugs: [Wireshark-bugs] [Bug 1847] TCP Duplicate ACK's not being marked as such in "Exp
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1847
------- Comment #1 from christopher.maynard@xxxxxxxxx 2007-09-14 19:53 GMT -------
Created an attachment (id=926)
--> (http://bugs.wireshark.org/bugzilla/attachment.cgi?id=926&action=view)
Small capture file depicting the TCP ACK analysis problem.
Some analysis of the trace:
1) host 10.36.136.59 is streaming data to host 10.36.136.159, but 10.36.136.159
is also sending data to 10.36.136.59 at the same time.
2) At frame 15, 10.36.136.159 PSH's some data to 10.36.136.59 and also sends an
ACK (a.k.a., "next expected SEQ#)of 1448.
3) At frame 19, we notice our first "Dup ACK #1" for 1448 and also notice that
10.36.136.159 is not sending any data in the frame and its TCP PSH flag is not
set. The duplicate ACK occurs because 10.36.136.159 is expecting a SEQ# of
1448, and even though that segment does appear in the trace in frame 16, it
never makes it to its destination for whatever reason, but apparently frame 17
with SEQ# 2896 does get there, so the host has obviously missed the 1448 byte
segment in frame 16.
4) At frame 20, we notice that 10.36.136.59 does not yet notice the duplicate
ACK because it is still streaming data. In fact it won't notice it until much
farther down the trace (frame 81).
5) Continuing to frame 41, we notice the last "Dup ACK #12" in this series,
which means we should expect that the missing segment is next. WRONG!
6) At frame 43, 10.36.136.159 sends more data to the other host, and its PSH
flag is set.
7) At frame 44, 10.36.136.159 sends another duplicate ACK, but this time, it's
marked - incorrectly I believe - as "Dup ACK #1", rather than "Dup ACK #13" ...
or actually "Dup ACK #14" with frame 43 being marked as "Dup ACK #13" since it
too contains the same ACK 1448 as before.
8) In fact, here we notice that all frames from 10.36.136.159 starting with
frame 19 through frame 79 have the same TCP ACK#, namely 1448, so they should
all contain a "Dup ACK #X" status, and they should be incrementing from 1
continuously to 32, rather than being reset back to 1 after the PSH/ACK in
frame 43. So, instead of seeing 2 "Dup ACK" sequences, the 1st from frames
19-41 of 12 "Dup ACK's" & the 2nd from frames 44-78 of 18 "Dup ACK's", we
should see only one sequence from frames 19-79 of 32 "Dup ACK's". Basically
host 10.36.136.159 has been trying to get host 10.36.136.59 to resend the
missing segment starting at offset 1448 for that long.
Anyway, it seems that the PSH flag (and possibly its own seq # changing as a
result) incorrectly causes the "Dup ACK" analysis to reset and it shouldn't.
That implies that the host got its missing segment somewhere between frames 41
and 44, but it didn't.
BTW: You have to go all the way to frame 81 to finally see the retransmission
of the missed segment.
--
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.
