diff options
author | John Crispin <john@openwrt.org> | 2007-06-02 00:46:02 +0000 |
---|---|---|
committer | John Crispin <john@openwrt.org> | 2007-06-02 00:46:02 +0000 |
commit | e19eb3d8286ad66f455721f8b7f8260bce5e4016 (patch) | |
tree | 37c13b9c5ec72323b4ed9f1757aa7055b5013226 /target/linux/etrax-2.6/image/e100boot/src/libpcap-0.4/INSTALL | |
parent | a1ddc8ab7d95ffb1f50b13c93a90e6e9fda9a591 (diff) | |
download | upstream-e19eb3d8286ad66f455721f8b7f8260bce5e4016.tar.gz upstream-e19eb3d8286ad66f455721f8b7f8260bce5e4016.tar.bz2 upstream-e19eb3d8286ad66f455721f8b7f8260bce5e4016.zip |
add initial support for the crisarchitecture used on foxboards to openwrt
SVN-Revision: 7439
Diffstat (limited to 'target/linux/etrax-2.6/image/e100boot/src/libpcap-0.4/INSTALL')
-rw-r--r-- | target/linux/etrax-2.6/image/e100boot/src/libpcap-0.4/INSTALL | 328 |
1 files changed, 328 insertions, 0 deletions
diff --git a/target/linux/etrax-2.6/image/e100boot/src/libpcap-0.4/INSTALL b/target/linux/etrax-2.6/image/e100boot/src/libpcap-0.4/INSTALL new file mode 100644 index 0000000000..e108597514 --- /dev/null +++ b/target/linux/etrax-2.6/image/e100boot/src/libpcap-0.4/INSTALL @@ -0,0 +1,328 @@ +@(#) $Header: /usr/local/cvs/linux/tools/build/e100boot/libpcap-0.4/INSTALL,v 1.1 1999/08/26 10:05:18 johana 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. + +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://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 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. + +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 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. Finally, testing shows that there can't be more than one +simultaneous dlpi user per network interface and you cannot capture +outbound packets. + +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. 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! + +If you use AIX, you may not be able to build libpcap from this release. +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 + +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 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 +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 +ppp.h - Point to Point Protocol definitions +savefile.c - offline support +scanner.l - filter string scanner |