https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5548
Chris Maynard <christopher.maynard@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Chris Maynard <christopher.maynard@xxxxxxxxx> 2011-01-05 07:17:17 PST ---
It isn't out of order. It's an ACK to the data sent in frame 3.
In this capture file, let A = 10.147.1.19 and B = 10.2.7.187. Then:
Frame 1: A sends 13 bytes to B: seq=1, ack=1, len=13
(next expected seq=14, as can be seen later on in frame 9)
Frame 2: B ACK's the 13 bytes from A: seq=20320, ack=14, len=0
Frames 3-8: B sends a combined 8709 bytes to A: seq=27585, ack=14, len=1444
(next expected seq=29029, as can be seen later on in frame 11)
Frame 9: A sends 15 bytes to B: seq=14, ack=1, len=15
(next expected seq=29, as can be seen later on in frame 12)
Frame 10: A ACK's the 1460 bytes sent from B in frame 3: seq=1, ack=1461,
len=0
... and so forth.
To me there does appear to be a bug here in frame 10, but it's not with
Wireshark. The bug appears to be with the sender as the seq # should have been
14, not 1.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.