wireshark/wiretap
Guy Harris 252230934a Add Wiretap encapsulation type for IEEE 802.16 MAC Common Part Sublayer,
for which a DLT_ value and LINKTYPE_ value have just been assigned.

svn path=/trunk/; revision=20003
2006-11-27 18:10:12 +00:00
..
5views.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
5views.h
AUTHORS Rename the main executable to "wireshark", along with more conversions: 2006-05-31 19:12:15 +00:00
CMakeLists.txt Parts of http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1179 2006-10-24 17:39:32 +00:00
COPYING
ChangeLog
INSTALL Ethereal -> Wireshark 2006-06-06 23:09:20 +00:00
Makefile.am If we have to use Lex or Flex, check whether we found it, first, and if 2006-10-19 07:45:10 +00:00
Makefile.common name change 2006-05-21 05:12:17 +00:00
Makefile.nmake Add makefile.nmake 2006-02-22 06:06:21 +00:00
NEWS ethereal->wireshark updates 2006-05-22 08:14:01 +00:00
README Ethereal -> Wireshark 2006-06-06 23:09:20 +00:00
README.airmagnet
README.developer Update to describe all that the read routine needs to return, and to 2006-11-07 19:25:32 +00:00
acinclude.m4 Ethereal -> Wireshark 2006-06-06 23:09:20 +00:00
airopeek9.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
airopeek9.h
ascend-grammar.y change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
ascend-int.h change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
ascend-scanner.l From Ignacio Goyret 2005-10-11 19:55:55 +00:00
ascend.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
ascend.h
atm.c "aalt5_len" in the ATM pseudo-header is not guaranteed to be set to a 2005-10-18 10:39:23 +00:00
atm.h
ber.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
ber.h Basic Encoding Rules (BER) encoded file reading. Not really a packet trace format but still useful for dissecting arbitrary BER/DER ASN.1. 2006-05-08 19:56:36 +00:00
buffer.c
buffer.h
catapult_dct2000.c both recent fixes of warnings don't compile on Win32, inttypes.h is not available and PRId64 is not defined in the config.h.win32. 2006-11-18 03:37:34 +00:00
catapult_dct2000.h - Fix problems with parsing sctpprim headers 2006-10-23 17:22:20 +00:00
config.h.win32 replace *a lot* of file related calls by their GLib counterparts. This is necessary for the switch to GTK 2.6 (at least on WIN32). 2005-11-06 22:43:25 +00:00
configure.in Change ETH_VAR_IMPORT to WS_VAR_IMPORT. Try to fix a duplicate variable 2006-06-20 18:30:54 +00:00
cosine.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
cosine.h
csids.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
csids.h
dbs-etherwatch.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
dbs-etherwatch.h
erf.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
erf.h
etherpeek.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
etherpeek.h
eyesdn.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
eyesdn.h
file_access.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
file_util.h name change 2006-05-21 05:12:17 +00:00
file_wrappers.c fix the return value of file_seek, as noted by Steve 2006-11-06 00:24:24 +00:00
file_wrappers.h change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
hcidump.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
hcidump.h
i4b_trace.h
i4btrace.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
i4btrace.h
iptrace.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
iptrace.h
iseries.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
iseries.h From Martin Warnes: 2005-11-25 20:30:42 +00:00
k12.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
k12.h
lanalyzer.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
lanalyzer.h
libpcap.c Add a plain "radiotap.channel" field to the radiotap dissector. 2006-11-12 00:52:05 +00:00
libpcap.h Add support for slightly modified libpcap file format with nanosecond resolution (currently supported by Ethereal only). Support for both read and write was added. 2005-08-30 09:43:47 +00:00
netmon.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
netmon.h
nettl.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
nettl.h
network_instruments.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
network_instruments.h The first item in the network load EIP appears to be the network 2006-04-19 03:42:06 +00:00
netxray.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
netxray.h
ngsniffer.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
ngsniffer.h
pppdump.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
pppdump.h
radcom.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
radcom.h
snoop.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
snoop.h
toshiba.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
toshiba.h
visual.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
visual.h
vms.c change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
vms.h
wtap-capture.h
wtap-int.h change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct. 2006-11-05 22:46:44 +00:00
wtap.c Add Wiretap encapsulation type for IEEE 802.16 MAC Common Part Sublayer, 2006-11-27 18:10:12 +00:00
wtap.def add file extension information (filter "*.pcap;*.cap" and default extension ".pcap") to wiretap 2006-06-23 18:20:34 +00:00
wtap.h Add Wiretap encapsulation type for IEEE 802.16 MAC Common Part Sublayer, 2006-11-27 18:10:12 +00:00

