head	1.2;
access;
symbols
	RELENG_7_4_0_RELEASE:1.1.1.5.24.1
	RELENG_7_4:1.1.1.5.24.1.0.10
	RELENG_7_4_BP:1.1.1.5.24.1
	RELENG_7_3_0_RELEASE:1.1.1.5.24.1
	RELENG_7_3:1.1.1.5.24.1.0.8
	RELENG_7_3_BP:1.1.1.5.24.1
	RELENG_7_2_0_RELEASE:1.1.1.5.24.1
	RELENG_7_2:1.1.1.5.24.1.0.6
	RELENG_7_2_BP:1.1.1.5.24.1
	RELENG_7_1_0_RELEASE:1.1.1.5.24.1
	RELENG_6_4_0_RELEASE:1.1.1.5
	RELENG_7_1:1.1.1.5.24.1.0.4
	RELENG_7_1_BP:1.1.1.5.24.1
	RELENG_6_4:1.1.1.5.0.28
	RELENG_6_4_BP:1.1.1.5
	RELENG_7_0_0_RELEASE:1.1.1.5.24.1
	RELENG_6_3_0_RELEASE:1.1.1.5
	RELENG_7_0:1.1.1.5.24.1.0.2
	RELENG_7_0_BP:1.1.1.5.24.1
	RELENG_6_3:1.1.1.5.0.26
	RELENG_6_3_BP:1.1.1.5
	RELENG_7:1.1.1.5.0.24
	RELENG_7_BP:1.1.1.5
	RELENG_6_2_0_RELEASE:1.1.1.5
	RELENG_6_2:1.1.1.5.0.22
	RELENG_6_2_BP:1.1.1.5
	RELENG_5_5_0_RELEASE:1.1.1.5
	RELENG_5_5:1.1.1.5.0.20
	RELENG_5_5_BP:1.1.1.5
	RELENG_6_1_0_RELEASE:1.1.1.5
	RELENG_6_1:1.1.1.5.0.18
	RELENG_6_1_BP:1.1.1.5
	RELENG_6_0_0_RELEASE:1.1.1.5
	RELENG_6_0:1.1.1.5.0.16
	RELENG_6_0_BP:1.1.1.5
	RELENG_6:1.1.1.5.0.14
	RELENG_6_BP:1.1.1.5
	RELENG_5_4_0_RELEASE:1.1.1.5
	RELENG_5_4:1.1.1.5.0.12
	RELENG_5_4_BP:1.1.1.5
	RELENG_4_11_0_RELEASE:1.1.1.4.2.2
	RELENG_4_11:1.1.1.4.2.2.0.10
	RELENG_4_11_BP:1.1.1.4.2.2
	RELENG_5_3_0_RELEASE:1.1.1.5
	RELENG_5_3:1.1.1.5.0.10
	RELENG_5_3_BP:1.1.1.5
	RELENG_5:1.1.1.5.0.8
	RELENG_5_BP:1.1.1.5
	RELENG_4_10_0_RELEASE:1.1.1.4.2.2
	RELENG_4_10:1.1.1.4.2.2.0.8
	RELENG_4_10_BP:1.1.1.4.2.2
	RELENG_5_2_1_RELEASE:1.1.1.5
	RELENG_5_2_0_RELEASE:1.1.1.5
	RELENG_5_2:1.1.1.5.0.6
	RELENG_5_2_BP:1.1.1.5
	RELENG_4_9_0_RELEASE:1.1.1.4.2.2
	RELENG_4_9:1.1.1.4.2.2.0.6
	RELENG_4_9_BP:1.1.1.4.2.2
	RELENG_5_1_0_RELEASE:1.1.1.5
	RELENG_5_1:1.1.1.5.0.4
	RELENG_5_1_BP:1.1.1.5
	RELENG_4_8_0_RELEASE:1.1.1.4.2.2
	RELENG_4_8:1.1.1.4.2.2.0.4
	RELENG_4_8_BP:1.1.1.4.2.2
	RELENG_5_0_0_RELEASE:1.1.1.5
	RELENG_5_0:1.1.1.5.0.2
	RELENG_5_0_BP:1.1.1.5
	RELENG_4_7_0_RELEASE:1.1.1.4.2.2
	RELENG_4_7:1.1.1.4.2.2.0.2
	RELENG_4_7_BP:1.1.1.4.2.2
	RELENG_4_6_2_RELEASE:1.1.1.4.2.1
	RELENG_4_6_1_RELEASE:1.1.1.4.2.1
	RELENG_4_6_0_RELEASE:1.1.1.4.2.1
	RELENG_4_6:1.1.1.4.2.1.0.6
	RELENG_4_6_BP:1.1.1.4.2.1
	RELENG_4_5_0_RELEASE:1.1.1.4.2.1
	RELENG_4_5:1.1.1.4.2.1.0.4
	RELENG_4_5_BP:1.1.1.4.2.1
	RELENG_4_4_0_RELEASE:1.1.1.4.2.1
	RELENG_4_4:1.1.1.4.2.1.0.2
	RELENG_4_4_BP:1.1.1.4.2.1
	RELENG_4_3_0_RELEASE:1.1.1.4
	RELENG_4_3:1.1.1.4.0.4
	RELENG_4_3_BP:1.1.1.4
	v0_6_2:1.1.1.5
	RELENG_4_2_0_RELEASE:1.1.1.4
	RELENG_4_1_1_RELEASE:1.1.1.4
	PRE_SMPNG:1.1.1.4
	RELENG_4_1_0_RELEASE:1.1.1.4
	RELENG_3_5_0_RELEASE:1.1.1.3
	RELENG_4_0_0_RELEASE:1.1.1.4
	RELENG_4:1.1.1.4.0.2
	RELENG_4_BP:1.1.1.4
	v0_5:1.1.1.4
	TCPDUMP_ORG:1.1.1
	RELENG_3_4_0_RELEASE:1.1.1.3
	RELENG_3_3_0_RELEASE:1.1.1.3
	RELENG_3_2_PAO:1.1.1.3.0.4
	RELENG_3_2_PAO_BP:1.1.1.3
	RELENG_3_2_0_RELEASE:1.1.1.3
	RELENG_3_1_0_RELEASE:1.1.1.3
	RELENG_3:1.1.1.3.0.2
	RELENG_3_BP:1.1.1.3
	RELENG_2_2_8_RELEASE:1.1.1.1
	RELENG_3_0_0_RELEASE:1.1.1.3
	v0_4:1.1.1.3
	RELENG_2_2_7_RELEASE:1.1.1.1
	RELENG_2_2_6_RELEASE:1.1.1.1
	RELENG_2_2_5_RELEASE:1.1.1.1
	v0_3:1.1.1.2
	RELENG_2_2_2_RELEASE:1.1.1.1
	RELENG_2_2_1_RELEASE:1.1.1.1
	RELENG_2_2_0_RELEASE:1.1.1.1
	RELENG_2_2:1.1.1.1.0.2
	RELENG_2_2_BP:1.1.1.1
	v0_2_1:1.1.1.1
	LBL:1.1.1;
