Bug 7921 - libpcap and thus tcpdump incompatible with rest of universe
libpcap and thus tcpdump incompatible with rest of universe
Status: CLOSED DUPLICATE of bug 6773
Product: Red Hat Linux
Classification: Retired
Component: tcpdump (Show other bugs)
6.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-12-21 02:56 EST by genescott
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-12-22 08:26:25 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 genescott 1999-12-21 02:56:59 EST
Someone apparently added some #ifdef linux crap to libpcap's pcap.h making
it impossible to use traces generated with it (tcpdump -w or -r for
example) on different systems.  Getting the real libpcap (same version)
and compiling it works fine, as it's missing the #ifdef linux stuff.
Tcpdump is affected as it's statically linked to it, if there's anything
else statically linked to it, those are affected too.

This is rather important as network analysis folk pass around pcap files
quite regularly and expect them to be usable.

Also, with bugzilla, libpcap shows up as a component in query but not in
submitting a bug report?  How do I specify libpcap?  I can't deselect the
component in the list and typing in libpcap below complains I selected two
things.  Anyway, this should be a libpcap bug as tcpdump is just affected
by it.
Comment 1 Jeff Johnson 1999-12-22 08:26:59 EST
*** This bug has been marked as a duplicate of 6773 ***
Comment 2 Guy Harris 1999-12-23 05:25:59 EST
The added stuff came from a patch from Alexey Kuznetzov; see

	http://ftp.sunet.se/pub/os/Linux/ip-routing/lbl-tools/

Red Hat apparently picked up the libpcap-0.4-ss990417 version of the patch,
which changed the format of the capture file without changing the magic number,
causing it to be unable to read tcpdump files from systems that didn't have that
patch applied and causing it to write capture files unreadable on systems that
didn't have that patch applied.

Later versions of the patch, such as the ss991029 version, change the magic
number; they can read capture files from unpatched systems (although not from
systems such as Red Hat 6.1 with the ss990417 patch, as they'll think those came
from unpatched systems), but write files that can't be read by systems that
don't have the ss991029 patch (or, I think, the ss990915 patch) applied.

The next version of Ethereal:

	http://ethereal.zing.org/

which will be able to read vanilla, Red Hat 6.1, and ss991029 "libpcap" files
(it uses a hack^H^H^H^Hheuristic to check whether a file that appears to be a
vanilla file is actually a Red Hat 6.1 file) and can write out a file in any of
those formats, should also come with source to a program, "editcap", which can
read a capture file in any format Ethereal can read and write it out in any
format Ethereal can write, and thus should let you turn Red Hat 6.1, or
ss991029, "libpcap"/"tcpdump" files into files that can be read by vanilla
"libpcap"/"tcpdump".

6773, of which this has been marked a duplicate, will be fixed (in a subsequent
Red Hat release, I infer) by picking up the ss991029 version of Alexey's
patches, which will, at least, let that future RH Linux read capture files from
systems with vanilla "libpcap", although it'd require some translation (e.g.,
with "editcap") to make files from that system readable on systems with vanilla
"libpcap".

(I have heard a claim on the "ethereal-dev" mailing list that recent SuSE Linux
releases have also picked up some version of Alexey's patches; if they have,
hopefully it's at least the ss991029 version, not the ss990417 version.)

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