Hi.
I recently stumbled upon the following in Ethereal, when viewing the total
packet lengths.
In a recent tracefile I loaded in ethereal, I noticed what appeared to be
total packet lengths (not to confuse with the tcp segment size) that seemed
to exceed the maximum MTU size for the interface on which the capture was
taken. Although at first I thought that I was dealing with yet another buggy
TCP/IP or ethernet-driver implementation here, upon further investigation it
appears to me that, for some reason unknown to me, ethereal/tethereal
incorrectly counts the 'total packet length' (in certain cases ?).
I've tried to verify this behaviour by loading the attached file
'incorrect-packet-length.single-packet.trace' in both ethereal/tethereal and
in tcpdump (using the '-r' option). Tcpdump then correctly states the total
packet size as 'len 1500', while (t)ethereal incorrectly reports the total
packet size as '1514'.
Or am I just doing something really wrong here ?
I've attached a gzip'ed tarfile that demonstrates what I'm talking about,
which includes the following files:
- incorrect-packet-length.single-packet.trace
Which is a single packet that exhibits the behaviour, in standard libpcap
format.
- incorrect-packet-length.single-packet.tcpdump.txt
Which is the ASCII text representation of 'tcpdump -r' of the single packet
tracefile.
- incorrect-packet-length.single-packet.tethereal.txt
Which is the ASCII text representation of 'tethereal -r' of the single
packet tracefile.
- incorrect-packet-length.full-trace.trace
Which is the complete tracefile of which the 'single-packet' file is an
excerpt. Please note that if you whish to load the 'full-trace' file, you
will probably need a recent development snapshot of ethereal, as ethereal
0.9.7 and earlier will likely crash on the RPC/NFS traffic types included in
the trace. ( This is already fixed in the latest snapshots.) The single
packet should load fine in any version.
Sincerely,
J.Smith
Attachment:
incorrect-packet-length.tar.gz
Description: GNU Zip compressed data
