Fixed bug with calculation of bytes in flight.
authorgrahamb <grahamb@f5534014-38df-0310-8fa8-9805f1628bb7>
Wed, 8 Feb 2012 11:52:35 +0000 (11:52 +0000)
committergrahamb <grahamb@f5534014-38df-0310-8fa8-9805f1628bb7>
Wed, 8 Feb 2012 11:52:35 +0000 (11:52 +0000)
commit2349c3abe4a1de11bce2226c9b7e315ecfb177fe
tree6f11c0cc3344b7317363c1f99db6abc4540c77b7
parent3e9753eea20b04bc02197474ba4fc512fa6d2a4c
Fixed bug with calculation of bytes in flight.

A corner case was posted to the Q&A site showing incorrect calculation of bytes in flight (http://ask.wireshark.org/questions/8843/bytes-in-flight-problems-with-retransmissions)

The capture in question has a tcp segment (frame 12) that is a retransmission of unacked earlier data (frames 4, 9, 10) and also contains some new data.  Eventually an ACK is received for the earlier segments (frame 16) but the code doesn't remove frame 12 from the linked list of unacked segments because it extends past the received ACK.  When more data is received in frame 17, the bytes in flight is calculated from the start of frame 12 rather than from the unacked portion of it, leading to a larger incorrect value.

The change simply updates the starting sequence number in the unacked segment list for any partially acked segment to be the start of unacked data.

The capture in question now shows correct information for bytes in flight, and hopefully the nature of the change won't cause issues elsewhere.

git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@40929 f5534014-38df-0310-8fa8-9805f1628bb7
epan/dissectors/packet-tcp.c