Bug 6773 - "tcpdump" writes out capture files others cannot read
"tcpdump" writes out capture files others cannot read
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: tcpdump (Show other bugs)
6.1
All Linux
high Severity high
: ---
: ---
Assigned To: Harald Hoyer
:
: 6718 7921 9243 19690 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-11-06 03:05 EST by Guy Harris
Modified: 2008-05-01 11:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-12-22 09:47:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Guy Harris 1999-11-06 03:05:01 EST
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.)
Comment 1 rodrigc 1999-11-13 11:24:59 EST
Tcpdump and libpcap are now being actively maintained at
http://www.tcpdump.org

Redhat may want to incorporate versions from this effort
in their distribution.
Comment 2 Jeff Johnson 1999-12-22 08:24:59 EST
*** Bug 6718 has been marked as a duplicate of this bug. ***
Comment 3 Jeff Johnson 1999-12-22 08:26:59 EST
*** Bug 7921 has been marked as a duplicate of this bug. ***
Comment 4 Jeff Johnson 1999-12-22 09:47:59 EST
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
release.
Comment 5 Jeff Johnson 2000-02-09 14:44:59 EST
*** Bug 9243 has been marked as a duplicate of this bug. ***
Comment 6 Daniel Senie 2000-02-09 14:57:59 EST
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
field.

Thanks.
Comment 7 Guy Harris 2000-02-09 18:38:59 EST
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 "ethereal-dev@zing.org".)

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.
Comment 8 Guy Harris 2000-02-09 18:40:59 EST
("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.)
Comment 9 Jeff Johnson 2000-10-25 12:34:26 EDT
*** Bug 19690 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.