https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7703
Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jeff.morriss.ws@xxxxxxxxx
--- Comment #2 from Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> 2012-09-14 11:13:42 PDT ---
Hmm. It seems that Wireshark is being smarter than just subtracting the
current sequence number from the last ACK. In particular what it is doing is
adding up the sequence numbers of the unacknowledged messages that *Wireshark
has seen*. The last bit is important because, as you can see from TCP's
warning on frame 47, a bunch of packets weren't captured/seen (352920 bytes
worth). The "last ack" (frame 58) is acking a TCP segment that's not even in
the capture file (it's prior to the first frame).
IOW Wireshark is calculating the bytes in flight (in this direction) by adding
up the size of these segments:
Frame:54 Seq:3592761289 Nextseq:3592762001
Frame:53 Seq:3592759829 Nextseq:3592761289
Frame:52 Seq:3592758369 Nextseq:3592759829
Frame:51 Seq:3592756909 Nextseq:3592758369
Frame:50 Seq:3592755449 Nextseq:3592756909
Frame:49 Seq:3592753989 Nextseq:3592755449
Frame:48 Seq:3592752529 Nextseq:3592753989
Frame:47 Seq:3592751069 Nextseq:3592752529
Frame:6 Seq:3592406689 Nextseq:3592408149
Frame:5 Seq:3592405229 Nextseq:3592406689
Frame:4 Seq:3592403769 Nextseq:3592405229
Frame:3 Seq:3592402309 Nextseq:3592403769
Frame:2 Seq:3592400849 Nextseq:3592402309
(since they are all the segments Wireshark has seen and they are all
unacknowledged.)
It's not immediately obvious to me why Wireshark does it this way, but it does
look fairly intentional (well, at least this method certainly seems harder than
looking at the last ACK and subtracting!), so I'll leave this bug as-is for now
in case someone with more TCP knowledge comes along.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.