locks; strict;
comment	@# @;


1.2
date	2007.10.16.02.07.55;	author mlaier;	state dead;
branches;
next	1.1;

1.1
date	96.08.19.20.36.29;	author pst;	state Exp;
branches
	1.1.1.1;
next	;

1.1.1.1
date	96.08.19.20.36.29;	author pst;	state Exp;
branches;
next	1.1.1.2;

1.1.1.2
date	97.05.27.00.01.00;	author fenner;	state Exp;
branches;
next	1.1.1.3;

1.1.1.3
date	98.09.15.19.27.58;	author fenner;	state Exp;
branches;
next	1.1.1.4;

1.1.1.4
date	2000.01.30.00.32.33;	author fenner;	state Exp;
branches
	1.1.1.4.2.1;
next	1.1.1.5;

1.1.1.5
date	2001.04.03.04.18.09;	author fenner;	state Exp;
branches
	1.1.1.5.24.1;
next	;

1.1.1.4.2.1
date	2001.08.01.00.23.07;	author fenner;	state Exp;
branches;
next	1.1.1.4.2.2;

1.1.1.4.2.2
date	2002.07.05.14.39.58;	author fenner;	state dead;
branches;
next	;

1.1.1.5.24.1
date	2007.10.19.03.03.55;	author mlaier;	state dead;
branches;
next	;


desc
@@


1.2
log
@Resolve merge conflicts

