d/freebsd-nq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Remove more unused files.

Browse Source
This commit is contained in:
Rui Paulo 2010-10-29 18:56:51 +00:00
parent 6aa7d503ce
commit b436d954c4
5 changed files with 0 additions and 590 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

114
contrib/libpcap/README.dag
View File

@ -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>.

254
contrib/libpcap/README.hpux
View File

@ -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-------------------------------------

108
contrib/libpcap/README.linux
View File

@ -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.

50
contrib/libpcap/README.septel
View File

@ -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

64
contrib/libpcap/README.sita
View File

@ -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)