It appears that Red Hat Linux 6.1 picked up some patches to
"libpcap" from Alexey Kuznetsov, which change the format of
the per-packet header in capture files.
Unfortunately, it also appears that you may have picked up
an older version of that patch, which doesn't change the
magic number of the capture file; this means that "tcpdump",
and other programs that use "libpcap", will write out
capture files that are unreadable by programs not using the
modified "libpcap", such as "tcpdump" on any system that
doesn't have that patch, or Ethereal.
At least one user of Ethereal has sent mail to the
"ethereal-users" mailing list indicating that Ethereal
cannot read a capture file written with "tcpdump" on a Red
Hat 6.1 system.
Please either pick up a later version of Alexey's patch, or,
at least, change the magic number, in capture files that
have the "ifindex", "protocol", and "pkt_type" fields in the
"struct pcap_pkthdr" structure, to 0xa1b2cd34, that being
the magic number that Alexey uses for his modified capture
file format in later patches.
Please also provide this as an update, so that, if an
Ethereal user has this problem, we can tell them to get an
update from the Red Hat Web site. (I will be adding support
for Alexey's modified capture file format to Ethereal soon.)
Tcpdump and libpcap are now being actively maintained at
Redhat may want to incorporate versions from this effort
in their distribution.
*** Bug 6718 has been marked as a duplicate of this bug. ***
*** Bug 7921 has been marked as a duplicate of this bug. ***
Fixed (by upgrading to latest ANK snapshot) in tcpdump-3.4-17.
Meanwhile, the tcpdump.org offering seems not quite ready for prime time,
although I'll probably upgrade to that version if/when they have a stable
*** Bug 9243 has been marked as a duplicate of this bug. ***
Sorry about entering the dupe. I did a quick search, but missed it.
Will a patched RPM be coming out soon? The comments from December 22nd indicated
this was being fixed. This problem is causing some significant issues in the
Note that a later version of the Kuznetzov code won't necessarily fix the
problem with Etherpeek; the later version of the code merely causes the
non-standard capture file format to have a different magic number, so that code
that is aware of the non-standard format can distinguish between files in the
standard format and files in the new format simply by looking at the magic
number (rather than, say, going through the contortions that Ethereal's
capture-file-reading library does).
If Etherpeek doesn't know about the Kuznetzov changes, it won't be able to read
capture files from future versions of 6.1. (However, the capture-file-reading
library in the latest version of Ethereal can also write capture files in either
standard, Red Hat 6.1, or Kuznetzov-with-different-magic-number format, and the
latest version of Ethereal also comes with a "editcap" program that can be used
to translate capture files from one format to another, so it should be possible
to turn RH 6.1 or Kuznetzov-with-a-different-magic-number capture files into
standard libpcap files - if that doesn't work, it's a bug, and should be
reported to "email@example.com".)
Note also that the current tcpdump.org version of libpcap can neither read nor
write Red Hat 6.1 or Kuznetzov-with-a-different-magic-number capture files.
("Future versions of 6.1" in my previous comment should read "future versions of
Red Hat", assuming Red Hat Linux continues to use the Kuznetzov code, and to
write files in the modified format.)
*** Bug 19690 has been marked as a duplicate of this bug. ***