Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: [Wireshark-users] '[xxx bytes missing in capture file]'

From: "Stephen Noonan" <snoonan@xxxxxxxxx>
Date: Fri, 20 Nov 2009 12:15:55 -0500
I have some concerns about the '[xxx bytes missing in capture file]' message
that I getting in my Follow TCP Stream output.

I am doing some stress testing on an embedded product we are developing by
applying impairments to the network using a third party package (PacketStorm
Tornado). Our product must work under extremely adverse conditions, allowing
for the maximum number of dropped packets feasible, multi-second RTTs, bit
errors, etc.

We are using Wireshark to capture everything in order to analyze failures
and the Follow TCP Stream feature has been extremely valuable in doing so,
however I keep seeing the message in question appearing, many times with
negative values. According to
http://www.wireshark.org/lists/wireshark-users/200805/msg00098.html there
were some bugs that were ostensibly fixed, but that message is from 2008.
The version of Wireshark used to capture was 1.2.3 (Win32).

Currently we are testing with 5% dropped packets which causes quite a bit of
TCP Retransmissions. It is only under this type of condition (or worse) that
Wireshark reports missing bytes in the stream, and it may take hours of
capturing before it appears. Unfortunately I cannot share any actual capture
data due to its sensitive nature.

Our transmissions are only 36 bytes per poll, with a 36 byte response, about
every 3 seconds. I have seen the number of lost bytes range from 13 to
14000000 (14 MB), which, for the higher numbers at least, it is difficult to
believe the dedicated PC we have somehow could not keep up with the data and
miss that large of an amount. After something like the 14 MB message only
one direction of the TCP Stream is displayed. I know the other direction -
responses - must actually have existed, at least at some points, due to the
nature of the data in the transmissions.
 
I guess I'm wondering if Wireshark's view TCP Stream code has been tested to
reconstruct the stream at the level of retransmissions that are occurring in
my test setup.

Any comments on the subject would be welcome. I am fairly new at using
Wireshark so it is possible I am doing something wrong.

Thanks,

Steve