Approved by:	re (kensmith)
Obtained from:	tcpdump.org
@
text
@@@(#) $Header: INSTALL,v 1.27 96/07/23 14:36:02 leres Exp $ (LBL)

To build libpcap, first customize any paths in Makefile.in, then run
"./configure" (a shell script). The configure script will determine
your system attributes and generate an appropriate Makefile from
Makefile.in. Next run "make". If everything goes well you can su to
root and run "make install", "make install-incl" and "make
install-man". However, you need not install libpcap if you just want to
build tcpdump; just make sure the tcpdump and libpcap directory trees
have the same parent directory.

If configure says:

    configure: warning: cannot determine packet capture interface
    configure: warning: (see INSTALL for more info)

then your system either does not support packet capture or your system
does support packet capture but libpcap does not support that
particular type. (If you have HP-UX, see below.) If your system uses a
packet capture not supported by libpcap, please send us patches; don't
forget to include an autoconf fragment suitable for use in
configure.in.

You will need an ANSI C compiler to build libpcap. The configure script
will abort if your compiler is not ANSI compliant. If this happens, use
the GNU C compiler, available via anonymous ftp:

	ftp://prep.ai.mit.edu/pub/gnu/gcc-*.tar.gz

Note well: If you use gcc, you may need to run its "fixincludes"
script. Running fixincludes is not required with later versions of gcc
and in some cases (e.g. Solaris 2.5) causes problems when run. The
configure script will abort if it detects if the fixincludes needs to
be run. If the fixincludes test in configure passes, you're probably
ok.

If you use flex, you must use version 2.4.6 or higher. The configure
script automatically detects the version of flex and will not use it
unless it is new enough. You can use "flex -V" to see what version you
have (unless it's really old). The current version of flex is available
via anonymous ftp:

	ftp://ftp.ee.lbl.gov/flex-*.tar.Z

As of this writing, the current version is 2.5.3.

If you use bison, you must use flex (and visa versa). The configure
script automatically falls back to lex and yacc if both flex and bison
are not found.

If your system only has AT&T lex, that also works okay unless your
libpcap program uses other lex/yacc generated code. (Although it's
possible to map the yy* identifiers with a script, we use flex and
bison so we don't feel this is necessary.)

Some systems support the Berkeley Packet Filter natively; for example
out of the box OSF and BSD/OS have bpf. If your system does not support
bpf, you will need to pick up:

	ftp://ftp.ee.lbl.gov/bpf-*.tar.Z

Note well: you MUST have kernel source for your operating system in
order to install bpf. An exception is SunOS 4; the bpf distribution
includes replacement kernel objects for some of the standard SunOS 4
network device drivers. See the bpf INSTALL document for more
information.

If you use Solaris, there is a bug with bufmod(7) that is fixed in
5.3.2.  Setting a snapshot length with the broken bufmod(7) results in
data be truncated from the FRONT of the packet instead of the end.  The
work around is to not set a snapshot length but this results in
performance problems since the entire packet is copied to user space.
If you must run an older version of Solaris, there is a patch available
from Sun; ask for bugid 1149065. After installing the patch, use
"setenv BUFMOD_FIXED" to enable use of bufmod(7). However, we recommend
you run a more current release of Solaris.

Under OSF, packet capture must be enabled before it can be used. For
instructions on how to enable packet filter support, see:

	ftp://ftp.digital.com/pub/Digital/dec-faq/Digital-UNIX

Once you enable packet filter support, your OSF system will support bpf
natively.

Under Ultrix, packet capture must be enabled before it can be used. For
instructions on how to enable packet filter support, see:

	ftp://ftp.digital.com/pub/Digital/dec-faq/ultrix

If you use HP-UX, have at least version 9 and either have the version
of cc that supports ANSI C (cc -Aa) or else get the GNU C compiler. In
addition, you must buy the optional streams package. If you don't have:

    /usr/include/sys/dlpi.h
    /usr/include/sys/dlpi_ext.h

then you don't have the streams package. It's also possible that the
streams package is standard starting with a particular subrelease of
HP-UX 10.

The HP implementation of DLPI is a little bit eccentric. Unlike
Solaris, you must attach /dev/dlpi instead of the specific /dev/*
network pseudo device entry in order to capture packets. The ppa is
based on the ifnet "index" number. Under HP-UX 9, it is necessary to
read /dev/kmem and the kernel symbol file (/hp-ux). Under HP-UX 10,
dlpi can provide information for determining the ppa. It does not seem
to be possible to trace the loopback interface. Unlike other DLPI
implementations, PHYS implies MULTI and SAP and you get an error if you
try to enable more than one promiscous more than one promiscuous mode
at a time. This results in error messages:

    WARNING: DL_PROMISC_MULTI failed (recv_ack: promisc_multi: Invalid argument)
    WARNING: DL_PROMISC_SAP failed (recv_ack: promisc_sap: Invalid argument)

which may be safely ignored. Finally, testing shows that there can't be
more than one simultaneous dlpi user per network interface.

If you use Linux, you will not be able to build libpcap from this
release. We have a Linux system up and hope to support Linux at some
point after the next even version of the Linux kernel source is
released. Meanwhile, you can try picking up:

	ftp://sunsite.unc.edu/pub/Linux/system/Network/management/tcpdump-3.0.2-linux.tar.gz

This appears to be libpcap 0.0.6 and tcpdump 3.0.2 hacked for Linux.
(It includes 20000 lines of linux-specific include files, almost twice
the source in the official libpcap distribution. It also contains a
linux specific libpcap module that is essentially a hacked copy of the
snoop module; one of the hacks is to replace the Regents of the
University of California copyright with a vague reference to the GNU
license.)

Note well: there is rumoured to be a version of tcpdump floating around
called 3.0.3 that includes libpcap and is supposed to support Linux.
You should be advised that the Network Research Group at LBNL never
generated a release with this version number. You should also know that
a standard trick crackers use to get people to install trojans is to
distribute bogus packages that have a version number higher than the
current release.

If you use AIX, you will not be able to build libpcap from this
release. We have a set of contributed patches that we hope to integrate
in some future release of libpcap.

If you use NeXTSTEP, you will not be able to build libpcap from this
release. We hope to support this operating system in some future
release of libpcap.

If you use SINIX, you should be able to build libpcap from this
release. We are told you must have the C-DS V1.1A00 compiler. If you
have problems, please send details to libpcap@@ee.lbl.gov.

If you use SCO, you might have trouble building libpcap from this
release. We do not have a machine running SCO and have not had reports
of anyone successfully building on it. Since SCO apparently supports
dlpi, it's possible libpcap 0.2 works. Meanwhile, sco provides a
tcpdump binary as part of their "Network/Security Tools" package:

    http://www.sco.com/technology/internet/goodies/#SECURITY

There is also a README that explains how to enable packet capture.

If you use UnixWare, you will not be able to build libpcap from this
release. We hope to support this operating system in some future
release of libpcap. Meanwhile, there appears to be an UnixWare port of
libpcap 0.0 (and tcpdump 3.0) in:

    ftp://ftp1.freebird.org/pub/mirror/freebird/internet/systools/

UnixWare appears to use a hacked version of DLPI.

If you use flex and bison and not gcc but the linker cannot find
alloca(), you need to either use gcc or not use flex and bison.

If linking tcpdump fails with "Undefined: _alloca" when using bison on
a Sun4, your version of bison is broken. In any case version 1.16 or
higher is recommended (1.14 is known to cause problems 1.16 is known to
work). Either pick up a current version from:

	ftp://prep.ai.mit.edu/pub/gnu/bison.tar.gz

or hack around it by inserting the lines:

	#ifdef __GNUC__
	#define alloca __builtin_alloca
	#else
	#ifdef sparc
	#include <alloca.h>
	#else
	char *alloca ();
	#endif
	#endif

right after the (100 line!) GNU license comment in bison.simple, remove
grammar.[co] and fire up make again.

If you use SunOS 4, your kernel must support streams NIT. If you run a
libpcap program and it dies with:

    /dev/nit: No such device

You must add streams NIT support to your kernel configuration, run
config and boot the new kernel.

If you are running a version of SunOS earlier than 4.1, you will need
to replace the Sun supplied /sys/sun{3,4,4c}/OBJ/nit_if.o with the
appropriate version from this distribution's SUNOS4 subdirectory and
build a new kernel:

	nit_if.o.sun3-sunos4		(any flavor of sun3)
	nit_if.o.sun4c-sunos4.0.3c	(SS1, SS1+, IPC, SLC, etc.)
	nit_if.o.sun4-sunos4		(Sun4's not covered by
					    nit_if.o.sun4c-sunos4.0.3c)

These nit replacements fix a bug that makes nit essentially unusable in
pre-SunOS 4.1.  In addition, our sun4c-sunos4.0.3c nit gives you
timestamps to the resolution of the SS-1 clock (1 us) rather than the
lousy 20ms timestamps Sun gives you  (tcpdump will print out the full
timestamp resolution if it finds it's running on a SS-1).

FILES
-----
CHANGES		- description of differences between releases
FILES		- list of files exported as part of the distribution
INSTALL		- this file
Makefile.in	- compilation rules (input to the configure script)
README		- description of distribution
SUNOS4		- pre-SunOS 4.1 replacement kernel nit modules
VERSION		- version of this release
aclocal.m4	- autoconf macros
bpf/net		- copies of bpf_filter.c and bpf.h
bpf_filter.c	- symlink to bpf/net/bpf_filter.c
bpf_image.c	- bpf disassembly routine
config.guess	- autoconf support
config.sub	- autoconf support
configure	- configure script (run this first)
configure.in	- configure script source
etherent.c	- /etc/ethers support routines
ethertype.h	- ethernet protocol types and names definitions
gencode.c	- bpf code generation routines
gencode.h	- bpf code generation definitions
grammar.y	- filter string grammar
inet.c		- network routines
install-sh	- BSD style install script
lbl/gnuc.h	- gcc macros and defines
lbl/os-*.h	- os dependent defines and prototypes
mkdep		- construct Makefile dependency list
nametoaddr.c	- hostname to address routines
net		- symlink to bpf/net
optimize.c	- bpf optimization routines
pcap-bpf.c	- BSD Packet Filter support
pcap-dlpi.c	- Data Link Provider Interface support
pcap-enet.c	- enet support
pcap-int.h	- internal libpcap definitions
pcap-namedb.h	- public libpcap name database definitions
pcap-nit.c	- Network Interface Tap support
pcap-nit.h	- Network Interface Tap definitions
pcap-null.c	- dummy monitor support (allows offline use of libpcap)
pcap-pf.c	- Packet Filter support
pcap-pf.h	- Packet Filter definitions
pcap-snit.c	- Streams based Network Interface Tap support
pcap-snoop.c	- Snoop network monitoring support
pcap.3		- manual entry
pcap.c		- pcap utility routines
pcap.h		- public libpcap definitions
savefile.c	- offline support
scanner.l	- filter string scanner
@


1.1
log
@Initial revision
@
text
@@


1.1.1.1
log
@Virgin import of LBL libpcap version 0.2.1.
Obtained from: ftp://ftp.ee.lbl.gov/libpcap.tar.Z on 19-Aug-1996.
@
text
@@


1.1.1.2
log
@Virgin import of libpcap 0.3
@
text
@d1 1
a1 1
@@(#) $Header: INSTALL,v 1.32 96/12/11 19:16:21 leres Exp $ (LBL)
d45 1
a45 1
As of this writing, the current version is 2.5.4.
d51 4
a54 7
If you use flex and bison, you may also have to use gcc to avoid
undefined references for alloca.

If your system only has AT&T lex, this is okay unless your libpcap
program uses other lex/yacc generated code. (Although it's possible to
map the yy* identifiers with a script, we use flex and bison so we
don't feel this is necessary.)
d69 8
a76 23
Solaris 2.3.2 (aka SunOS 5.3.2). Setting a snapshot length with the
broken bufmod(7) results in data be truncated from the FRONT of the
packet instead of the end.  The work around is to not set a snapshot
length but this results in performance problems since the entire packet
is copied to user space. If you must run an older version of Solaris,
there is a patch available from Sun; ask for bugid 1149065. After
installing the patch, use "setenv BUFMOD_FIXED" to enable use of
bufmod(7). However, we recommend you run a more current release of
Solaris.

If you use the SPARCompiler, you must be careful to not use the
/usr/ucb/cc interface. If you do, you will get bogus warnings and
perhaps errors. Either make sure your path has /opt/SUNWspro/bin
before /usr/ucb or else:

    setenv CC /opt/SUNWspro/bin/cc

before running configure. (You might have to do a "make distclean"
if you already ran configure once).

Also note that "make depend" won't work; while all of the known
universe uses -M, the SPARCompiler uses -xM to generate makefile
dependencies.
d91 3
a93 4
If you use HP-UX, you must have at least version 9 and either the
version of cc that supports ANSI C (cc -Aa) or else use the GNU C
compiler. You must also buy the optional streams package. If you don't
have:
d98 3
a100 6
then you don't have the streams package. In addition, we believe you
need to install the "9.X LAN and DLPI drivers cumulative" patch
(PHNE_6855) to make the version 9 DLPI work with libpcap.

It's been reported that the DLPI streams package is standard starting
with HP-UX 10.
d119 14
a132 7
If you use Linux, this version of libpcap is known to compile and run
under Red Hat 4.0 with the 2.0.25 kernel. It may work with earlier 2.X
versions but is guaranteed not to work with 1.X kernels. Running more
than one libpcap program at a time can cause problems since promiscuous
mode is implemented by twiddlin the interface flags from the libpcap
application. Also, packet timestamps aren't very good. This appears to
be due to haphazard handling of the timestamp in the kernel.
d137 2
a138 2
generated a release with this version number. We note with interest
that a standard cracker trick to get people to install trojans is to
d142 3
a144 6
If you use AIX, you may not be able to build libpcap from this release.
We do not have an AIX system in house so it's impossible for us to test
AIX patches submitted to us. We are told that you must like againt
/lib/pse.exp, that you must use AIX cc or a GNU C compiler newer than
2.7.2 and that you may need to run strload before running a libpcap
application.
d151 2
a152 11
release. It is known to compile and run on SINIX-Y/N 5.42 with the C-DS
V1.0 or V1.1 compiler. But note that in some releases of SINIX, yacc
emits incorrect code; if grammar.y fails to compile, change every
occurence of:

	#ifdef YYDEBUG

to:
	#if YYDEBUG

Another workaround is to use flex and bison.
d157 2
a158 2
dlpi, it's possible the current version works. Meanwhile, sco provides
a tcpdump binary as part of their "Network/Security Tools" package:
d231 1
a231 1
acsite.m4	- autoconf macros
a247 1
linux-include/*	- network include files missing on Linux
@


1.1.1.3
log
@Virgin import of LBL libpcap v0.4
@
text
@d1 1
a1 1
@@(#) $Header: INSTALL,v 1.42 98/03/20 18:49:16 vern Exp $ (LBL)
a23 9
It is possible to override the default packet capture type, although
the circumstance where this works are limited. For example if you have
installed bpf under SunOS 4 and wish to build a snit libpcap:

    ./configure --with-pcap=snit

Another example is to force a supported packet capture type in the case
where the configure scripts fails to detect it.

d33 3
a35 7
configure script will abort with:

    checking for ANSI ioctl definitions... yes
    configure: error: see the INSTALL for more info

if it detects if the fixincludes needs to be run. If the fixincludes
test in configure passes, you're probably ok.
d51 2
a52 6
Sometimes the stock C compiler does not interact well with flex and
bison. The list of problems includes undefined references for alloca.
You can get around this by installing gcc or manually disabling flex
and bison with:

    ./configure --without-flex --without-bison
a95 12
If you are trying to do packet capture with a FORE ATM card, you may or
may not be able to. They usually only release their driver in object
code so unless their driver supports packet capture, there's not much
libpcap can do.

If you get an error like:

    tcpdump: recv_ack: bind error 0x???

when using DLPI, look for the DL_ERROR_ACK error return values, usually
in /usr/include/sys/dlpi.h, and find the corresponding value.

d133 7
a139 3
at a time. Finally, testing shows that there can't be more than one
simultaneous dlpi user per network interface and you cannot capture
outbound packets.
d155 1
a155 5
current release. We also note with annoyance that 90% of the Linux
related bug reports we get are due to changes made to unofficial
versions of our page. If you are having trouble but aren't using a
version that came from ftp.ee.lbl.gov, please try that before
submitting a bug report!
d158 5
a162 10
Although AIX 4 ships with tcpdump, it is an old version that predates
libpcap. We do not have an AIX system in house so it's impossible for
us to test AIX patches submitted to us. We are told that you must link
against /lib/pse.exp, that you must use AIX cc or a GNU C compiler
newer than 2.7.2 and that you may need to run strload before running a
libpcap application. Also, it may be necessary to run the configure
script as root in order for it to detect that bpf is available. Another
workaround is to use:

    ./configure --with-pcap=bpf
d200 3
d258 1
a258 1
aclocal.m4	- autoconf macros
a294 1
ppp.h		- Point to Point Protocol definitions
@


1.1.1.4
log
@Virgin import of tcpdump.org libpcap v0.5
@
text
@d1 1
a1 1
@@(#) $Header: /tcpdump/master/libpcap/INSTALL,v 1.42.1.1 1999/10/07 23:46:40 mcr Exp $ (LBL)
@


1.1.1.4.2.1
log
@MFC: libpcap 0.6
@
text
@d1 1
a1 1
@@(#) $Header: /tcpdump/master/libpcap/INSTALL,v 1.46 2000/12/16 09:05:11 guy Exp $ (LBL)
d3 8
a10 7
To build libpcap, run "./configure" (a shell script). The configure
script will determine your system attributes and generate an
appropriate Makefile from Makefile.in. Next run "make". If everything
goes well you can su to root and run "make install". However, you need
not install libpcap if you just want to build tcpdump; just make sure
the tcpdump and libpcap directory trees have the same parent
directory.
d37 12
a48 1
	ftp://ftp.gnu.org/pub/gnu/gcc/
d125 2
a126 3
Under {DEC OSF/1, Digital UNIX, Tru64 UNIX}, packet capture must be
enabled before it can be used.  For instructions on how to enable packet
filter support, see:
a129 3
Look for the "How do I configure the Berkeley Packet Filter and capture
tcpdump traces?" item.

d150 2
a151 1
The DLPI streams package is standard starting with HP-UX 10.
d155 1
a155 1
network pseudo device entry in order to capture packets. The PPA is
d158 1
a158 1
DLPI can provide information for determining the PPA. It does not seem
d161 4
a164 24
try to enable more than one promiscuous mode at a time.

It is impossible to capture outbound packets on HP-UX 9.  To do so on
HP-UX 10, you will, apparently, need a late "LAN products cumulative
patch" (at one point, it was claimed that this would be PHNE_18173 for
s700/10.20; at another point, it was claimed that the required patches
were PHNE_20892, PHNE_20725 and PHCO_10947, or newer patches), and to do
so on HP-UX 11 you will, apparently, need the latest lancommon/DLPI
patches and the latest driver patch for the interface(s) in use on HP-UX
11 (at one point, it was claimed that patches PHNE_19766, PHNE_19826,
PHNE_20008, and PHNE_20735 did the trick).

Furthermore, on HP-UX 10, you will need to turn on a kernel switch by
doing

	echo 'lanc_outbound_promisc_flag/W 1' | adb -w /stand/vmunix /dev/mem

You would have to arrange that this happen on reboots; the right way to
do that would probably be to put it into an executable script file
"/sbin/init.d/outbound_promisc" and making
"/sbin/rc2.d/S350outbound_promisc" a symbolic link to that script.

Finally, testing shows that there can't be more than one simultaneous
DLPI user per network interface.
d167 6
a172 8
under Red Hat 4.0 with the 2.0.25 kernel.  It may work with earlier 2.X
versions but is guaranteed not to work with 1.X kernels.  Running more
than one libpcap program at a time, on a system with a 2.0.X kernel, can
cause problems since promiscuous mode is implemented by twiddling the
interface flags from the libpcap application; the packet capture
mechanism in the 2.2 and later kernels doesn't have this problem.  Also,
packet timestamps aren't very good.  This appears to be due to haphazard
handling of the timestamp in the kernel.
d175 10
a184 14
called 3.0.3 that includes libpcap and is supposed to support Linux. 
You should be advised that neither the Network Research Group at LBNL
nor the Tcpdump Group ever generated a release with this version number. 
The LBNL Network Research Group notes with interest that a standard
cracker trick to get people to install trojans is to distribute bogus
packages that have a version number higher than the current release. 
They also noted with annoyance that 90% of the Linux related bug reports
they got are due to changes made to unofficial versions of their page. 
If you are having trouble but aren't using a version that came from
tcpdump.org, please try that before submitting a bug report!

On Linux, libpcap will not work if the kernel does not have the packet
socket option enabled; see the README.linux file for information about
this.
d187 1
d192 3
a194 1
libpcap application.
d196 1
a196 2
Read the README.aix file for information on installing libpcap and
configuring your system to be able to support libpcap.
d218 1
a218 1
DLPI, it's possible the current version works. Meanwhile, SCO provides
d239 1
a239 1
	ftp://ftp.gnu.org/pub/gnu/bison
d306 1
@


1.1.1.4.2.2
log
@MFC: libpcap-0.7.1
@
text
@@


1.1.1.5
log
@Virgin import of tcpdump.org libpcap v0.6.2
@
text
@d1 1
a1 1
@@(#) $Header: /tcpdump/master/libpcap/INSTALL,v 1.46 2000/12/16 09:05:11 guy Exp $ (LBL)
d3 8
a10 7
To build libpcap, run "./configure" (a shell script). The configure
script will determine your system attributes and generate an
appropriate Makefile from Makefile.in. Next run "make". If everything
goes well you can su to root and run "make install". However, you need
not install libpcap if you just want to build tcpdump; just make sure
the tcpdump and libpcap directory trees have the same parent
directory.
d37 12
a48 1
	ftp://ftp.gnu.org/pub/gnu/gcc/
d125 2
a126 3
Under {DEC OSF/1, Digital UNIX, Tru64 UNIX}, packet capture must be
enabled before it can be used.  For instructions on how to enable packet
filter support, see:
a129 3
Look for the "How do I configure the Berkeley Packet Filter and capture
tcpdump traces?" item.

d150 2
a151 1
The DLPI streams package is standard starting with HP-UX 10.
d155 1
a155 1
network pseudo device entry in order to capture packets. The PPA is
d158 1
a158 1
DLPI can provide information for determining the PPA. It does not seem
d161 4
a164 24
try to enable more than one promiscuous mode at a time.

It is impossible to capture outbound packets on HP-UX 9.  To do so on
HP-UX 10, you will, apparently, need a late "LAN products cumulative
patch" (at one point, it was claimed that this would be PHNE_18173 for
s700/10.20; at another point, it was claimed that the required patches
were PHNE_20892, PHNE_20725 and PHCO_10947, or newer patches), and to do
so on HP-UX 11 you will, apparently, need the latest lancommon/DLPI
patches and the latest driver patch for the interface(s) in use on HP-UX
11 (at one point, it was claimed that patches PHNE_19766, PHNE_19826,
PHNE_20008, and PHNE_20735 did the trick).

Furthermore, on HP-UX 10, you will need to turn on a kernel switch by
doing

	echo 'lanc_outbound_promisc_flag/W 1' | adb -w /stand/vmunix /dev/mem

You would have to arrange that this happen on reboots; the right way to
do that would probably be to put it into an executable script file
"/sbin/init.d/outbound_promisc" and making
"/sbin/rc2.d/S350outbound_promisc" a symbolic link to that script.

Finally, testing shows that there can't be more than one simultaneous
DLPI user per network interface.
d167 6
a172 8
under Red Hat 4.0 with the 2.0.25 kernel.  It may work with earlier 2.X
versions but is guaranteed not to work with 1.X kernels.  Running more
than one libpcap program at a time, on a system with a 2.0.X kernel, can
cause problems since promiscuous mode is implemented by twiddling the
interface flags from the libpcap application; the packet capture
mechanism in the 2.2 and later kernels doesn't have this problem.  Also,
packet timestamps aren't very good.  This appears to be due to haphazard
handling of the timestamp in the kernel.
d175 10
a184 14
called 3.0.3 that includes libpcap and is supposed to support Linux. 
You should be advised that neither the Network Research Group at LBNL
nor the Tcpdump Group ever generated a release with this version number. 
The LBNL Network Research Group notes with interest that a standard
cracker trick to get people to install trojans is to distribute bogus
packages that have a version number higher than the current release. 
They also noted with annoyance that 90% of the Linux related bug reports
they got are due to changes made to unofficial versions of their page. 
If you are having trouble but aren't using a version that came from
tcpdump.org, please try that before submitting a bug report!

On Linux, libpcap will not work if the kernel does not have the packet
socket option enabled; see the README.linux file for information about
this.
d187 1
d192 3
a194 1
libpcap application.
d196 1
a196 2
Read the README.aix file for information on installing libpcap and
configuring your system to be able to support libpcap.
d218 1
a218 1
DLPI, it's possible the current version works. Meanwhile, SCO provides
d239 1
a239 1
	ftp://ftp.gnu.org/pub/gnu/bison
d306 1
@


1.1.1.5.24.1
log
@MFC:
  Import of tcpdump 3.9.8 and libpcap 0.9.8

Approved by:	re (kensmith)
@
text
@@


