Bug 66942

Created attachment 61465 [details]
tcpdump packet capture

did you record the file with the same tcpdump (architecture, machine)???

Yep, recorded on the same machine (1.7 ghz athlon) which won't play it back

hmm, strange... does every dumpfile fail on your machine?

Nope.  I just made one (tcpdump -i eth0 -w foo) and played it back (tcpdump -r
foo) w/o problems -- it's specific to that capture.

(kaboom -- login's not working for me right now)

Seems like some bytes (length of packets captured) in the dump are really wired
(off by 8). Are you sure the hardware is correct? HD and RAM are ok?

AFAIK, yes.  That machine's been running since December 2001 as a small
department (ftp / web / nat / kickstart / etc.) server w/o any problems other
than this one.  I ran memtest86 over the weekend when I put it together, and it
passed then....

Is this just Red Hat bug 6773 returned from the dead?

That bug was apparently fixed in Red Hat 6.2, but perhaps libpcap was re-broken
in 7.3.  If not, then perhaps that version of tcpdump was either statically
linked with a broken version of libpcap, or was dynamically linked with libpcap
and is finding a broken shared-library version of libpcap on the machine in
question.

Ethereal can read the file because it has some hacks^H^H^H^H^Hheuristics I put
into it to cope with various broken versions of libpcap that write out files
with a magic number that doesn't match the per-packet header.  Libpcap doesn't
have those heuristics, as the Ethereal version of them relies on being able to
seek backwards in the capture file, and libpcap is supposed to support reading
from pipes so we'd have to put some buffering in to allow those hacks to be done
when reading from a pipe.

(Ethereal also notes that the file is a "Red Hat Linux 6.1 libpcap" file, if you
select "Summary" from the "Tools" menu.)

but why should the _same_ tcpdump suddenly produce dump files with changed headers??

Well, the additional fields in the per-record header are zero - including the
protocol value, so it's probably not something as simple as bug 6773.

However, the file is definitely not a valid standard tcpdump file, so the bug is
presumably somewhere in the version of libpcap or tcpdump on the system on which
it was run, or in the driver or networking stack of the kernel of the machine on
which it was run, unless it's a hardware problem.  (I.e., it's not a problem
with standard libpcap or tcpdump, unless there's some recent kernel
"improvement" that requires a change to libpcap.)

Was the bad capture made with the exact same tcpdump binary that the good
capture was made with?  Or did the user's search path somehow manage to find a
different version of tcpdump when he/she did the capture that gave the bad
tcpdump?

My mistake -- I thought the system had been upgraded to 7.3, but it's actually 7.2.

tcpdump version is

tcpdump-3.6.2-10.7x

libpcap version is

libpcap-0.6.2-10.7x

Capture and playback were definitely w/ the same libs and binary;
/usr/lib/libpcap* and /usr/sbin/tcpdump are the only copies of each on the system.

So far, I've only seen this problem when I capture DHCP on that system.  The
DHCP server on it is pushing etherboot, so it does have the bizarre etherboot
menus.  Beyond that, I can't think of anything unusual about the traffic going
through the box.

hmm, not much I will do... this is the only report I have on this strange bug.