mirror of
https://git.FreeBSD.org/src.git
synced 2024-12-18 10:35:55 +00:00
297 lines
12 KiB
Plaintext
297 lines
12 KiB
Plaintext
@(#) $Header: INSTALL,v 1.32 96/12/11 19:16:21 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.4.
|
|
|
|
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 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.)
|
|
|
|
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
|
|
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.
|
|
|
|
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, 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:
|
|
|
|
/usr/include/sys/dlpi.h
|
|
/usr/include/sys/dlpi_ext.h
|
|
|
|
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.
|
|
|
|
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, 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.
|
|
|
|
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. We note 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.
|
|
|
|
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.
|
|
|
|
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. 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.
|
|
|
|
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 the current version 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
|
|
acsite.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
|
|
linux-include/* - network include files missing on Linux
|
|
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
|