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

1 files changed, 5 insertions, 0 deletions

diff --git a/epan/dissectors/packet-tcp.c b/epan/dissectors/packet-tcp.c
index f8380d9da8..c081035e15 100644
--- a/epan/dissectors/packet-tcp.c
+++ b/epan/dissectors/packet-tcp.c
@@ -1149,6 +1149,11 @@ finished_checking_retransmission_type:
             tcpd->ta->frame_acked=ual->frame;
             nstime_delta(&tcpd->ta->ts, &pinfo->fd->abs_ts, &ual->ts);
         }
+        /* If this acknowledges part of the segment, adjust the segment info for the acked part */
+        else if (GT_SEQ(ack, ual->seq) && LE_SEQ(ack, ual->nextseq)) {
+            ual->seq = ack;
+            continue;
+        }
         /* If this acknowledges a segment prior to this one, leave this segment alone and move on */
         else if (GT_SEQ(ual->nextseq,ack)){
             prevual = ual;