libpcap-0.7.2.tar.gz

@(#) $Header: /tcpdump/master/libpcap/INSTALL.txt,v 1.2.2.1 2002/07/16 05:02:47 guy Exp $ (LBL) 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. 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. 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. 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://ftp.gnu.org/pub/gnu/gcc/ 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. 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 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. 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. 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: ftp://ftp.digital.com/pub/Digital/dec-faq/Digital-UNIX Look for the "How do I configure the Berkeley Packet Filter and capture tcpdump traces?" item. 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. 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 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. 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, 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, packe