README

$Id$

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 Wireshark
(http://www.wireshark.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 pseudomachine. 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. Wiretap has no filter capability at present; it currently doesn't
support packet capture, so it wouldn't be useful there, and filtering
when reading a capture file is done by Wireshark, using a more powerful
filtering mechanism than that provided by BPF.


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 (compressed and uncompressed)
-------
The uncompressed 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 Gilbert
would be *very* interested in receiving a sample. (see 'AUTHORS' file
for our e-mail addresses).

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.

"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.  AIX 3 uses
the iptrace 1.0 file format, while AIX4 uses iptrace 2.0.  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.

Sniffer Basic (NetXRay)/Windows Sniffer Pro
-------------------------------------------
Network Associates' Sniffer Basic (formerly NetXRay from Cinco Networks)
file format is now supported, at least for Ethernet and token-ring. 
Network Associates' Windows Sniffer Pro appears to use a variant of that
format; it's supported to the same extent.

RADCOM WAN/LAN Analyzers
------------------------
Olivier Abad has added code to read Ethernet and LAPB captures from
RADCOM WAN/LAN Analyzers (see http://www.radcom-inc.com/).

Lucent/Ascend access products
-----------------------------
Gerald

HP-UX nettl
-----------
nettl is used on HP-UX to trace various streams based subsystems.  Wiretap
can read nettl files containing IP frames (NS_LS_IP subsystem) and LAPB
frames (SX25L2 subsystem). It has been tested with files generated on
HP-UX 9.04 and 10.20.
Use the following commands to generate a trace :
# IP capture. 0x30000000 means PDU in and PDU out :
nettl -tn 0x30000000 -e NS_LS_IP -f tracefile
# X25 capture. You must specify an interface :
nettl -tn 0x30000000 -e SX25l2 -d /dev/x25_0 -f tracefile
# stop capture. subsystem is NS_LS_IP or SX25L2 :
nettl -tf -e subsystem

One may be able to specify "-tn pduin pduout" rather than
"-tn 0x30000000"; the nettl man page for HP-UX 10.30 implies that it
should work.

There is also basic support for nettl files containing NS_LS_DRIVER, 
NS_LS_TCP, NS_LS_UDP, NS_LS_LOOPBACK, unknown type 0xb9, and NS_LS_ICMP.
However, NS_LS_ICMP will not be decoded since WTAP lacks a raw ICMP 
encapsulation type.


Toshiba ISDN Router
-------------------
An under-documented command that the router supports in a telnet session
is "snoop" (not related to the Solaris "snoop" command). If you give
it the "dump" option (either by letting "snoop" query you for its next
argument, or typing "snoop dump" on the command line), you'll get a hex
dump of all packets across the router (except of your own telnet session
-- good thinking Toshiba!). You can select a certain channel to sniff
(LAN, B1, B2, D), but the default is all channels.  You save this hex
dump to disk with 'script' or by 'telnet | tee'. Wiretap will read the
ASCII hex dump and convert it to binary data.

ISDN4BSD "i4btrace" utility
---------------------------
Bert Driehuis

Cisco Secure Intrustion Detection System iplogging facility
-----------------------------------------------------------
Mike Hall

pppd logs (pppdump-format files)
--------------------------------
Gilbert

VMS TCPTRACE
------------
Compaq VMS's TCPIPTRACE format is supported.  This is the capture program
that comes with TCP/IP or UCX as supplied by Compaq or Digital Equipment
Corporation.

Under UCX 4.x, it is invoked as TCPIPTRACE.  Under TCPIP 5.x, it is invoked
as TCPTRACE.

TCPTRACE produces an ascii text based format, that has changed slightly over
time.

DBS Etherwatch (text format)
----------------------------
Text output from DBS Etherwatch is supported.  DBS Etherwatch is available
from: http://www.users.bigpond.com/dbsneddon/software.htm.

Catapult DCT2000 (.out files)
-----------------------------
DCT2000 test systems produce ascii text-based .out files for ports
that have logging enabled. When being read, the data part of the message is
prefixed with a short header that provides some context (context+port,
direction, original timestamp, etc).

You can choose to suppress the reading of non-standard protocols
(i.e. messages between layers rather than the well-known link-level protocols
usually found on board ports).


Gilbert Ramirez <gram@alumni.rice.edu>
Guy Harris <guy@alum.mit.edu>