275 lines
10 KiB
Plaintext
275 lines
10 KiB
Plaintext
++++++++++++++++++++++++++++++++++++++
|
|
<!-- WSUG Appendix Tools -->
|
|
++++++++++++++++++++++++++++++++++++++
|
|
|
|
[[AppTools]]
|
|
|
|
[appendix]
|
|
== Related command line tools
|
|
|
|
[[AppToolsIntroduction]]
|
|
|
|
=== Introduction
|
|
|
|
Along with the main application, Wireshark comes with an array of
|
|
command line tools which can be helpful for specialized tasks. Some of
|
|
these tools will be described in this chapter. You can find more
|
|
information about all of Wireshark's command line tools on
|
|
link:{wireshark-man-page-url}[the web site].
|
|
|
|
[[AppToolstshark]]
|
|
|
|
=== __tshark__: Terminal-based Wireshark
|
|
|
|
TShark is a terminal oriented version of Wireshark designed for capturing and
|
|
displaying packets when an interactive user interface isn't necessary or
|
|
available. It supports the same options as `wireshark`. For more information on
|
|
`tshark` see the manual pages (`man tshark`).
|
|
|
|
[[AppToolstsharkEx]]
|
|
.Help information available from `tshark`
|
|
----
|
|
include::tshark-h.txt[]
|
|
----
|
|
|
|
[[AppToolstcpdump]]
|
|
|
|
=== __tcpdump__: Capturing with `tcpdump` for viewing with Wireshark
|
|
|
|
It's often more useful to capture packets using `tcpdump` rather than
|
|
`wireshark`. For example, you might want to do a remote capture and either don't
|
|
have GUI access or don't have Wireshark installed on the remote machine.
|
|
|
|
Older versions of `tcpdump` truncate packets to 68 or 96 bytes. If this is the case,
|
|
use `-s` to capture full-sized packets:
|
|
|
|
----
|
|
$ tcpdump -i <interface> -s 65535 -w <some-file>
|
|
----
|
|
|
|
You will have to specify the correct _interface_ and the name of a _file_ to
|
|
save into. In addition, you will have to terminate the capture with ^C when you
|
|
believe you have captured enough packets.
|
|
|
|
+tcpdump+ is not part of the Wireshark distribution. You can get it from
|
|
{tcpdump-main-url} or as a standard package in most Linux distributions.
|
|
|
|
[[AppToolsdumpcap]]
|
|
|
|
=== __dumpcap__: Capturing with `dumpcap` for viewing with Wireshark
|
|
|
|
Dumpcap is a network traffic dump tool. It captures packet data from a live
|
|
network and writes the packets to a file. Dumpcap's native capture file format
|
|
is pcapng, which is also the format used by Wireshark.
|
|
|
|
Without any options set it will use the pcap library to capture traffic from the
|
|
first available network interface and write the received raw packet data, along
|
|
with the packets' time stamps into a pcapng file. The capture filter syntax
|
|
follows the rules of the pcap library.
|
|
|
|
[[AppToolsdumpcapEx]]
|
|
.Help information available from `dumpcap`
|
|
----
|
|
include::dumpcap-h.txt[]
|
|
----
|
|
|
|
[[AppToolscapinfos]]
|
|
|
|
=== __capinfos__: Print information about capture files
|
|
|
|
+capinfos+ can print information about binary capture files.
|
|
|
|
[[AppToolscapinfosEx]]
|
|
.Help information available from `capinfos`
|
|
----
|
|
include::capinfos-h.txt[]
|
|
----
|
|
|
|
[[AppToolsrawshark]]
|
|
|
|
=== __rawshark__: Dump and analyze network traffic.
|
|
|
|
Rawshark reads a stream of packets from a file or pipe, and prints a line
|
|
describing its output, followed by a set of matching fields for each packet on
|
|
stdout.
|
|
|
|
[[AppToolsrawsharkEx]]
|
|
.Help information available from `rawshark`
|
|
----
|
|
include::rawshark-h.txt[]
|
|
----
|
|
|
|
[[AppToolseditcap]]
|
|
|
|
=== __editcap__: Edit capture files
|
|
|
|
+editcap+ is a general-purpose utility for modifying capture files. Its main
|
|
function is to remove packets from capture files, but it can also be used to
|
|
convert capture files from one format to another, as well as to print
|
|
information about capture files.
|
|
|
|
[[AppToolseditcapEx]]
|
|
.Help information available from editcap
|
|
----
|
|
include::editcap-h.txt[]
|
|
----
|
|
|
|
[[AppToolseditcapEx1]]
|
|
.Capture file types available from `editcap -F`
|
|
----
|
|
include::editcap-F.txt[]
|
|
----
|
|
|
|
[[AppToolseditcapEx2]]
|
|
.Encapsulation types available from `editcap -T`
|
|
|
|
----
|
|
include::editcap-T.txt[]
|
|
----
|
|
|
|
[[AppToolsmergecap]]
|
|
|
|
=== __mergecap__: Merging multiple capture files into one
|
|
|
|
Mergecap is a program that combines multiple saved capture files into a single
|
|
output file specified by the `-w` argument. Mergecap knows how to read libpcap
|
|
capture files, including those of tcpdump. In addition, Mergecap can read
|
|
capture files from snoop (including Shomiti) and atmsnoop, LanAlyzer, Sniffer
|
|
(compressed or uncompressed), Microsoft Network Monitor, AIX's iptrace, NetXray,
|
|
Sniffer Pro, RADCOM's WAN/LAN analyzer, Lucent/Ascend router debug output,
|
|
HP-UX's nettl, and the dump output from Toshiba's ISDN routers. There is no need
|
|
to tell Mergecap what type of file you are reading; it will determine the file
|
|
type by itself. Mergecap is also capable of reading any of these file formats if
|
|
they are compressed using `gzip`. Mergecap recognizes this directly from the
|
|
file; the ``$$.gz$$'' extension is not required for this purpose.
|
|
|
|
By default, it writes the capture file in pcapng format, and writes all of the
|
|
packets in the input capture files to the output file. The `-F` flag can be used
|
|
to specify the format in which to write the capture file; it can write the file
|
|
in libpcap format (standard libpcap format, a modified format used by some
|
|
patched versions of libpcap, the format used by Red Hat Linux 6.1, or the format
|
|
used by SuSE Linux 6.3), snoop format, uncompressed Sniffer format, Microsoft
|
|
Network Monitor 1.x format, and the format used by Windows-based versions of the
|
|
Sniffer software.
|
|
|
|
Packets from the input files are merged in chronological order based on each
|
|
frame's timestamp, unless the `-a` flag is specified. Mergecap assumes that
|
|
frames within a single capture file are already stored in chronological order.
|
|
When the `-a` flag is specified, packets are copied directly from each input
|
|
file to the output file, independent of each frame's timestamp.
|
|
|
|
If the `-s` flag is used to specify a snapshot length, frames in the input file
|
|
with more captured data than the specified snapshot length will have only the
|
|
amount of data specified by the snapshot length written to the output file. This
|
|
may be useful if the program that is to read the output file cannot handle
|
|
packets larger than a certain size (for example, the versions of snoop in
|
|
Solaris 2.5.1 and Solaris 2.6 appear to reject Ethernet frames larger than the
|
|
standard Ethernet MTU, making them incapable of handling gigabit Ethernet
|
|
captures if jumbo frames were used).
|
|
|
|
If the `-T` flag is used to specify an encapsulation type, the encapsulation
|
|
type of the output capture file will be forced to the specified type, rather
|
|
than being the type appropriate to the encapsulation type of the input capture
|
|
file. Note that this merely forces the encapsulation type of the output file to
|
|
be the specified type; the packet headers of the packets will not be translated
|
|
from the encapsulation type of the input capture file to the specified
|
|
encapsulation type (for example, it will not translate an Ethernet capture to an
|
|
FDDI capture if an Ethernet capture is read and `-T fddi` is specified).
|
|
|
|
[[AppToolsmergecapEx]]
|
|
.Help information available from `mergecap`
|
|
----
|
|
include::mergecap-h.txt[]
|
|
----
|
|
|
|
A simple example merging `dhcp-capture.pcapng` and `imap-1.pcapng` into
|
|
`outfile.pcapng` is shown below.
|
|
|
|
[[AppToolsmergecapExSimple]]
|
|
.Simple example of using mergecap
|
|
----
|
|
$ mergecap -w outfile.pcapng dhcp-capture.pcapng imap-1.pcapng
|
|
----
|
|
|
|
[[AppToolstext2pcap]]
|
|
|
|
=== __text2pcap__: Converting ASCII hexdumps to network captures
|
|
|
|
There may be some occasions when you wish to convert a hex dump of some network
|
|
traffic into a libpcap file.
|
|
|
|
+text2pcap+ is a program that reads in an ASCII hex dump and writes the data
|
|
described into a libpcap-style capture file. text2pcap can read hexdumps with
|
|
multiple packets in them, and build a capture file of multiple packets.
|
|
`text2pcap` is also capable of generating dummy Ethernet, IP and UDP headers, in
|
|
order to build fully processable packet dumps from hexdumps of application-level
|
|
data only.
|
|
|
|
+text2pcap+ understands a hexdump of the form generated by `od -A x -t x1`. In
|
|
other words, each byte is individually displayed and surrounded with a space.
|
|
Each line begins with an offset describing the position in the file. The offset
|
|
is a hex number (can also be octal - see `-o`), of more than two hex digits. Here
|
|
is a sample dump that `text2pcap` can recognize:
|
|
|
|
----
|
|
000000 00 e0 1e a7 05 6f 00 10 ........
|
|
000008 5a a0 b9 12 08 00 46 00 ........
|
|
000010 03 68 00 00 00 00 0a 2e ........
|
|
000018 ee 33 0f 19 08 7f 0f 19 ........
|
|
000020 03 80 94 04 00 00 10 01 ........
|
|
000028 16 a2 0a 00 03 50 00 0c ........
|
|
000030 01 01 0f 19 03 80 11 01 ........
|
|
----
|
|
|
|
There is no limit on the width or number of bytes per line. Also the text dump
|
|
at the end of the line is ignored. Bytes/hex numbers can be uppercase or
|
|
lowercase. Any text before the offset is ignored, including email forwarding
|
|
characters `>'. Any lines of text between the bytestring lines is ignored.
|
|
The offsets are used to track the bytes, so offsets must be correct. Any line
|
|
which has only bytes without a leading offset is ignored. An offset is
|
|
recognized as being a hex number longer than two characters. Any text after the
|
|
bytes is ignored (e.g. the character dump). Any hex numbers in this text are
|
|
also ignored. An offset of zero is indicative of starting a new packet, so a
|
|
single text file with a series of hexdumps can be converted into a packet
|
|
capture with multiple packets. Multiple packets are read in with timestamps
|
|
differing by one second each. In general, short of these restrictions, text2pcap
|
|
is pretty liberal about reading in hexdumps and has been tested with a variety
|
|
of mangled outputs (including being forwarded through email multiple times, with
|
|
limited line wrap etc.)
|
|
|
|
There are a couple of other special features to note. Any line where the first
|
|
non-whitespace character is '#' will be ignored as a comment. Any line beginning
|
|
with #TEXT2PCAP is a directive and options can be inserted after this command to
|
|
be processed by `text2pcap`. Currently there are no directives implemented; in the
|
|
future, these may be used to give more fine grained control on the dump and the
|
|
way it should be processed e.g. timestamps, encapsulation type etc.
|
|
|
|
+text2pcap+ also allows the user to read in dumps of application-level data, by
|
|
inserting dummy L2, L3 and L4 headers before each packet. Possibilities include
|
|
inserting headers such as Ethernet, Ethernet + IP, Ethernet + IP + UDP, or
|
|
Ethernet + Ip + TCP before each packet. This allows Wireshark or any other
|
|
full-packet decoder to handle these dumps.
|
|
|
|
[[AppToolstext2pcapEx]]
|
|
.Help information available from text2pcap
|
|
|
|
----
|
|
include::mergecap-h.txt[]
|
|
----
|
|
|
|
[[AppToolsreordercap]]
|
|
|
|
=== __reordercap__: Reorder a capture file
|
|
|
|
+reordercap+ lets you reorder a capture file according to the packets timestamp.
|
|
|
|
[[AppToolsreordercapEx]]
|
|
.Help information available from reordercap
|
|
----
|
|
include::reordercap-h.txt[]
|
|
----
|
|
|
|
++++++++++++++++++++++++++++++++++++++
|
|
<!-- End of WSUG Appendix Tools -->
|
|
++++++++++++++++++++++++++++++++++++++
|