diff --git a/contrib/libpcap/README.dag b/contrib/libpcap/README.dag deleted file mode 100644 index acf97edf8d04..000000000000 --- a/contrib/libpcap/README.dag +++ /dev/null @@ -1,114 +0,0 @@ - -The following instructions apply if you have a Linux or FreeBSD platform and -want libpcap to support the DAG range of passive network monitoring cards from -Endace (http://www.endace.com, see below for further contact details). - -1) Install and build the DAG software distribution by following the -instructions supplied with that package. Current Endace customers can download -the DAG software distibution from https://www.endace.com - -2) Configure libcap. To allow the 'configure' script to locate the DAG -software distribution use the '--with-dag' option: - - ./configure --with-dag=DIR - -Where DIR is the root of the DAG software distribution, for example -/var/src/dag. If the DAG software is correctly detected 'configure' will -report: - - checking whether we have DAG API... yes - -If 'configure' reports that there is no DAG API, the directory may have been -incorrectly specified or the DAG software was not built before configuring -libpcap. - -See also the libpcap INSTALL.txt file for further libpcap configuration -options. - -Building libpcap at this stage will include support for both the native packet -capture stream (linux or bpf) and for capturing from DAG cards. To build -libpcap with only DAG support specify the capture type as 'dag' when -configuring libpcap: - - ./configure --with-dag=DIR --with-pcap=dag - -Applications built with libpcap configured in this way will only detect DAG -cards and will not capture from the native OS packet stream. - ----------------------------------------------------------------------- - -Libpcap when built for DAG cards against dag-2.5.1 or later releases: - -Timeouts are supported. pcap_dispatch() will return after to_ms milliseconds -regardless of how many packets are received. If to_ms is zero pcap_dispatch() -will block waiting for data indefinitely. - -pcap_dispatch() will block on and process a minimum of 64kB of data (before -filtering) for efficiency. This can introduce high latencies on quiet -interfaces unless a timeout value is set. The timeout expiring will override -the 64kB minimum causing pcap_dispatch() to process any available data and -return. - -pcap_setnonblock is supported. When nonblock is set, pcap_dispatch() will -check once for available data, process any data available up to count, then -return immediately. - -pcap_findalldevs() is supported, e.g. dag0, dag1... - -Some DAG cards can provide more than one 'stream' of received data. -This can be data from different physical ports, or separated by filtering -or load balancing mechanisms. Receive streams have even numbers, e.g. -dag0:0, dag0:2 etc. Specifying transmit streams for capture is not supported. - -pcap_setfilter() is supported, BPF programs run in userspace. - -pcap_setdirection() is not supported. Only received traffic is captured. -DAG cards normally do not have IP or link layer addresses assigned as -they are used to passively monitor links. - -pcap_breakloop() is supported. - -pcap_datalink() and pcap_list_datalinks() are supported. The DAG card does -not attempt to set the correct datalink type automatically where more than -one type is possible. - -pcap_stats() is supported. ps_drop is the number of packets dropped due to -RX stream buffer overflow, this count is before filters are applied (it will -include packets that would have been dropped by the filter). The RX stream -buffer size is user configurable outside libpcap, typically 16-512MB. - -pcap_get_selectable_fd() is not supported, as DAG cards do not support -poll/select methods. - -pcap_inject() and pcap_sendpacket() are not supported. - -Some DAG cards now support capturing to multiple virtual interfaces, called -streams. Capture streams have even numbers. These are available via libpcap -as separate interfaces, e.g. dag0:0, dag0:2, dag0:4 etc. dag0:0 is the same -as dag0. These are visible via pcap_findalldevs(). - -libpcap now does NOT set the card's hardware snaplen (slen). This must now be -set using the appropriate DAG coniguration program, e.g. dagthree, dagfour, -dagsix, dagconfig. This is because the snaplen is currently shared between -all of the streams. In future this may change if per-stream slen is -implemented. - -DAG cards by default capture entire packets including the L2 -CRC/FCS. If the card is not configured to discard the CRC/FCS, this -can confuse applications that use libpcap if they're not prepared for -packets to have an FCS. Libpcap now reads the environment variable -ERF_FCS_BITS to determine how many bits of CRC/FCS to strip from the -end of the captured frame. This defaults to 32 for use with -Ethernet. If the card is configured to strip the CRC/FCS, then set -ERF_FCS_BITS=0. If used with a HDLC/PoS/PPP/Frame Relay link with 16 -bit CRC/FCS, then set ERF_FCS_BITS=16. - ----------------------------------------------------------------------- - -Please submit bug reports via . - -Please also visit our Web site at: - - http://www.endace.com/ - -For more information about Endace DAG cards contact . diff --git a/contrib/libpcap/README.hpux b/contrib/libpcap/README.hpux deleted file mode 100644 index 88c27f8a2581..000000000000 --- a/contrib/libpcap/README.hpux +++ /dev/null @@ -1,254 +0,0 @@ -For HP-UX 11i (11.11) and later, there are no known issues with -promiscuous mode under HP-UX. If you are using a earlier version of -HP-UX and cannot upgrade, please continue reading. - -HP-UX patches to fix packet capture problems - -Note that packet-capture programs such as tcpdump may, on HP-UX, not be -able to see packets sent from the machine on which they're running. -Some articles on groups.google.com discussing this are: - - http://groups.google.com/groups?selm=82ld3v%2480i%241%40mamenchi.zrz.TU-Berlin.DE - -which says: - - Newsgroups: comp.sys.hp.hpux - Subject: Re: Did someone made tcpdump working on 10.20 ? - Date: 12/08/1999 - From: Lutz Jaenicke - - In article <82ks5i$5vc$1@news1.dti.ne.jp>, mtsat - wrote: - >Hello, - > - >I downloaded and compiled tcpdump3.4 a couple of week ago. I tried to use - >it, but I can only see incoming data, never outgoing. - >Someone (raj) explained me that a patch was missing, and that this patch - >must me "patched" (poked) in order to see outbound data in promiscuous mode. - >Many things to do .... So the question is : did someone has already this - >"ready to use" PHNE_**** patch ? - - Two things: - 1. You do need a late "LAN products cumulative patch" (e.g. PHNE_18173 - for s700/10.20). - 2. You must use -echo 'lanc_outbound_promisc_flag/W1' | /usr/bin/adb -w /stand/vmunix /dev/kmem - You can insert this e.g. into /sbin/init.d/lan - - Best regards, - Lutz - -and - - http://groups.google.com/groups?selm=88cf4t%24p03%241%40web1.cup.hp.com - -which says: - - Newsgroups: comp.sys.hp.hpux - Subject: Re: tcpdump only shows incoming packets - Date: 02/15/2000 - From: Rick Jones - - Harald Skotnes wrote: - > I am running HPUX 11.0 on a C200 hanging on a 100Mb switch. I have - > compiled libpcap-0.4 an tcpdump-3.4 and it seems to work. But at a - > closer look I only get to see the incoming packets not the - > outgoing. I have tried tcpflow-0.12 which also uses libpcap and the - > same thing happens. Could someone please give me a hint on how to - > get this right? - - Search/Read the archives ?-) - - What you are seeing is expected, un-patched, behaviour for an HP-UX - system. On 11.00, you need to install the latest lancommon/DLPI - patches, and then the latest driver patch for the interface(s) in use. - At that point, a miracle happens and you should start seeing outbound - traffic. - -[That article also mentions the patch that appears below.] - -and - - http://groups.google.com/groups?selm=38AA973E.96BE7DF7%40cc.uit.no - -which says: - - Newsgroups: comp.sys.hp.hpux - Subject: Re: tcpdump only shows incoming packets - Date: 02/16/2000 - From: Harald Skotnes - - Rick Jones wrote: - - ... - - > What you are seeing is expected, un-patched, behaviour for an HP-UX - > system. On 11.00, you need to install the latest lancommon/DLPI - > patches, and then the latest driver patch for the interface(s) in - > use. At that point, a miracle happens and you should start seeing - > outbound traffic. - - Thanks a lot. I have this problem on several machines running HPUX - 10.20 and 11.00. The machines where patched up before y2k so did not - know what to think. Anyway I have now installed PHNE_19766, - PHNE_19826, PHNE_20008, PHNE_20735 on the C200 and now I can see the - outbound traffic too. Thanks again. - -(although those patches may not be the ones to install - there may be -later patches). - -And another message to tcpdump-workers@tcpdump.org, from Rick Jones: - - Date: Mon, 29 Apr 2002 15:59:55 -0700 - From: Rick Jones - To: tcpdump-workers@tcpdump.org - Subject: Re: [tcpdump-workers] I Can't Capture the Outbound Traffic - - ... - - http://itrc.hp.com/ would be one place to start in a search for the most - up-to-date patches for DLPI and the lan driver(s) used on your system (I - cannot guess because 9000/800 is too generic - one hs to use the "model" - command these days and/or an ioscan command (see manpage) to guess what - the drivers (btlan[3456], gelan, etc) might be involved in addition to - DLPI. - - Another option is to upgrade to 11i as outbound promiscuous mode support - is there in the base OS, no patches required. - -Another posting: - - http://groups.google.com/groups?selm=7d6gvn%24b3%241%40ocean.cup.hp.com - -indicates that you need to install the optional STREAMS product to do -captures on HP-UX 9.x: - - Newsgroups: comp.sys.hp.hpux - Subject: Re: tcpdump HP/UX 9.x - Date: 03/22/1999 - From: Rick Jones - - Dave Barr (barr@cis.ohio-state.edu) wrote: - : Has anyone ported tcpdump (or something similar) to HP/UX 9.x? - - I'm reasonably confident that any port of tcpdump to 9.X would require - the (then optional) STREAMS product. This would bring DLPI, which is - what one uses to access interfaces in promiscuous mode. - - I'm not sure that HP even sells the 9.X STREAMS product any longer, - since HP-UX 9.X is off the pricelist (well, maybe 9.10 for the old 68K - devices). - - Your best bet is to be up on 10.20 or better if that is at all - possible. If your hardware is supported by it, I'd go with HP-UX 11. - If you want to see the system's own outbound traffic, you'll never get - that functionality on 9.X, but it might happen at some point for 10.20 - and 11.X. - - rick jones - -(as per other messages cited here, the ability to see the system's own -outbound traffic did happen). - -Rick Jones reports that HP-UX 11i needs no patches for outbound -promiscuous mode support. - -An additional note, from Jost Martin, for HP-UX 10.20: - - Q: How do I get ethereral on HPUX to capture the _outgoing_ packets - of an interface - A: You need to get PHNE_20892,PHNE_20725 and PHCO_10947 (or - newer, this is as of 4.4.00) and its dependencies. Then you can - enable the feature as descibed below: - - Patch Name: PHNE_20892 - Patch Description: s700 10.20 PCI 100Base-T cumulative patch - To trace the outbound packets, please do the following - to turn on a global promiscuous switch before running - the promiscuous applications like snoop or tcpdump: - - adb -w /stand/vmunix /dev/mem - lanc_outbound_promisc_flag/W 1 - (adb will echo the result showing that the flag has - been changed) - $quit - (Thanks for this part to HP-support, Ratingen) - - The attached hack does this and some security-related stuff - (thanks to hildeb@www.stahl.bau.tu-bs.de (Ralf Hildebrandt) who - posted the security-part some time ago) - - <> - - (Don't switch IP-forwarding off, if you need it !) - Install the hack as /sbin/init.d/hacl_ip_stack (adjust - permissions !) and make a sequencing-symlink - /sbin/rc2.d/S350hack_ip_stack pointing to this script. - Now all this is done on every reboot. - -According to Rick Jones, the global promiscuous switch also has to be -turned on for HP-UX 11.00, but not for 11i - and, in fact, the switch -doesn't even exist on 11i. - -Here's the "hack_ip_stack" script: - ------------------------------------Cut Here------------------------------------- -#!/sbin/sh -# -# nettune: hack kernel parms for safety - -OKAY=0 -ERROR=-1 - -# /usr/contrib/bin fuer nettune auf Pfad -PATH=/sbin:/usr/sbin:/usr/bin:/usr/contrib/bin -export PATH - - -########## -# main # -########## - -case $1 in - start_msg) - print "Tune IP-Stack for security" - exit $OKAY - ;; - - stop_msg) - print "This action is not applicable" - exit $OKAY - ;; - - stop) - exit $OKAY - ;; - - start) - ;; # fall through - - *) - print "USAGE: $0 {start_msg | stop_msg | start | stop}" >&2 - exit $ERROR - ;; - esac - -########### -# start # -########### - -# -# tcp-Sequence-Numbers nicht mehr inkrementieren sondern random -# Syn-Flood-Protection an -# ip_forwarding aus -# Source-Routing aus -# Ausgehende Packets an ethereal/tcpdump etc. - -/usr/contrib/bin/nettune -s tcp_random_seq 2 || exit $ERROR -/usr/contrib/bin/nettune -s hp_syn_protect 1 || exit $ERROR -/usr/contrib/bin/nettune -s ip_forwarding 0 || exit $ERROR -echo 'ip_block_source_routed/W1' | /usr/bin/adb -w /stand/vmunix /dev/kmem || exit $ERROR -echo 'lanc_outbound_promisc_flag/W 1' | adb -w /stand/vmunix /dev/mem || exit $ERROR - -exit $OKAY ------------------------------------Cut Here------------------------------------- diff --git a/contrib/libpcap/README.linux b/contrib/libpcap/README.linux deleted file mode 100644 index 226b2438b4f1..000000000000 --- a/contrib/libpcap/README.linux +++ /dev/null @@ -1,108 +0,0 @@ -In order for libpcap to be able to capture packets on a Linux system, -the "packet" protocol must be supported by your kernel. If it is not, -you may get error messages such as - - modprobe: can't locate module net-pf-17 - -in "/var/adm/messages", or may get messages such as - - socket: Address family not supported by protocol - -from applications using libpcap. - -You must configure the kernel with the CONFIG_PACKET option for this -protocol; the following note is from the Linux "Configure.help" file for -the 2.0[.x] kernel: - - Packet socket - CONFIG_PACKET - The Packet protocol is used by applications which communicate - directly with network devices without an intermediate network - protocol implemented in the kernel, e.g. tcpdump. If you want them - to work, choose Y. - - This driver is also available as a module called af_packet.o ( = - code which can be inserted in and removed from the running kernel - whenever you want). If you want to compile it as a module, say M - here and read Documentation/modules.txt; if you use modprobe or - kmod, you may also want to add "alias net-pf-17 af_packet" to - /etc/modules.conf. - -and the note for the 2.2[.x] kernel says: - - Packet socket - CONFIG_PACKET - The Packet protocol is used by applications which communicate - directly with network devices without an intermediate network - protocol implemented in the kernel, e.g. tcpdump. If you want them - to work, choose Y. This driver is also available as a module called - af_packet.o ( = code which can be inserted in and removed from the - running kernel whenever you want). If you want to compile it as a - module, say M here and read Documentation/modules.txt. You will - need to add 'alias net-pf-17 af_packet' to your /etc/conf.modules - file for the module version to function automatically. If unsure, - say Y. - -In addition, there is an option that, in 2.2 and later kernels, will -allow packet capture filters specified to programs such as tcpdump to be -executed in the kernel, so that packets that don't pass the filter won't -be copied from the kernel to the program, rather than having all packets -copied to the program and libpcap doing the filtering in user mode. - -Copying packets from the kernel to the program consumes a significant -amount of CPU, so filtering in the kernel can reduce the overhead of -capturing packets if a filter has been specified that discards a -significant number of packets. (If no filter is specified, it makes no -difference whether the filtering isn't performed in the kernel or isn't -performed in user mode. :-)) - -The option for this is the CONFIG_FILTER option; the "Configure.help" -file says: - - Socket filtering - CONFIG_FILTER - The Linux Socket Filter is derived from the Berkeley Packet Filter. - If you say Y here, user-space programs can attach a filter to any - socket and thereby tell the kernel that it should allow or disallow - certain types of data to get through the socket. Linux Socket - Filtering works on all socket types except TCP for now. See the text - file linux/Documentation/networking/filter.txt for more information. - If unsure, say N. - -Note that, by default, libpcap will, if libnl is present, build with it; -it uses libnl to support monitor mode on mac80211 devices. There is a -configuration option to disable building with libnl, but, if that option -is chosen, the monitor-mode APIs (as used by tcpdump's "-I" flag, and as -will probably be used by other applications in the future) won't work -properly on mac80211 devices. - -Linux's run-time linker allows shared libraries to be linked with other -shared libraries, which means that if an older version of a shared -library doesn't require routines from some other shared library, and a -later version of the shared library does require those routines, the -later version of the shared library can be linked with that other shared -library and, if it's otherwise binary-compatible with the older version, -can replace that older version without breaking applications built with -the older version, and without breaking configure scripts or the build -procedure for applications whose configure script doesn't use the -pcap-config script if they build with the shared library. (The build -procedure for applications whose configure scripts use the pcap-config -script if present will not break even if they build with the static -library.) - -Statistics: -Statistics reported by pcap are platform specific. The statistics -reported by pcap_stats on Linux are as follows: - -2.2.x -===== -ps_recv Number of packets that were accepted by the pcap filter -ps_drops Always 0, this statistic is not gatherd on this platform - -2.4.x -===== -ps_rec Number of packets that were accepted by the pcap filter -ps_drops Number of packets that had passed filtering but were not - passed on to pcap due to things like buffer shortage, etc. - This is useful because these are packets you are interested in - but won't be reported by, for example, tcpdump output. diff --git a/contrib/libpcap/README.septel b/contrib/libpcap/README.septel deleted file mode 100644 index fbc88df38af4..000000000000 --- a/contrib/libpcap/README.septel +++ /dev/null @@ -1,50 +0,0 @@ -The following instructions apply if you have a Linux platform and want -libpcap to support the Septel range of passive network monitoring cards -from Intel (http://www.intel.com) - -1) Install and build the Septel software distribution by following the -instructions supplied with that package. - -2) Configure libcap. To allow the 'configure' script to locate the Septel -software distribution use the '--with-septel' option: - - ./configure --with-septel=DIR - -where DIR is the root of the Septel software distribution, for example -/var/src/septel. - -By default (if you write only ./configure --with-septel) it takes -./../septel as argument for DIR. - -If the Septel software is correctly detected 'configure' will -report: - - checking whether we have Septel API... yes - -If 'configure' reports that there is no Septel API, the directory may have been -incorrectly specified or the Septel software was not built before configuring -libpcap. - -See also the libpcap INSTALL.txt file for further libpcap configuration -options. - -Building libpcap at this stage will include support for both the native -packet capture stream and for capturing from Septel cards. To build -libpcap with only Septel support specify the capture type as 'septel' -when configuring libpcap: - - ./configure --with-septel=DIR --with-pcap=septel - -Applications built with libpcap configured in this way will only detect Septel -cards and will not capture from the native OS packet stream. - -Note: As mentioned in pcap-septel.c we should first edit the system.txt -file to change the user part example (UPE) module id to 0xdd instead of -0x2d for technical reason. So this change in system.txt is crutial and -things will go wrong if it's not done. System.txt along with config.txt -are configuration files that are edited by the user before running the -gctload program that uses these files for initialising modules and -configuring parameters. - ----------------------------------------------------------------------- -for more information please contact me : gil_hoyek@hotmail.com diff --git a/contrib/libpcap/README.sita b/contrib/libpcap/README.sita deleted file mode 100644 index ee7a426846f0..000000000000 --- a/contrib/libpcap/README.sita +++ /dev/null @@ -1,64 +0,0 @@ -The following instructions apply if you have a Linux platform and want -libpcap to support the 'ACN' WAN/LAN router product from from SITA -(http://www.sita.aero) - -This might also work on non-Linux Unix-compatible platforms, but that -has not been tested. - -See also the libpcap INSTALL.txt file for further libpcap configuration -options. - -These additions/extensions have been made to PCAP to allow it to -capture packets from a SITA ACN device (and potentially others). - -To enable its support you need to ensure that the distribution has -a correct configure.in file; that can be created if neccessay by -using the normal autoconf procedure of: - -aclocal -autoconf -autoheader -automake - -Then run configure with the 'sita' option: - -./configure --with-sita - -Applications built with libpcap configured in this way will only detect SITA -ACN interfaces and will not capture from the native OS packet stream. - -The SITA extension provides a remote datascope operation for capturing -both WAN and LAN protocols. It effectively splits the operation of -PCAP into two halves. The top layer performs the majority of the -work, but interfaces via a TCP session to remote agents that -provide the lower layer functionality of actual sniffing and -filtering. More detailed information regarding the functions and -inter-device protocol and naming conventions are described in detail -in 'pcap-sita.html'. - -pcap_findalldevs() reads the local system's /etc/hosts file looking -for host names that match the format of IOP type devices. ie. aaa_I_x_y -and then queries each associated IP address for a list of its WAN and -LAN devices. The local system the aggregates the lists obtained from -each IOP, sorts it, and provides it (to Wireshark et.al) as the -list of monitorable interfaces. - -Once a valid interface has been selected, pcap_open() is called -which opens a TCP session (to a well known port) on the target IOP -and tells it to start monitoring. - -All captured packets are then forwarded across that TCP session -back to the local 'top layer' for forwarding to the actual -sniffing program (wireshark...) - -Note that the DLT_SITA link-layer type includes a proprietary header -that is documented as part of the SITA dissector of Wireshark and is -also described in 'pcap-sita.html' for posterity sake. - -That header provides: -- Packet direction (in/out) (1 octet) -- Link layer hardware signal status (1 octet) -- Transmit/Receive error status (2 octets) -- Encapsulated WAN protocol ID (1 octet) - -