Remove more unused files.

5 files changed, 0 insertions, 590 deletions

diff --git a/contrib/libpcap/README.dag b/contrib/libpcap/README.dag
deleted file mode 100644
index acf97ed..0000000
--- 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 <support@endace.com>.
-
-Please also visit our Web site at:
-
-        http://www.endace.com/
-
-For more information about Endace DAG cards contact <sales@endace.com>.
diff --git a/contrib/libpcap/README.hpux b/contrib/libpcap/README.hpux
deleted file mode 100644
index 88c27f8..0000000
--- 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 <jaenicke@emserv1.ee.TU-Berlin.DE>
-
-  In article <82ks5i$5vc$1@news1.dti.ne.jp>, mtsat <mtsat@iris.dti.ne.jp>
-  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 <foo@bar.baz.invalid>
-
-  Harald Skotnes <harald@cc.uit.no> 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 <harald@cc.uit.no>
-
-  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 <foo@bar.baz>
-
-  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)
-
-		 <<hack_ip_stack>> 
-
-		(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 226b243..0000000
--- 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 fbc88df..0000000
--- 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 ee7a426..0000000
--- 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)
-
-