1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
|
$Id: README,v 1.12 1999/03/01 20:35:33 guy 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.
Wiretap is very good at reading many file formats, as per #2
above. Display filters are now appearing in wiretap, but they are
still basic. Development is continuing on the BPF compiler, so display
filters will continue to be enhanced. Wiretap can't capture packets yet,
but once it can, it will have the ability to do capture-filtering via
BPF, either through BPF kernel facilities or through a user-space BPF
implementation. BPF is my first target, but the filter compiler will
be generic enough so that as per #6, other packet-filtering engines can
be used.
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).
ATM sniffers are claimed by the manual to record a mixture of cells and
frames; there's currently no "raw ATM" encapsulation in wiretap to allow
us to return that directly, so we assume that the traffic of interest is
all LANE or all RFC 1483 traffic, search in the file for the first AAL5
frame that's either LANE or RFC 1483, set the encapsulation based on
which of those we saw, and discard all non-AAL5 cells as well as AAL5
frames not of the specified type. We also discard the 2-byte LANE
header at the front of the frame, leaving only the emulated Ethernet or
Token Ring frame.
Given that wiretap now returns packet encapsulation types on a
per-packet basis, we could, instead, discard all non-AAL5 cells and AAL5
frames that are neither LANE nor RFC 1483, and return the appropriate
encapsulation for the packet as we read it.
LANalyzer
---------
The LANalyzer format is available from http://www.novell.com. Search their
knowledge base for "Trace File Format".
Network Monitor
---------------
Microsoft's Network Monitor file format is supported, at least under Ethernet
and token-ring. If you have capture files of other datalink types, please send
them to Guy Harris.
"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. Right now
wiretap only supports iptrace 2.0 (AIX4) because I don't have access to
an AIX3 machine. iptrace 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).
Sniffer Basic (NetXRay)/Windows Sniffer Pro
-------------------------------------------
Network Associates' Sniffer Basic (formerly NetXRay from Cinco Networks)
file format is now partially supported; only Ethernet and Token Ring
captures can be read, and the packet time stamp isn't correctly
computed. Network Associates' Windows Sniffer Pro appears to use a
variant of that format; it's supported to the same extent.
Gilbert Ramirez <gram@verdict.uthscsa.edu>
Guy Harris <guy@netapp.com>
|
