summaryrefslogtreecommitdiffstats
path: root/wiretap/README
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-10 20:34:10 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-10 20:34:10 +0000
commite4ba6dbc3f1e76890b22773807ea37fe8fa2b1bc (patch)
tree68cb5ef9081156392f1dd62a00c6ccc1451b93df /wiretap/README
parentInitial commit. (diff)
downloadwireshark-e4ba6dbc3f1e76890b22773807ea37fe8fa2b1bc.tar.xz
wireshark-e4ba6dbc3f1e76890b22773807ea37fe8fa2b1bc.zip
Adding upstream version 4.2.2.upstream/4.2.2
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'wiretap/README')
-rw-r--r--wiretap/README186
1 files changed, 186 insertions, 0 deletions
diff --git a/wiretap/README b/wiretap/README
new file mode 100644
index 00000000..7b393ad4
--- /dev/null
+++ b/wiretap/README
@@ -0,0 +1,186 @@
+NOTE: this documents the original intent behind libwiretap. Currently,
+it is being developed solely as a library for reading capture files,
+rather than packet capture. The list of file formats is also
+out-of-date.
+
+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
+(https://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 https://web.archive.org/web/20031231213434/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 Intrusion 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: https://web.archive.org/web/20070612033348/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>
+
+STANAG 4607
+-----------
+Initial support for the STANAG 4607 protocol. Documentation at:
+https://web.archive.org/web/20130223054955/http://www.nato.int/structur/AC/224/standard/4607/4607.htm