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 showing 5 of 8 show 3 more comments |
2 Answers:
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. answered 31 Jan '12, 03:59  SYN-bit ♦♦ 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? answered 02 Feb '12, 02:10 dranigl |
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.
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!
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?
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
could you post just those few packets (maybe sliced due to privacy) on cloudshark or provide a screenshot?
Fyi ... this is now being tracked as enhancement bug 6683.
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?
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