79 lines
3.2 KiB
Plaintext
79 lines
3.2 KiB
Plaintext
$Id: README,v 1.5 1999/01/02 06:10:55 gram Exp $
|
|
|
|
Wiretap is a library that is being developed as a future replacement for
|
|
libpcap, the current standard Unix library for packet capturing. Libpcap is
|
|
great in that it is very platform independent and has a wonderful BPF
|
|
optimizing engine. But it has some shortcomings as well. These shortcomings
|
|
came to a head during the development of Ethereal (http://ethereal.zing.org),
|
|
a packet analyzer. As such, I began developing wiretap so that:
|
|
|
|
1. The library can easily be amended with new packet filtering objects.
|
|
Libpcap is very TCP/IP-oriented. I want to filter on IPX objects, SNA objects,
|
|
etc. I also want any decent programmer to be able to add new filters to the
|
|
library.
|
|
|
|
2. The library can read file formats from many packet-capturing utilities.
|
|
Libpcap only reads Libpcap files.
|
|
|
|
3. The library can capture on more than one network interface at a time, and
|
|
save this trace in one file.
|
|
|
|
4. Network names can be resolved immediately after a trace and saved in the
|
|
trace file. That way, I can ship a trace of my firewall-protected network to a
|
|
colleague, and he'll see the proper hostnames for the IP addresses in the
|
|
packet capture, even though he doesn't have access to the DNS server behind my
|
|
LAN's firewall.
|
|
|
|
5. I want to look into the possibility of compressing packet data when saved
|
|
to a file, like Sniffer.
|
|
|
|
6. The packet-filter can be optimized for the host OS. Not all OSes have BPF;
|
|
SunOS has NIT and Solaris has DLPI, which both use the CMU/Stanford
|
|
packet-filter psuedomachine. RMON has another type of packet-filter syntax
|
|
which we could support.
|
|
|
|
Currently, only #2 is available. Wiretap doesn't even do any filtering yet. It
|
|
can only be used to read packet capture files.
|
|
|
|
File Formats
|
|
============
|
|
|
|
Libpcap
|
|
-------
|
|
The "libpcap" file format was determined by reading the "libpcap" code;
|
|
wiretap reads the "libpcap" file format with its own code, rather than
|
|
using the "libpcap" library's code to read it.
|
|
|
|
Sniffer (uncompressed)
|
|
-------
|
|
The Sniffer format is documented in the Sniffer manual. Unfortunately,
|
|
Sniffer manuals tend to document only the format for the Sniffer model
|
|
they document. Token-Ring and ethernet seems to work well, though.
|
|
If you have an ATM Sniffer file, both Guy and I would be *very*
|
|
interested in receiving a sample. (see 'AUTHORS' file for our e-mail
|
|
addresses). When using LANE, the ATM Sniffer appears to record the emulated
|
|
LAN information; that is, only the ethernet or token-ring information is
|
|
stored in the trace file, not any information about ATM cells.
|
|
|
|
LANalyzer
|
|
---------
|
|
The LANalyzer format is available from http://www.novell.com. Search their
|
|
knowledge base for "Trace File Format".
|
|
|
|
"snoop"
|
|
-------
|
|
The Solaris 2.x "snoop" program's format is documented in RFC 1761.
|
|
|
|
"iptrace"
|
|
---------
|
|
This is the capture program that comes with AIX 3.x and 4.x. It has an
|
|
undocumented, yet very simple, file format. The interesting thing about
|
|
iptrace is that it will record packets coming in from all network interfaces;
|
|
a single iptrace file can contain multiple datalink types. I have tested
|
|
iptrace on ethernet and token-ring; if you can provide an iptrace file with
|
|
any other datalink type, I would appreciate a copy. (with the output from
|
|
'ipreport' too, if possible).
|
|
|
|
Gilbert Ramirez
|
|
<gram@verdict.uthscsa.edu>
|