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

Bytes in flight - Problems with retransmissions?

Hey

I've read that wireshark had problems with the bytes in flight value, when retransmissions occur. This bug was fixed in version 1.4.1. Well, but I've got a trace, where the values does not seem to bee correct. The link to this .pcap file is: http://uploading.com/files/ce18d69a/bytes_in_flight_problem.pcap/
In this trace the calculation of bytes in flight is correct until frame 17, where it is 1714. I calculated manually the bytes in flight values of this trace and my result would be 1460 for frame 17! It seems that the retransmission is not taken into account when it is acknowledged. After this frame the calculation of Wireshark is correct again. So does wireshark 1.6.5 has problems too with this calculation when retransmissions occur?

Thanks for your answer! Best regards, mario

retransmissions tcp-bytes-in-flight

asked 06 Feb '12, 04:59

dranigl
14●6●6●8
accept rate: 0%

It appears that the hosting service you have used for your capture is now demanding payment before I can download it.

Putting your capture on somewhere more accessible, e.g. CloudShark would be more helpful.

(06 Feb '12, 07:07) grahamb ♦

I have now uploaded the capture file to cloudshark, the link is

https://www.cloudshark.org/captures/01e4d4ac94cf

(06 Feb '12, 23:30) dranigl

From what I see 1.6.5 has the same issue. I looked at the trace at the whole flow and cannot find a reason for that.

I could imagine, that wireshark has problems with that trace, because the way this 10.114.x.y machine sends out acknowledgements is totally different to every other TCP implementation I know especially by sending unneeded ACKs without any more incoming data to acknowledge. Maybe the bytes_in_flight algorithm simply does not expect such behaviour

(07 Feb '12, 00:53) Landi

Thank you for the answer. So do you think that this is a bug which should be posted at bugs.wireshark.org?

(07 Feb '12, 01:07) dranigl

One Answer:

This is a bug. The retransmitted data in frame 12 spans more than the original transmitted segments (frames 4, 9 & 10 plus new data) and the ACK in frame 16 is only for part of the data in frame 12. The code that calculates the bytes in flight uses the whole of frame 12 in calculating the value, so in frame 17 is doing so from the sequence number 1359412875 up to the 'next' sequence number for frame 17 which is 1359414589 giving the displayed value (4589 - 2875 = 1714).

The code works by keeping a linked list of unacked segments, but doesn't handle partially acked segments as in frame 12.

Edit: Hopefully this is fixed in any rev later than 40929.

answered 07 Feb '12, 16:34

grahamb ♦
19.8k●3●30●206
accept rate: 22%

edited 08 Feb '12, 04:50