This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Hello,

I've got a question about the value of bytes in flight. I am using Wireshark 1.6.2 and have a trace where the bytes in flight have an incorrect value.

So my first question is: Is it true that bytes in flight are calculated with [NextSequenceNumber] - [ACK of the packet before] ?

Secondly i've read that there was a bug concerning this bytes in flight has been fixed with version 1.4.1. So my question is, if i have to make a new trace with version 1.6.2 to get a correct error? Or is the value recalculated when I open a .pcap file?

Thanks for your help! Mario

asked 30 Jan '12, 00:22

dranigl's gravatar image

dranigl
14668
accept rate: 0%

Can you provide a bit more information? Bytes in Flight does have problems when SACK is used as the ACKed Left Edge/Right Edge data is not removed from the Bytes in Flight value.

(30 Jan '12, 00:35) lchappell ♦

Thank you for your answer!

So I've got the trace where the problem occurs, SACK is not used. An example of my trace is: PACKET 1 has the ACKNOWLEDGE-Number (AN) 1359412875 PACKET 2 has the Next-Sequence-Number (NSN) 1359413411 When I calculate the Bytes in Flight value manually I get: NSN - AN = 536 = Bytes in flight But Wireshark 1.6.2 calculates 924!

What could be the cause? By the way this is not a live trace, it's a .pcap file. Does that make a difference?

Thank you!

(30 Jan '12, 03:22) dranigl

where does wireshark "calculate" 924 bytes in flight - did you add a custom column and did you check for which side of the TCP session (A->B or B->A) you looked up the sequence and ack numbers?

(30 Jan '12, 03:56) Landi

I looked up: A->B: The ACK number B->A: The seqence number (This is the following packet) And the value of Bytes in flight in the second packet (where i looked up the sequence number) is 924

(30 Jan '12, 04:17) dranigl

could you post just those few packets (maybe sliced due to privacy) on cloudshark or provide a screenshot?

(30 Jan '12, 05:33) Landi

Fyi ... this is now being tracked as enhancement bug 6683.

(30 Jan '12, 05:42) cmaynard ♦♦

alt textalt text

If the display of the screenshots does not function, here are the links: http://www.bilder-space.de/show_img.php?img=267c71-1328009257.jpg&size=original http://www.bilder-space.de/show_img.php?img=5eacd2-1328009167.jpg&size=original

So this are the two packets. The Bytes in flight of the second is 924, but it should be 536. Is that true?

(31 Jan '12, 03:28) dranigl

Not neccessarily, because in 11696 there is no ACK for 11694 (look at ACKnumber), so there might be 536 bytes in flight from frame 11696 plus some bytes from previous frame(s), where wireshark did not yet see dual-side ACKs to really make sure everyone has got the data. But to really tell, I'd need +/- 2-3 packets to really see what was going on. Check if the last frame(s) before 11694 had 388 bytes of data

(31 Jan '12, 07:52) Landi
showing 5 of 8 show 3 more comments

Your calculation is correct, what might be the cause is that the ACK in frame 11694 is not taken into account because it also carries data. If that's the case, that should be fixed. Could you extract this TCP stream from the capture file (filter: tcp.stream==82) and post that on https://bugs.wireshark.org with a reference to this question. It can then be picked up, fixed and tested.

permanent link

answered 31 Jan '12, 03:59

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

edited 31 Jan '12, 03:59

1

Sorry, but I don't see that your way - if you take a close look at frame 11696, you see that the ACK number is telling that the sender did not yet process the frame 11694, because ACK is still on 18919. So the stack did not acknowledge the other sides last segment in which the data sent before was acknowledged. So it could perfectly be fine, that wireshark still says that there is unackknowledged data from previous frames

(31 Jan '12, 07:49) Landi
1

Good point. That means the question is from which standpoint does Wireshark need to calculate the bytes-inflight? From the capture point or the server viewpoint. I assumed Wireshark would calculate it from the capture viewpoint, but indeed if you calculate it from the senders viewpoint, there is more unacknowledged data which could very well be the missing 388 bytes :-)

(31 Jan '12, 10:07) SYN-bit ♦♦

Thank you for your answers! I'will check that

Could it be a reason too, that wireshark has problems to calculate the bytes in flight value when retransmissions occur?

permanent link

answered 02 Feb '12, 02:10

dranigl's gravatar image

dranigl
14668
accept rate: 0%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×752
×32
×2

question asked: 30 Jan '12, 00:22

question was seen: 15,356 times

last updated: 02 Feb '12, 02:10

p​o​w​e​r​e​d by O​S​Q​A