Bug 7921

Summary:	libpcap and thus tcpdump incompatible with rest of universe
Product:	[Retired] Red Hat Linux	Reporter:	genescott
Component:	tcpdump	Assignee:	Harald Hoyer <harald>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.1	CC:	genec
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	1999-12-22 13:26:25 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description genescott 1999-12-21 07:56:59 UTC

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 13:26:59 UTC

*** This bug has been marked as a duplicate of 6773 ***

Comment 2 Guy Harris 1999-12-23 10:25:59 UTC

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.)