On Fri, Nov 20, 2009 at 12:15:55PM -0500, Stephen Noonan wrote:
>
> 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.
This sounds like there is a problem in the wireshark code that
reassembles the data. As wireshark might not see all packets (in
contrary to the endpoints of the tcp conversation), it can be quite
difficult to determine is data was really missing or just out-of-order,
so I guess there are some situations that are not handled correctly. To
solve this, the capture file does need to be available. If there is any
way you could share the capture file with just me, than I could have a
look at it (I was the one who wrote the "XXX bytes missing" part of
Follow TCP stream in the first place). Or else, it you could share the
file after you used editcap with a snap length to just provide up to the
TCP layer, skipping the payload, then I could try to reproduce a
representative file to work with.
> 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.
Could you check whether all packets have indeed be captured? There can
be a difference between what the endpoints have seen and what wireshark
is seeing.
> 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.
You just did ;-)
Cheers,
Sake
