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

Ethereal-users: [Ethereal-users] Bugs in TCP analysis? (was: Ethereal Statistics vs Summary)

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date: 11 Dec 2004 01:35:12 +0200
Gavin Newman wrote on Fri, 03 Dec 2004 16:53:33 +1030:

> The endpoint and conversation list packet and byte counts are far
> less than the values in the summary (after filtering), I've
> confirmed that the summary supplied values are correct by adding up
> the total IP packet lengths for every packet for the host.

I have noticed the same thing (using 0.10.7): At least the TCP conversation
byte counts are incorrect (too small).

If TDS in Gavin's case runs over TCP the following reasoning should
also apply to his case.

Taking into account that TCP might need retransmissions the question
really is what does a byte count mean? The number of bytes captured on
the interface or the payload in the TCP stream. These 2 numbers differ
by the size of the header information and by possible retransmissions
captured.

Assuming the Ethereal intends to calculate the payload, the result is
not just adding the contents of all segments. It has to do a full TCP
analysis in order to eliminate retransmission overhead from the
calculation.

And here comes the point: When analysing some traffic I had captured I
had big problems to understand Ethereal's analysis of retransmissions
and out-of-order segments.

So I started to google and found the following indications that TCP
analysis is indeed buggy:

http://www.ethereal.com/lists/ethereal-users/200404/msg00235.html
http://www.gustavus.edu/+max/courses/F2004/MCS-377/labs/lab2/

So does anybody know whether these bugs still exist in 0.10.7?

Is there a list of known bugs anywhere?

Regards,

Uwe

P.S. Thinking about the original problem a second time: Wouldn't it
be easier just to look at the last sequence counter to find out about
the number of bytes? Of course in order to find the number of packets
this wouldn't help.