forked from osmocom/wireshark
3001 lines
104 KiB
Plaintext
3001 lines
104 KiB
Plaintext
include::../docbook/attributes.adoc[]
|
|
= tshark(1)
|
|
:doctype: manpage
|
|
:stylesheet: ws.css
|
|
:linkcss:
|
|
:copycss: ../docbook/{stylesheet}
|
|
|
|
== NAME
|
|
|
|
tshark - Dump and analyze network traffic
|
|
|
|
== SYNOPSIS
|
|
|
|
[manarg]
|
|
*tshark*
|
|
[ *-i* <capture interface>|- ]
|
|
[ *-f* <capture filter> ]
|
|
[ *-2* ]
|
|
[ *-r* <infile> ]
|
|
[ *-w* <outfile>|- ]
|
|
[ *options* ]
|
|
[ <filter> ]
|
|
|
|
[manarg]
|
|
*tshark*
|
|
*-G* [ <report type> ] [ --elastic-mapping-filter <protocols> ]
|
|
|
|
== DESCRIPTION
|
|
|
|
*TShark* is a network protocol analyzer. It lets you capture packet
|
|
data from a live network, or read packets from a previously saved
|
|
capture file, either printing a decoded form of those packets to the
|
|
standard output or writing the packets to a file. *TShark*'s native
|
|
capture file format is *pcapng* format, which is also the format used
|
|
by *Wireshark* and various other tools.
|
|
|
|
Without any options set, *TShark* will work much like *tcpdump*. It
|
|
will use the pcap library to capture traffic from the first available
|
|
network interface and displays a summary line on the standard output for
|
|
each received packet.
|
|
|
|
When run with the *-r* option, specifying a capture file from which to
|
|
read, *TShark* will again work much like *tcpdump*, reading packets
|
|
from the file and displaying a summary line on the standard output for
|
|
each packet read. *TShark* is able to detect, read and write the same
|
|
capture files that are supported by *Wireshark*. The input file
|
|
doesn't need a specific filename extension; the file format and an
|
|
optional gzip, zstd or lz4 compression will be automatically detected. Near the
|
|
beginning of the DESCRIPTION section of xref:wireshark.html[wireshark](1) or
|
|
https://www.wireshark.org/docs/man-pages/wireshark.html is a detailed
|
|
description of the way *Wireshark* handles this, which is the same way
|
|
*TShark* handles this.
|
|
|
|
Compressed file support uses (and therefore requires) the zlib library.
|
|
If the zlib library is not present when compiling *TShark*, it will be
|
|
possible to compile it, but the resulting program will be unable to read
|
|
compressed files.
|
|
|
|
When displaying packets on the standard output, *TShark* writes, by
|
|
default, a summary line containing the fields specified by the
|
|
preferences file (which are also the fields displayed in the packet list
|
|
pane in *Wireshark*), although if it's writing packets as it captures
|
|
them, rather than writing packets from a saved capture file, it won't
|
|
show the "frame number" field. If the *-V* option is specified, it
|
|
instead writes a view of the details of the packet, showing all the
|
|
fields of all protocols in the packet. If the *-O* option is
|
|
specified, it will only show the full details for the protocols
|
|
specified, and show only the top-level detail line for all other
|
|
protocols. Use the output of "*tshark -G protocols*" to find the
|
|
abbreviations of the protocols you can specify. If the *-P* option is
|
|
specified with either the *-V* or *-O* options, both the summary line
|
|
for the entire packet and the details will be displayed.
|
|
|
|
Packet capturing is performed with the pcap library. That library
|
|
supports specifying a filter expression; packets that don't match that
|
|
filter are discarded. The *-f* option is used to specify a capture
|
|
filter. The syntax of a capture filter is defined by the pcap library;
|
|
this syntax is different from the display filter syntax described below,
|
|
and the filtering mechanism is limited in its abilities.
|
|
|
|
Display filters in *TShark*, which allow you to select which packets are
|
|
to be decoded or written to a file, are very powerful; more fields are
|
|
filterable in *TShark* than in other protocol analyzers, and the syntax
|
|
you can use to create your filters is richer. As *TShark* progresses,
|
|
expect more and more protocol fields to be allowed in display filters.
|
|
Display filters use the same syntax as display and color filters in
|
|
*Wireshark*; a display filter is specified with the *-Y* option.
|
|
|
|
Display filters can be specified when capturing or when reading from a
|
|
capture file. Note that capture filters are much more efficient
|
|
than display filters, and it may be more difficult for *TShark* to keep up
|
|
with a busy network if a display filter is specified for a live capture, so
|
|
you might be more likely to lose packets if you're using a display filter.
|
|
|
|
A capture or display filter can either be specified with the *-f* or *-Y*
|
|
option, respectively, in which case the entire filter expression must be
|
|
specified as a single argument (which means that if it contains spaces,
|
|
it must be quoted), or can be specified with command-line arguments
|
|
after the option arguments, in which case all the arguments after the
|
|
filter arguments are treated as a filter expression. If the filter is
|
|
specified with command-line arguments after the option arguments, it's a
|
|
capture filter if a capture is being done (i.e., if no *-r* option was
|
|
specified) and a display filter if a capture file is being read (i.e., if a
|
|
*-r* option was specified).
|
|
|
|
If the *-w* option is specified when capturing packets or reading from
|
|
a capture file, *TShark* does not display packets on the standard
|
|
output. Instead, it writes the packets to a capture file with the name
|
|
specified by the *-w* option. Note that display filters are currently
|
|
not supported when capturing and saving the captured packets.
|
|
|
|
If you want to write the decoded form of packets to a file, run
|
|
*TShark* without the *-w* option, and redirect its standard output to
|
|
the file (do __not__ use the *-w* option).
|
|
|
|
If you want the packets to be displayed to the standard output and also
|
|
saved to a file, specify the *-P* option in addition to the *-w*
|
|
option to have the summary line displayed, specify the *-V* option
|
|
in addition to the *-w* option to have the details of the packet
|
|
displayed, and specify the *-O* option, with a list of protocols, to
|
|
have the full details of the specified protocols and the top-level
|
|
detail line for all other protocols to be displayed. If the *-P*
|
|
option is used together with the *-V* or *-O* option, the summary line
|
|
will be displayed along with the detail lines.
|
|
|
|
When writing packets to a file, *TShark*, by default, writes the file
|
|
in *pcapng* format, and writes all of the packets it sees to the output
|
|
file. The *-F* option can be used to specify the format in which to
|
|
write the file. This list of available file formats is displayed by the
|
|
*-F* option without a value. However, you can't specify a file format
|
|
for a live capture.
|
|
|
|
When capturing packets, *TShark* writes to the standard error an
|
|
initial line listing the interfaces from which packets are being
|
|
captured and, if packet information isn't being displayed to the
|
|
terminal, writes a continuous count of packets captured to the standard
|
|
output. If the *-q* option is specified, neither the continuous count
|
|
nor the packet information will be displayed; instead, at the end of the
|
|
capture, a count of packets captured will be displayed. If the *-Q*
|
|
option is specified, neither the initial line, nor the packet
|
|
information, nor any packet counts will be displayed. If the *-q* or
|
|
*-Q* option is used, the *-P*, *-V*, or *-O* option can be used to
|
|
cause the corresponding output to be displayed even though other output
|
|
is suppressed.
|
|
|
|
When reading packets, the *-q* and *-Q* option will suppress the
|
|
display of the packet summary or details; this would be used if *-z*
|
|
options are specified in order to display statistics, so that only the
|
|
statistics, not the packet information, is displayed.
|
|
|
|
The *-G* option is a special mode that simply causes *TShark*
|
|
to dump one of several types of internal glossaries and then exit.
|
|
|
|
== OPTIONS
|
|
|
|
-2::
|
|
+
|
|
--
|
|
Perform a two-pass analysis. This causes *TShark* to buffer output until the
|
|
entire first pass is done, but allows it to fill in fields that require future
|
|
knowledge, such as 'response in frame #' fields. Also permits reassembly
|
|
frame dependencies to be calculated correctly.
|
|
--
|
|
|
|
-a|--autostop <capture autostop condition>::
|
|
+
|
|
--
|
|
Specify a criterion that specifies when *TShark* is to stop writing
|
|
to a capture file. The criterion is of the form __test:value__,
|
|
where __test__ is one of:
|
|
|
|
*duration*:__value__ Stop writing to a capture file after __value__ seconds
|
|
have elapsed. Floating point values (e.g. 0.5) are allowed.
|
|
|
|
*files*:__value__ Stop writing to capture files after __value__ number of files
|
|
were written.
|
|
|
|
*filesize*:__value__ Stop writing to a capture file after it reaches a size of
|
|
__value__ kB. If this option is used together with the -b option, *TShark*
|
|
will stop writing to the current capture file and switch to the next one if
|
|
filesize is reached. When reading a capture file, *TShark* will stop reading
|
|
the file after the number of bytes read exceeds this number (the complete
|
|
packet will be read, so more bytes than this number may be read). Note that
|
|
the filesize is limited to a maximum value of 2 GiB.
|
|
|
|
*packets*:__value__ switch to the next file after it contains __value__
|
|
packets.
|
|
This does not include any packets that do not pass the display filter, so it
|
|
may differ from *-c*<capture packet count>.
|
|
--
|
|
|
|
-A <user>:<password>::
|
|
+
|
|
--
|
|
Specify a user and a password when *TShark* captures from a rpcap:// interface
|
|
where authentication is required.
|
|
|
|
This option is available with libpcap with enabled remote support.
|
|
--
|
|
|
|
-b|--ring-buffer <capture ring buffer option>::
|
|
+
|
|
--
|
|
Cause *TShark* to run in "multiple files" mode. In "multiple files" mode,
|
|
*TShark* will write to several capture files. When the first capture file
|
|
fills up, *TShark* will switch writing to the next file and so on.
|
|
|
|
The created filenames are based on the filename given with the *-w* option,
|
|
the number of the file and on the creation date and time,
|
|
e.g. outfile_00001_20230714120117.pcap, outfile_00002_20230714120523.pcap, ...
|
|
|
|
With the __files__ option it's also possible to form a "ring buffer".
|
|
This will fill up new files until the number of files specified,
|
|
at which point *TShark* will discard the data in the first file and start
|
|
writing to that file and so on. If the __files__ option is not set,
|
|
new files filled up until one of the capture stop conditions match (or
|
|
until the disk is full).
|
|
|
|
The criterion is of the form __key:value__,
|
|
where __key__ is one of:
|
|
|
|
*duration*:__value__ switch to the next file after __value__ seconds have
|
|
elapsed, even if the current file is not completely filled up. Floating
|
|
point values (e.g. 0.5) are allowed.
|
|
|
|
*files*:__value__ begin again with the first file after __value__ number of
|
|
files were written (form a ring buffer). This value must be less than 100000.
|
|
Caution should be used when using large numbers of files: some filesystems do
|
|
not handle many files in a single directory well. The *files* criterion
|
|
requires either *duration*, *interval* or *filesize* to be specified to
|
|
control when to go to the next file. It should be noted that each *-b*
|
|
parameter takes exactly one criterion; to specify two criterion, each must be
|
|
preceded by the *-b* option.
|
|
|
|
*filesize*:__value__ switch to the next file after it reaches a size of
|
|
__value__ kB. Note that the filesize is limited to a maximum value of 2 GiB.
|
|
|
|
*interval*:__value__ switch to the next file when the time is an exact
|
|
multiple of __value__ seconds. For example, use 3600 to switch to a new file
|
|
every hour on the hour.
|
|
|
|
*packets*:__value__ switch to the next file after it contains __value__
|
|
packets.
|
|
|
|
*nametimenum*:__value__ Choose between two save filename templates. If
|
|
__value__ is 1, make running file number part before start time part; this is
|
|
the original and default behaviour (e.g. log_00001_20230714164426.pcap). If
|
|
__value__ is greater than 1, make start time part before running number part
|
|
(e.g. log_20210828164426_00001.pcap). The latter makes alphabetical sorting
|
|
order equal to creation time order, and keeps related multiple file sets in
|
|
same directory close to each other.
|
|
|
|
Example: *tshark -b filesize:1000 -b files:5* results in a ring buffer of five
|
|
files of size one megabyte each.
|
|
--
|
|
|
|
-B|--buffer-size <capture buffer size>::
|
|
+
|
|
--
|
|
Set capture buffer size (in MiB, default is 2 MiB). This is used by
|
|
the capture driver to buffer packet data until that data can be written
|
|
to disk. If you encounter packet drops while capturing, try to increase
|
|
this size. Note that, while *TShark* attempts to set the buffer size
|
|
to 2 MiB by default, and can be told to set it to a larger value, the
|
|
system or interface on which you're capturing might silently limit the
|
|
capture buffer size to a lower value or raise it to a higher value.
|
|
|
|
This is available on UNIX-compatible systems, such as Linux, macOS,
|
|
\*BSD, Solaris, and AIX, with libpcap 1.0.0 or later, and on Windows.
|
|
It is not available on UNIX-compatible systems with earlier versions of
|
|
libpcap.
|
|
|
|
This option can occur multiple times. If used before the first
|
|
occurrence of the *-i* option, it sets the default capture buffer size.
|
|
If used after an *-i* option, it sets the capture buffer size for
|
|
the interface specified by the last *-i* option occurring before
|
|
this option. If the capture buffer size is not set specifically,
|
|
the default capture buffer size is used instead.
|
|
--
|
|
|
|
-c <capture packet count>::
|
|
+
|
|
--
|
|
Set the maximum number of packets to read when capturing live
|
|
data.
|
|
If reading a capture file, set the maximum number of packets to read.
|
|
This includes any packets that do not pass the display filter, so it
|
|
may differ from *-a packets:*<capture packet count>.
|
|
--
|
|
|
|
-C <configuration profile>::
|
|
+
|
|
--
|
|
Run with the given configuration profile.
|
|
--
|
|
|
|
-d <layer type>==<selector>,<decode-as protocol>::
|
|
+
|
|
--
|
|
Like Wireshark's *Decode As...* feature, this lets you specify how a
|
|
layer type should be dissected. If the layer type in question (for example,
|
|
*tcp.port* or *udp.port* for a TCP or UDP port number) has the specified
|
|
selector value, packets should be dissected as the specified protocol.
|
|
|
|
Example: *tshark -d tcp.port==8888,http* will decode any traffic running over
|
|
TCP port 8888 as HTTP.
|
|
|
|
Example: *tshark -d tcp.port==8888:3,http* will decode any traffic running over
|
|
TCP ports 8888, 8889 or 8890 as HTTP.
|
|
|
|
Example: *tshark -d tcp.port==8888-8890,http* will decode any traffic running
|
|
over TCP ports 8888, 8889 or 8890 as HTTP.
|
|
|
|
Using an invalid selector or protocol will print out a list of valid selectors
|
|
and protocol names, respectively.
|
|
|
|
Example: *tshark -d .* is a quick way to get a list of valid selectors.
|
|
|
|
Example: *tshark -d ethertype==0x0800.* is a quick way to get a list of
|
|
protocols that can be selected with an ethertype.
|
|
--
|
|
|
|
-D|--list-interfaces::
|
|
+
|
|
--
|
|
Print a list of the interfaces on which *TShark* can capture, and
|
|
exit. For each network interface, a number and an interface name,
|
|
possibly followed by a text description of the interface, is printed.
|
|
The interface name or the number can be supplied to the *-i* flag to
|
|
specify an interface on which to capture. The number can be useful on
|
|
Windows systems, where the interfaces have long names that usually
|
|
contain a GUID.
|
|
--
|
|
|
|
-e <field>::
|
|
+
|
|
--
|
|
Add a field to the list of fields to display if *-T ek|fields|json|pdml*
|
|
is selected. This option can be used multiple times on the command line.
|
|
At least one field must be provided if the *-T fields* option is
|
|
selected. Column names may be used prefixed with "_ws.col."
|
|
|
|
Example: *tshark -e frame.number -e ip.addr -e udp -e _ws.col.Info*
|
|
|
|
Fields are separated by tab characters by default. *-E* controls the
|
|
format of the printed fields.
|
|
Giving a protocol rather than a single field will print the protocol summary
|
|
(subtree label) from the packet details as a single field.
|
|
If the protocol summary contains only the protocol name
|
|
(e.g. "Hypertext Transfer Protocol") then the protocol filter name ("http")
|
|
will be printed.
|
|
--
|
|
|
|
-E <field print option>::
|
|
+
|
|
--
|
|
Set an option controlling the printing of fields when *-T fields* is
|
|
selected.
|
|
|
|
Options are:
|
|
|
|
*bom=y|n* If *y*, prepend output with the UTF-8 byte order mark
|
|
(hexadecimal ef, bb, bf). Defaults to *n*.
|
|
|
|
*header=y|n* If *y*, print a list of the field names given using *-e*
|
|
as the first line of the output; the field name will be separated using
|
|
the same character as the field values. Defaults to *n*.
|
|
|
|
*separator=/t|/s|*<character> Set the separator character to
|
|
use for fields. If */t* tab will be used (this is the default), if
|
|
*/s*, a single space will be used. Otherwise any character that can be
|
|
accepted by the command line as part of the option may be used.
|
|
|
|
*occurrence=f|l|a* Select which occurrence to use for fields that have
|
|
multiple occurrences. If *f* the first occurrence will be used, if *l*
|
|
the last occurrence will be used and if *a* all occurrences will be used
|
|
(this is the default).
|
|
|
|
*aggregator=,|/s|*<character> Set the aggregator character to
|
|
use for fields that have multiple occurrences. If *,* a comma will be used
|
|
(this is the default), if */s*, a single space will be used. Otherwise
|
|
any character that can be accepted by the command line as part of the
|
|
option may be used.
|
|
|
|
*quote=d|s|n* Set the quote character to use to surround fields. *d*
|
|
uses double-quotes, *s* single-quotes, *n* no quotes (the default).
|
|
--
|
|
|
|
-f <capture filter>::
|
|
+
|
|
--
|
|
Set the capture filter expression.
|
|
|
|
This option can occur multiple times. If used before the first
|
|
occurrence of the *-i* option, it sets the default capture filter expression.
|
|
If used after an *-i* option, it sets the capture filter expression for
|
|
the interface specified by the last *-i* option occurring before
|
|
this option. If the capture filter expression is not set specifically,
|
|
the default capture filter expression is used if provided.
|
|
|
|
Pre-defined capture filter names, as shown in the GUI menu item Capture->Capture
|
|
Filters, can be used by prefixing the argument with "predef:".
|
|
Example: *tshark -f "predef:MyPredefinedHostOnlyFilter"*
|
|
--
|
|
|
|
-F <file format>::
|
|
+
|
|
--
|
|
Set the file format of the output capture file written using the *-w*
|
|
option. The output written with the *-w* option is raw packet data, not
|
|
text, so there is no *-F* option to request text output. The option *-F*
|
|
without a value will list the available formats.
|
|
--
|
|
|
|
-g::
|
|
+
|
|
--
|
|
This option causes the output file(s) to be created with group-read permission
|
|
(meaning that the output file(s) can be read by other members of the calling
|
|
user's group).
|
|
--
|
|
|
|
-G [ <report type> ]::
|
|
+
|
|
--
|
|
The *-G* option will cause *TShark* to dump one of several types of glossaries
|
|
and then exit. If no specific glossary type is specified, then the *fields*
|
|
report will be generated by default.
|
|
Using the report type of *help* lists all the current report types.
|
|
|
|
The available report types include:
|
|
|
|
*column-formats* Dumps the column formats understood by *TShark*.
|
|
There is one record per line. The fields are tab-delimited.
|
|
|
|
[horizontal]
|
|
Field 1:: format string (e.g. "%rD")
|
|
Field 2:: text description of format string (e.g. "Dest port (resolved)")
|
|
|
|
*currentprefs* Dumps a copy of the current preferences file to stdout.
|
|
|
|
*decodes* Dumps the "layer type"/"decode as" associations to stdout.
|
|
There is one record per line. The fields are tab-delimited.
|
|
|
|
[horizontal]
|
|
Field 1:: layer type, e.g. "tcp.port"
|
|
Field 2:: selector in decimal
|
|
Field 3:: "decode as" name, e.g. "http"
|
|
|
|
*defaultprefs* Dumps a default preferences file to stdout.
|
|
|
|
*dissector-tables* Dumps a list of dissector tables to stdout. There
|
|
is one record per line. The fields are tab-delimited.
|
|
|
|
[horizontal]
|
|
Field 1:: dissector table name, e.g. "tcp.port"
|
|
Field 2:: name used for the dissector table in the GUI
|
|
Field 3:: type (textual representation of the ftenum type)
|
|
Field 4:: base for display (for integer types)
|
|
Field 5:: protocol name
|
|
Field 6:: "decode as" support
|
|
|
|
*elastic-mapping* Dumps the ElasticSearch mapping file to stdout. Fields
|
|
falling in the default case (string) won't be mapped.
|
|
|
|
*fieldcount* Dumps the number of header fields to stdout.
|
|
|
|
*fields* Dumps the contents of the registration database to
|
|
stdout. An independent program can take this output and format it into nice
|
|
tables or HTML or whatever. There is one record per line. Each record is
|
|
either a protocol or a header field, differentiated by the first field.
|
|
The fields are tab-delimited.
|
|
|
|
.Protocols
|
|
[horizontal]
|
|
Field 1:: 'P'
|
|
Field 2:: descriptive protocol name
|
|
Field 3:: protocol abbreviation
|
|
|
|
.Header Fields
|
|
[horizontal]
|
|
Field 1:: 'F'
|
|
Field 2:: descriptive field name
|
|
Field 3:: field abbreviation
|
|
Field 4:: type (textual representation of the ftenum type)
|
|
Field 5:: parent protocol abbreviation
|
|
Field 6:: base for display (for integer types); "parent bitfield width" for FT_BOOLEAN
|
|
Field 7:: bitmask: format: hex: 0x....
|
|
Field 8:: blurb describing field
|
|
|
|
*folders* Dumps various folders used by *TShark*. This is essentially the
|
|
same data reported in Wireshark's About | Folders tab.
|
|
There is one record per line. The fields are tab-delimited.
|
|
|
|
[horizontal]
|
|
Field 1:: Folder type (e.g "Personal configuration:")
|
|
Field 2:: Folder location (e.g. "/home/vagrant/.config/wireshark/")
|
|
|
|
*ftypes* Dumps the "ftypes" (fundamental types) understood by *TShark*.
|
|
There is one record per line. The fields are tab-delimited.
|
|
|
|
[horizontal]
|
|
Field 1:: FTYPE (e.g "FT_IPv6")
|
|
Field 2:: text description of type (e.g. "IPv6 address")
|
|
|
|
*heuristic-decodes* Dumps the heuristic decodes currently installed.
|
|
There is one record per line. The fields are tab-delimited.
|
|
|
|
[horizontal]
|
|
Field 1:: underlying dissector (e.g. "tcp")
|
|
Field 2:: name of heuristic decoder (e.g. ucp")
|
|
Field 3:: heuristic enabled (e.g. "T" or "F")
|
|
|
|
*help* Displays the available report types.
|
|
|
|
*plugins* Dumps the plugins currently installed.
|
|
There is one record per line. The fields are tab-delimited.
|
|
|
|
[horizontal]
|
|
Field 1:: plugin library/Lua script/extcap executable (e.g. "gryphon.so")
|
|
Field 2:: plugin version (e.g. 0.0.4)
|
|
Field 3:: plugin type ("dissector", "tap", "file type", etc.)
|
|
Field 4:: full path to plugin file
|
|
|
|
*protocols* Dumps the protocols in the registration database to stdout.
|
|
An independent program can take this output and format it into nice tables
|
|
or HTML or whatever. There is one record per line. The fields are tab-delimited.
|
|
|
|
[horizontal]
|
|
Field 1:: protocol name
|
|
Field 2:: protocol short name
|
|
Field 3:: protocol filter name
|
|
|
|
*values* Dumps the value_strings, range_strings or true/false strings
|
|
for fields that have them. There is one record per line. Fields are
|
|
tab-delimited. There are three types of records: Value String, Range
|
|
String and True/False String. The first field, 'V', 'R' or 'T', indicates
|
|
the type of record.
|
|
|
|
.Value Strings
|
|
[horizontal]
|
|
Field 1:: 'V'
|
|
Field 2:: field abbreviation to which this value string corresponds
|
|
Field 3:: Integer value
|
|
Field 4:: String
|
|
|
|
.Range Strings
|
|
[horizontal]
|
|
Field 1:: 'R'
|
|
Field 2:: field abbreviation to which this range string corresponds
|
|
Field 3:: Integer value: lower bound
|
|
Field 4:: Integer value: upper bound
|
|
Field 5:: String
|
|
|
|
.True/False Strings
|
|
[horizontal]
|
|
Field 1:: 'T'
|
|
Field 2:: field abbreviation to which this true/false string corresponds
|
|
Field 3:: True String
|
|
Field 4:: False String
|
|
--
|
|
|
|
-h|--help::
|
|
+
|
|
--
|
|
Print the version and options and exit.
|
|
--
|
|
|
|
-H <input hosts file>::
|
|
+
|
|
--
|
|
Read a list of entries from a "hosts" file, which will then be written
|
|
to a capture file. Implies *-W n*. Can be called multiple times.
|
|
|
|
The "hosts" file format is documented at
|
|
https://en.wikipedia.org/wiki/Hosts_(file).
|
|
--
|
|
|
|
-i|--interface <capture interface> | -::
|
|
+
|
|
--
|
|
Set the name of the network interface or pipe to use for live packet
|
|
capture.
|
|
|
|
Network interface names should match one of the names listed in "*tshark
|
|
-D*" (described above); a number, as reported by "*tshark -D*", can also
|
|
be used.
|
|
|
|
If no interface is specified, *TShark* searches the list of
|
|
interfaces, choosing the first non-loopback interface if there are any
|
|
non-loopback interfaces, and choosing the first loopback interface if
|
|
there are no non-loopback interfaces. If there are no interfaces at all,
|
|
*TShark* reports an error and doesn't start the capture.
|
|
|
|
Pipe names should be either the name of a FIFO (named pipe) or "-" to
|
|
read data from the standard input. On Windows systems, pipe names must be
|
|
of the form +"\\.\pipe\+*pipename*". Data read from pipes must be in
|
|
standard pcapng or pcap format. Pcapng data must have the same
|
|
endianness as the capturing host.
|
|
|
|
"TCP@<host>:<port>" causes *TShark* to attempt to connect to the
|
|
specified port on the specified host and read pcapng or pcap data.
|
|
|
|
This option can occur multiple times. When capturing from multiple
|
|
interfaces, the capture file will be saved in pcapng format.
|
|
--
|
|
|
|
-I|--monitor-mode::
|
|
+
|
|
--
|
|
Put the interface in "monitor mode"; this is supported only on IEEE
|
|
802.11 Wi-Fi interfaces, and supported only on some operating systems.
|
|
|
|
Note that in monitor mode the adapter might disassociate from the
|
|
network with which it's associated, so that you will not be able to use
|
|
any wireless networks with that adapter. This could prevent accessing
|
|
files on a network server, or resolving host names or network addresses,
|
|
if you are capturing in monitor mode and are not connected to another
|
|
network with another adapter.
|
|
|
|
This option can occur multiple times. If used before the first
|
|
occurrence of the *-i* option, it enables the monitor mode for all interfaces.
|
|
If used after an *-i* option, it enables the monitor mode for
|
|
the interface specified by the last *-i* option occurring before
|
|
this option.
|
|
--
|
|
|
|
-j <protocol match filter>::
|
|
+
|
|
--
|
|
Protocol match filter used for ek|json|jsonraw|pdml output file types.
|
|
Only the protocol's parent node is included. Child nodes are only
|
|
included if explicitly specified in the filter.
|
|
|
|
Example: *tshark -j "ip ip.flags http"*
|
|
--
|
|
|
|
-J <protocol match filter>::
|
|
+
|
|
--
|
|
Protocol top level filter used for ek|json|jsonraw|pdml output file types.
|
|
The protocol's parent node and all child nodes are included.
|
|
Lower-level protocols must be explicitly specified in the filter.
|
|
|
|
Example: *tshark -J "tcp http"*
|
|
--
|
|
|
|
-K <keytab>::
|
|
+
|
|
--
|
|
Load kerberos crypto keys from the specified keytab file.
|
|
This option can be used multiple times to load keys from several files.
|
|
|
|
Example: *tshark -K krb5.keytab*
|
|
--
|
|
|
|
-l::
|
|
+
|
|
--
|
|
Flush the standard output after the information for each packet is
|
|
printed. (This is not, strictly speaking, line-buffered if *-V*
|
|
was specified; however, it is the same as line-buffered if *-V* wasn't
|
|
specified, as only one line is printed for each packet, and, as *-l* is
|
|
normally used when piping a live capture to a program or script, so that
|
|
output for a packet shows up as soon as the packet is seen and
|
|
dissected, it should work just as well as true line-buffering. We do
|
|
this as a workaround for a deficiency in the Microsoft Visual C++ C
|
|
library.)
|
|
|
|
This may be useful when piping the output of *TShark* to another
|
|
program, as it means that the program to which the output is piped will
|
|
see the dissected data for a packet as soon as *TShark* sees the
|
|
packet and generates that output, rather than seeing it only when the
|
|
standard output buffer containing that data fills up.
|
|
--
|
|
|
|
-L|--list-data-link-types::
|
|
+
|
|
--
|
|
List the data link types supported by the interface and exit. The reported
|
|
link types can be used for the *-y* option.
|
|
--
|
|
|
|
-n::
|
|
+
|
|
--
|
|
Disable network object name resolution (such as hostname, TCP and UDP port
|
|
names); the *-N* option might override this one.
|
|
--
|
|
|
|
-N <name resolving flags>::
|
|
+
|
|
--
|
|
Turn on name resolving only for particular types of addresses and port
|
|
numbers, with name resolving for other types of addresses and port
|
|
numbers turned off. This option overrides *-n* if both *-N* and *-n*
|
|
are present. This option and *-n* override the options from the preferences,
|
|
including preferences set via the *-o* option. If both *-N* and *-n* options
|
|
are not present, the values from the preferences are used, which default to
|
|
*d*, *m*, and *N* turned on and the other options turned off. (NB, *N* does
|
|
not actually do anything without *n* enabled as well.)
|
|
|
|
The argument is a string that may contain the letters:
|
|
|
|
*d* to enable resolution from captured DNS packets
|
|
|
|
*m* to enable MAC address resolution
|
|
|
|
*n* to enable network address resolution
|
|
|
|
*N* to enable using external resolvers (e.g., DNS) for network address
|
|
resolution; no effect without *n* also enabled
|
|
|
|
*t* to enable transport-layer port number resolution
|
|
|
|
*v* to enable VLAN IDs to names resolution
|
|
--
|
|
|
|
-o <preference>:<value>::
|
|
+
|
|
--
|
|
Set a preference value, overriding the default value and any value read
|
|
from a preference file. The argument to the option is a string of the
|
|
form __prefname:value__, where __prefname__ is the name of the
|
|
preference (which is the same name that would appear in the preference
|
|
file), and __value__ is the value to which it should be set.
|
|
--
|
|
|
|
-O <protocols>::
|
|
+
|
|
--
|
|
Similar to the *-V* option, but causes *TShark* to only show a
|
|
detailed view of the comma-separated list of __protocols__ specified, and
|
|
show only the top-level detail line for all other protocols, rather than
|
|
a detailed view of all protocols. Use the output of "*tshark -G
|
|
protocols*" to find the abbreviations of the protocols you can specify.
|
|
--
|
|
|
|
-p|--no-promiscuous-mode::
|
|
+
|
|
--
|
|
__Don't__ put the interface into promiscuous mode. Note that the
|
|
interface might be in promiscuous mode for some other reason; hence,
|
|
*-p* cannot be used to ensure that the only traffic that is captured is
|
|
traffic sent to or from the machine on which *TShark* is running,
|
|
broadcast traffic, and multicast traffic to addresses received by that
|
|
machine.
|
|
|
|
This option can occur multiple times. If used before the first
|
|
occurrence of the *-i* option, no interface will be put into the
|
|
promiscuous mode.
|
|
If used after an *-i* option, the interface specified by the last *-i*
|
|
option occurring before this option will not be put into the
|
|
promiscuous mode.
|
|
--
|
|
|
|
-P|--print::
|
|
+
|
|
--
|
|
Decode and display the packet summary or details, even if writing raw
|
|
packet data using the *-w* option, and even if packet output is
|
|
otherwise suppressed with *-Q*.
|
|
--
|
|
|
|
-q::
|
|
+
|
|
--
|
|
When capturing packets, don't display the continuous count of packets
|
|
captured that is normally shown when saving a capture to a file;
|
|
instead, just display, at the end of the capture, a count of packets
|
|
captured. On systems that support the SIGINFO signal, such as various
|
|
BSDs, you can cause the current count to be displayed by typing your
|
|
"status" character (typically control-T, although it
|
|
might be set to "disabled" by default on at least some BSDs, so you'd
|
|
have to explicitly set it to use it).
|
|
|
|
When reading a capture file, or when capturing and not saving to a file,
|
|
don't print packet information; this is useful if you're using a *-z*
|
|
option to calculate statistics and don't want the packet information
|
|
printed, just the statistics.
|
|
--
|
|
|
|
-Q::
|
|
+
|
|
--
|
|
When capturing packets, don't display, on the standard error, the
|
|
initial message indicating on which interfaces the capture is being
|
|
done, the continuous count of packets captured shown when saving a
|
|
capture to a file, and the final message giving the count of packets
|
|
captured. Only true errors are displayed on the standard error.
|
|
|
|
only display true errors; don't display the
|
|
initial message indicating the. This outputs less
|
|
than the *-q* option, so the interface name and total packet
|
|
count and the end of a capture are not sent to stderr.
|
|
|
|
When reading a capture file, or when capturing and not saving to a file,
|
|
don't print packet information; this is useful if you're using a *-z*
|
|
option to calculate statistics and don't want the packet information
|
|
printed, just the statistics.
|
|
--
|
|
|
|
-r|--read-file <infile>::
|
|
+
|
|
--
|
|
Read packet data from __infile__, can be any supported capture file format
|
|
(including gzipped files). It is possible to use named pipes or stdin (-)
|
|
here but only with certain (not compressed) capture file formats (in
|
|
particular: those that can be read without seeking backwards).
|
|
--
|
|
|
|
-R|--read-filter <Read filter>::
|
|
+
|
|
--
|
|
Cause the specified filter (which uses the syntax of read/display filters,
|
|
rather than that of capture filters) to be applied during the first pass of
|
|
analysis. Packets not matching the filter are not considered for future
|
|
passes. Only makes sense with multiple passes, see -2. For regular filtering
|
|
on single-pass dissect see -Y instead.
|
|
|
|
Note that forward-looking fields such as 'response in frame #' cannot be used
|
|
with this filter, since they will not have been calculate when this filter is
|
|
applied.
|
|
--
|
|
|
|
-s|--snapshot-length <capture snaplen>::
|
|
+
|
|
--
|
|
Set the default snapshot length to use when capturing live data.
|
|
No more than __snaplen__ bytes of each network packet will be read into
|
|
memory, or saved to disk. A value of 0 specifies a snapshot length of
|
|
262144, so that the full packet is captured; this is the default.
|
|
|
|
This option can occur multiple times. If used before the first
|
|
occurrence of the *-i* option, it sets the default snapshot length.
|
|
If used after an *-i* option, it sets the snapshot length for
|
|
the interface specified by the last *-i* option occurring before
|
|
this option. If the snapshot length is not set specifically,
|
|
the default snapshot length is used if provided.
|
|
--
|
|
|
|
-S <separator>::
|
|
+
|
|
--
|
|
Set the line separator to be printed between packets.
|
|
--
|
|
|
|
-t a|ad|adoy|d|dd|e|r|u|ud|udoy::
|
|
+
|
|
--
|
|
Set the format of the packet timestamp printed in summary lines.
|
|
The format can be one of:
|
|
|
|
*a* absolute: The absolute time, as local time in your time zone,
|
|
is the actual time the packet was captured, with no date displayed
|
|
|
|
*ad* absolute with date: The absolute date, displayed as YYYY-MM-DD,
|
|
and time, as local time in your time zone, is the actual time and date
|
|
the packet was captured
|
|
|
|
*adoy* absolute with date using day of year: The absolute date,
|
|
displayed as YYYY/DOY, and time, as local time in your time zone,
|
|
is the actual time and date the packet was captured
|
|
|
|
*d* delta: The delta time is the time since the previous packet was
|
|
captured
|
|
|
|
*dd* delta_displayed: The delta_displayed time is the time since the
|
|
previous displayed packet was captured
|
|
|
|
*e* epoch: The time in seconds since epoch (Jan 1, 1970 00:00:00)
|
|
|
|
*r* relative: The relative time is the time elapsed between the first packet
|
|
and the current packet
|
|
|
|
*u* UTC: The absolute time, as UTC, is the actual time the packet was
|
|
captured, with no date displayed
|
|
|
|
*ud* UTC with date: The absolute date, displayed as YYYY-MM-DD,
|
|
and time, as UTC, is the actual time and date the packet was captured
|
|
|
|
*udoy* UTC with date using day of year: The absolute date, displayed
|
|
as YYYY/DOY, and time, as UTC, is the actual time and date the packet
|
|
was captured
|
|
|
|
The default format is relative.
|
|
--
|
|
|
|
-T ek|fields|json|jsonraw|pdml|ps|psml|tabs|text::
|
|
+
|
|
--
|
|
Set the format of the output when viewing decoded packet data. The
|
|
options are one of:
|
|
|
|
*ek* Newline delimited JSON format for bulk import into Elasticsearch.
|
|
It can be used with *-j* or *-J* to specify
|
|
which protocols to include or with
|
|
*-x* to include raw hex-encoded packet data.
|
|
If *-P* is specified it will print the packet summary only, with both
|
|
*-P* and *-V* it will print the packet summary and packet details.
|
|
If neither *-P* or *-V* are used it will print the packet details only.
|
|
Example of usage to import data into Elasticsearch:
|
|
|
|
tshark -T ek -j "http tcp ip" -P -V -x -r file.pcap > file.json
|
|
curl -H "Content-Type: application/x-ndjson" -XPOST http://elasticsearch:9200/_bulk --data-binary "@file.json"
|
|
|
|
Elastic requires a mapping file to be loaded as template for packets-*
|
|
index in order to convert Wireshark types to elastic types. This file
|
|
can be auto-generated with the command "tshark -G elastic-mapping". Since
|
|
the mapping file can be huge, protocols can be selected by using the option
|
|
--elastic-mapping-filter:
|
|
|
|
tshark -G elastic-mapping --elastic-mapping-filter ip,udp,dns
|
|
|
|
*fields* The values of fields specified with the *-e* option, in a
|
|
form specified by the *-E* option. For example,
|
|
|
|
tshark -T fields -E separator=, -E quote=d
|
|
|
|
would generate comma-separated values (CSV) output suitable for importing
|
|
into your favorite spreadsheet program.
|
|
|
|
*json* JSON file format. It can be used with *-j* or *-J* to specify
|
|
which protocols to include or with *-x* option to include
|
|
raw hex-encoded packet data. Example of usage:
|
|
|
|
tshark -T json -r file.pcap
|
|
tshark -T json -j "http tcp ip" -x -r file.pcap
|
|
|
|
*jsonraw* JSON file format including only raw hex-encoded packet data.
|
|
It can be used with *-j* or *-J* to specify which protocols to include.
|
|
Example of usage:
|
|
|
|
tshark -T jsonraw -r file.pcap
|
|
tshark -T jsonraw -j "http tcp ip" -x -r file.pcap
|
|
|
|
*pdml* Packet Details Markup Language, an XML-based format for the
|
|
details of a decoded packet. This information is equivalent to the
|
|
packet details printed with the *-V* option. Using the --color option
|
|
will add color attributes to *pdml* output. These attributes are
|
|
nonstandard.
|
|
|
|
*ps* PostScript for a human-readable one-line summary of each of the
|
|
packets, or a multi-line view of the details of each of the packets,
|
|
depending on whether the *-V* option was specified.
|
|
|
|
*psml* Packet Summary Markup Language, an XML-based format for the summary
|
|
information of a decoded packet. This information is equivalent to the
|
|
information shown in the one-line summary printed by default.
|
|
Using the --color option will add color attributes to *pdml* output. These
|
|
attributes are nonstandard.
|
|
|
|
*tabs* Similar to the default *text* report except the human-readable one-line
|
|
summary of each packet will include an ASCII horizontal tab (0x09) character
|
|
as a delimiter between each column.
|
|
|
|
*text* Text of a human-readable one-line summary of each of the packets, or a
|
|
multi-line view of the details of each of the packets, depending on
|
|
whether the *-V* option was specified. This is the default.
|
|
--
|
|
|
|
--temp-dir <directory>::
|
|
+
|
|
--
|
|
Specifies the directory into which temporary files (including capture
|
|
files) are to be written. The default behaviour is to use your system's
|
|
temporary directory (typically __/tmp__ on UNIX-compatible systems, such
|
|
as Linux, macOS, \*BSD, Solaris, and AIX, and __C:\\Temp__ on Windows).
|
|
--
|
|
|
|
-u <seconds type>::
|
|
+
|
|
--
|
|
Specifies the seconds type. Valid choices are:
|
|
|
|
*s* for seconds
|
|
|
|
*hms* for hours, minutes and seconds
|
|
--
|
|
|
|
-U <tap name>::
|
|
+
|
|
--
|
|
PDUs export, exports PDUs from infile to outfile according to the tap
|
|
name given. Use -Y to filter.
|
|
|
|
Enter an empty tap name "" or a tap name of ? to get a list of available
|
|
names.
|
|
--
|
|
|
|
-v|--version::
|
|
+
|
|
--
|
|
Print the version and exit.
|
|
--
|
|
|
|
-V::
|
|
+
|
|
--
|
|
Cause *TShark* to print a view of the packet details.
|
|
--
|
|
|
|
-w <outfile> | -::
|
|
+
|
|
--
|
|
Write raw packet data to __outfile__ or to the standard output if
|
|
__outfile__ is '-'.
|
|
|
|
NOTE: -w provides raw packet data, not text. If you want text output
|
|
you need to redirect stdout (e.g. using '>'), don't use the *-w*
|
|
option for this.
|
|
--
|
|
|
|
-W <file format option>::
|
|
+
|
|
--
|
|
Save extra information in the file if the format supports it. For
|
|
example,
|
|
|
|
tshark -F pcapng -W n
|
|
|
|
will save host name resolution records along with captured packets.
|
|
|
|
Future versions of *TShark* may automatically change the capture format
|
|
to *pcapng* as needed.
|
|
|
|
The argument is a string that may contain the following letter:
|
|
|
|
*n* write network address resolution information (pcapng only)
|
|
--
|
|
|
|
-x::
|
|
+
|
|
--
|
|
Cause *TShark* to print a hex and ASCII dump of the packet data
|
|
after printing the summary and/or details, if either are also being displayed.
|
|
--
|
|
|
|
--hexdump <hexoption>::
|
|
+
|
|
--
|
|
Cause *TShark* to print a hex and ASCII dump of the packet data
|
|
with the ability to select which data sources to dump and how to
|
|
format or exclude the ASCII dump text.
|
|
|
|
This option can be used multiple times where the data source *<hexoption>*
|
|
is *all* or *frames* and the ASCII dump text *<hexoption>* is *ascii*,
|
|
*delimit*, *noascii*.
|
|
|
|
Example: tshark ... --hexdump frames --hexdump delimit ...
|
|
|
|
*all*::
|
|
|
|
Enable hexdump, generate hexdump blocks for all data sources associated
|
|
with each frame. Used to negate earlier use of `--hexdump frames`.
|
|
The *-x* option displays all data sources by default.
|
|
|
|
*frames*::
|
|
|
|
Enable hexdump, generate hexdump blocks only for the frame data. Use
|
|
this option to exclude, from hexdump output, any hexdump blocks for
|
|
secondary data sources such as 'Bitstring tvb', 'Reassembled TCP',
|
|
'De-chunked entity body', etc.
|
|
|
|
*ascii*::
|
|
|
|
Enable hexdump, with undelimited ASCII dump text. Used to negate earlier
|
|
use of `--hexdump delimit` or `--hexdump noascii`. The *-x* option
|
|
displays undelimited ASCII dump text by default.
|
|
|
|
*delimit*::
|
|
|
|
Enable hexdump with the ASCII dump text delimited with '|' characters.
|
|
This is useful to unambiguously determine the last of the hex byte text
|
|
and start of the ASCII dump text.
|
|
|
|
*noascii*::
|
|
|
|
Enable hexdump without printing any ASCII dump text.
|
|
|
|
*help*::
|
|
|
|
Display --hexdump specific help then exit.
|
|
|
|
The use of *--hexdump <hexoption>* is particularly useful to generate output
|
|
that can be used to create a pcap or pcapng file from a capture file type such
|
|
as Microsoft NetMon 2.x which *TShark* and *Wireshark* can read but can not
|
|
directly do a "Save as" nor export packets from.
|
|
|
|
Examples:
|
|
|
|
Generate hexdump output, with only the frame data source, with delimited ASCII
|
|
dump text, with each frame hex block preceded by a human readable timestamp that
|
|
is directly usable by the *text2pcap* utility:
|
|
|
|
tshark ... --hexdump frames --hexdump delimit \
|
|
-P -t ad -o gui.column.format:"Time","%t" \
|
|
| text2pcap -n -t '%F %T.%f' - MYNEWPCAPNG
|
|
|
|
Generate hexdump output, with only the frame data source, with no ASCII dump text,
|
|
with each frame hex block preceded by an epoch timestamp that is directly
|
|
usable by the *text2pcap* utility:
|
|
|
|
tshark ... --hexdump frames --hexdump noascii \
|
|
-P -t e -o gui.column.format:"Time","%t" \
|
|
| text2pcap -n -t %s.%f - MYNEWPCAPNG
|
|
--
|
|
|
|
-X <eXtension options>::
|
|
+
|
|
--
|
|
Specify an option to be passed to a *TShark* module. The eXtension option
|
|
is in the form __extension_key:value__, where __extension_key__ can be:
|
|
|
|
*lua_script*:__lua_script_filename__ tells *TShark* to load the given script in
|
|
addition to the default Lua scripts.
|
|
|
|
**lua_script**__num__:__argument__ tells *TShark* to pass the given argument
|
|
to the lua script identified by 'num', which is the number indexed order of the
|
|
'lua_script' command. For example, if only one script was loaded with
|
|
'-X lua_script:my.lua', then '-X lua_script1:foo' will pass the string 'foo' to
|
|
the 'my.lua' script. If two scripts were loaded, such as '-X lua_script:my.lua'
|
|
and '-X lua_script:other.lua' in that order, then a '-X lua_script2:bar' would
|
|
pass the string 'bar' to the second lua script, namely 'other.lua'.
|
|
|
|
*read_format*:__file_format__ tells *TShark* to use the given file format to
|
|
read in the file (the file given in the *-r* command option). Providing no
|
|
__file_format__ argument, or an invalid one, will produce a list of available
|
|
file formats to use. For example,
|
|
|
|
tshark -r rtcp_broken.pcapng -X read_format:"MIME Files Format" -V
|
|
|
|
will display the internal file structure and allow access to the
|
|
`file-pcapng` fields.
|
|
--
|
|
|
|
-y|--linktype <capture link type>::
|
|
+
|
|
--
|
|
Set the data link type to use while capturing packets. The values
|
|
reported by *-L* are the values that can be used.
|
|
|
|
This option can occur multiple times. If used before the first
|
|
occurrence of the *-i* option, it sets the default capture link type.
|
|
If used after an *-i* option, it sets the capture link type for
|
|
the interface specified by the last *-i* option occurring before
|
|
this option. If the capture link type is not set specifically,
|
|
the default capture link type is used if provided.
|
|
--
|
|
|
|
-Y|--display-filter <displaY filter>::
|
|
+
|
|
--
|
|
Cause the specified filter (which uses the syntax of read/display filters,
|
|
rather than that of capture filters) to be applied before printing a
|
|
decoded form of packets or writing packets to a file. Packets matching the
|
|
filter are printed or written to file; packets that the matching packets
|
|
depend upon (e.g., fragments), are not printed but are written to file;
|
|
packets not matching the filter nor depended upon are discarded rather
|
|
than being printed or written.
|
|
|
|
Use this instead of -R for filtering using single-pass analysis. If doing
|
|
two-pass analysis (see -2) then only packets matching the read filter (if there
|
|
is one) will be checked against this filter.
|
|
--
|
|
|
|
-M <auto session reset>::
|
|
+
|
|
--
|
|
Automatically reset internal session when reached to specified number of packets.
|
|
For example,
|
|
|
|
tshark -M 100000
|
|
|
|
will reset session every 100000 packets.
|
|
|
|
This feature does not support -2 two-pass analysis
|
|
--
|
|
|
|
-z <statistics>::
|
|
+
|
|
--
|
|
Get *TShark* to collect various types of statistics and display the
|
|
result after finishing reading the capture file. Use the *-q* option
|
|
if you're reading a capture file and only want the statistics printed,
|
|
not any per-packet information.
|
|
|
|
Statistics are calculated independently of the normal per-packet output,
|
|
unaffected by the main display filter. However, most have their own
|
|
optional __filter__ parameter, and only packets that match that filter (and
|
|
any capture filter or read filter) will be used in the calculations.
|
|
|
|
Note that the *-z proto* option is different - it doesn't cause
|
|
statistics to be gathered and printed when the capture is complete, it
|
|
modifies the regular packet summary output to include the values of
|
|
fields specified with the option. Therefore you must not use the *-q*
|
|
option, as that option would suppress the printing of the regular packet
|
|
summary output, and must also not use the *-V* option, as that would
|
|
cause packet detail information rather than packet summary information
|
|
to be printed.
|
|
|
|
Some of the currently implemented statistics are:
|
|
--
|
|
|
|
*-z help*::
|
|
+
|
|
--
|
|
Display all possible values for *-z*.
|
|
--
|
|
|
|
*-z* afp,srt[,__filter__]::
|
|
+
|
|
--
|
|
Show Apple Filing Protocol service response time statistics.
|
|
--
|
|
|
|
*-z* ancp,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on Access Node Control Protocol message types
|
|
and adjacency packet codes.
|
|
--
|
|
|
|
*-z* ansi_a,bsmap[,__filter__]::
|
|
+
|
|
--
|
|
Count the number of ANSI A-I/F BSMAP messages of each type.
|
|
--
|
|
|
|
*-z* ansi_a,dtap[,__filter__]::
|
|
+
|
|
--
|
|
Count the number of ANSI A-I/F DTAP messages of each type.
|
|
--
|
|
|
|
*-z* ansi_map[,__filter__]::
|
|
+
|
|
--
|
|
Count the number of ANSI MAP messages of each type, and calculate the
|
|
total number of bytes and average bytes of each message type.
|
|
--
|
|
|
|
*-z* asap,stat[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on Aggregate Service Access Protocol (ASAP).
|
|
For each ASAP message type, displays the number, rate, and share among
|
|
all ASAP message types of both packets and bytes, and the first and last
|
|
time that it is seen.
|
|
--
|
|
|
|
*-z* bacapp_instanceid,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on BACnet APDUs, collated by instance ID.
|
|
Displayed information includes source and destination address and
|
|
service type.
|
|
--
|
|
|
|
*-z* bacapp_ip,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on BACnet APDUs, collated by source and destination
|
|
address. Displayed information includes service type, object ID, and
|
|
instance ID.
|
|
--
|
|
|
|
*-z* bacapp_objectid,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on BACnet APDUs, collated by object ID.
|
|
Displayed information includes source and destination address,
|
|
service type, and instance ID.
|
|
--
|
|
|
|
*-z* bacapp_service,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on BACnet APDUs, collated by service type.
|
|
Displayed information includes source and destination address,
|
|
object ID, and instance ID.
|
|
--
|
|
|
|
*-z* calcappprotocol,stat[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on the Calculation Application Protocol of
|
|
Reliable Server Pooling. For each message type, displays the number,
|
|
rate, and share among all message types of both packets and bytes,
|
|
and the first and last time that it is seen.
|
|
--
|
|
|
|
*-z* camel,counter[,__filter__]::
|
|
+
|
|
--
|
|
Count the number of CAMEL messages for each opcode.
|
|
--
|
|
|
|
*-z* camel,srt[,__filter__]::
|
|
+
|
|
--
|
|
Collect requests/response SRT (Service Response Time) data for CAMEL.
|
|
Data collected is number of request messages with corresponding response
|
|
of each CAMEL message type, along with the minimum, maximum, and average
|
|
response time.
|
|
--
|
|
|
|
*-z* collectd,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics for collectd. The gathered statistics are the number
|
|
of collectd packets and the total number of value segments, along with the
|
|
host, plugin, and type of the values.
|
|
--
|
|
|
|
*-z* componentstatusprotocol,stat[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on the Calculation Status Protocol of Reliable
|
|
Server Pooling. For each message type, displays the number, rate
|
|
and share among all message types of both packets and bytes, and the
|
|
first and last time that it is seen.
|
|
--
|
|
|
|
*-z* conv,__type__[,__filter__]::
|
|
+
|
|
--
|
|
Create a table that lists all conversations that could be seen in the
|
|
capture. __type__ specifies the conversation endpoint type for which we
|
|
want to generate the statistics; currently the supported ones are:
|
|
|
|
"bluetooth" Bluetooth addresses
|
|
"dccp" DCCP/IP socket pairs Both IPv4 and IPv6 are supported
|
|
"eth" Ethernet addresses
|
|
"fc" Fibre Channel addresses
|
|
"fddi" FDDI addresses
|
|
"ip" IPv4 addresses
|
|
"ipv6" IPv6 addresses
|
|
"ipx" IPX addresses
|
|
"jxta" JXTA message addresses
|
|
"mptcp" Multipath TCP connections
|
|
"ncp" NCP connections
|
|
"rsvp" RSVP connections
|
|
"sctp" SCTP/IP socket pairs Both IPv4 and IPv6 are supported
|
|
"sll" Linux "cooked mode" capture addresses
|
|
"tcp" TCP/IP socket pairs Both IPv4 and IPv6 are supported
|
|
"tr" Token Ring addresses
|
|
"udp" UDP/IP socket pairs Both IPv4 and IPv6 are supported
|
|
"usb" USB addresses
|
|
"wlan" IEEE 802.11 addresses
|
|
"wpan" IEEE 802.15.4 addresses
|
|
"zbee_nwk" ZigBee Network Layer addresses
|
|
|
|
The table is presented with one line for each conversation which displays
|
|
the number of frames/bytes in each direction, the total number of
|
|
frames/bytes, relative start time and duration.
|
|
The table is sorted according to the total number of frames.
|
|
--
|
|
|
|
*-z* credentials::
|
|
+
|
|
--
|
|
Collect credentials (username/passwords) from packets. The report includes
|
|
the packet number, the protocol that had that credential, the username and
|
|
the password. For protocols just using one single field as authentication,
|
|
this is provided as a password and a placeholder in place of the user.
|
|
Currently implemented protocols include FTP, HTTP, IMAP, POP, and SMTP.
|
|
--
|
|
|
|
*-z* dcerpc,srt,__uuid__,__major__.__minor__[,__filter__]::
|
|
+
|
|
--
|
|
Collect call/reply SRT (Service Response Time) data for DCERPC interface __uuid__,
|
|
version __major__.__minor__.
|
|
Data collected is the number of calls for each procedure, MinSRT, MaxSRT
|
|
and AvgSRT.
|
|
|
|
Example: [.nowrap]#*-z dcerpc,srt,12345778-1234-abcd-ef00-0123456789ac,1.0*# will
|
|
collect data for the CIFS SAMR Interface.
|
|
|
|
This option can be used multiple times on the command line.
|
|
|
|
Example: [.nowrap]#*-z dcerpc,srt,12345778-1234-abcd-ef00-0123456789ac,1.0,ip.addr==1.2.3.4*# will collect SAMR
|
|
SRT statistics for a specific host.
|
|
--
|
|
|
|
*-z* dests,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on IPv4 destination addresses and the protocols
|
|
and ports appearing on each address.
|
|
--
|
|
|
|
*-z* dhcp,stat[,__filter__]::
|
|
+
|
|
--
|
|
Show DHCP (BOOTP) statistics.
|
|
--
|
|
|
|
*-z* diameter,avp[,__cmd.code__,__field__,__field__,__...__]::
|
|
+
|
|
--
|
|
This option enables extraction of most important diameter fields from large
|
|
capture files. Exactly one text line for each diameter message with matched
|
|
*diameter.cmd.code* will be printed.
|
|
|
|
Empty diameter command code or +'*'+ can be specified to match any *diameter.cmd.code*
|
|
|
|
Example: *-z diameter,avp* extract default field set from diameter messages.
|
|
|
|
Example: *-z diameter,avp,280* extract default field set from diameter DWR messages.
|
|
|
|
Example: *-z diameter,avp,272* extract default field set from diameter CC messages.
|
|
|
|
Extract most important fields from diameter CC messages:
|
|
|
|
*tshark -r file.cap.gz -q -z diameter,avp,272,CC-Request-Type,CC-Request-Number,Session-Id,Subscription-Id-Data,Rating-Group,Result-Code*
|
|
|
|
Following fields will be printed out for each diameter message:
|
|
|
|
"frame" Frame number.
|
|
"time" Unix time of the frame arrival.
|
|
"src" Source address.
|
|
"srcport" Source port.
|
|
"dst" Destination address.
|
|
"dstport" Destination port.
|
|
"proto" Constant string 'diameter', which can be used for post processing of tshark output. E.g. grep/sed/awk.
|
|
"msgnr" seq. number of diameter message within the frame. E.g. '2' for the third diameter message in the same frame.
|
|
"is_request" '0' if message is a request, '1' if message is an answer.
|
|
"cmd" diameter.cmd_code, E.g. '272' for credit control messages.
|
|
"req_frame" Number of frame where matched request was found or '0'.
|
|
"ans_frame" Number of frame where matched answer was found or '0'.
|
|
"resp_time" response time in seconds, '0' in case if matched Request/Answer is not found in trace. E.g. in the begin or end of capture.
|
|
|
|
*-z diameter,avp* option is much faster than *-V -T text* or *-T pdml* options.
|
|
|
|
*-z diameter,avp* option is more powerful than *-T field* and *-z proto,colinfo* options.
|
|
|
|
Multiple diameter messages in one frame are supported.
|
|
|
|
Several fields with same name within one diameter message are supported, e.g.
|
|
__diameter.Subscription-Id-Data__ or __diameter.Rating-Group__.
|
|
|
|
Note: *tshark -q* option is recommended to suppress default *TShark* output.
|
|
--
|
|
|
|
*-z* diameter,srt[,__filter__]::
|
|
+
|
|
--
|
|
Collect requests/response SRT (Service Response Time) data for Diameter.
|
|
Data collected is number of request and response pairs of each Diameter
|
|
command code, Minimum SRT, Maximum SRT, Average SRT, and Sum SRT.
|
|
Currently no statistics are gathered on unpaired messages.
|
|
--
|
|
|
|
*-z* dns,tree[,__filter__]::
|
|
+
|
|
--
|
|
Create a summary of the captured DNS packets. General information are collected
|
|
such as qtype and qclass distribution. For some data (as qname length or DNS
|
|
payload) max, min and average values are also displayed.
|
|
--
|
|
|
|
*-z* endpoints,__type__[,__filter__]::
|
|
+
|
|
--
|
|
Create a table that lists all endpoints that could be seen in the
|
|
capture. __type__ specifies the endpoint type for which we
|
|
want to generate the statistics; currently the supported ones are:
|
|
|
|
"bluetooth" Bluetooth addresses
|
|
"dccp" DCCP/IP socket pairs Both IPv4 and IPv6 are supported
|
|
"eth" Ethernet addresses
|
|
"fc" Fibre Channel addresses
|
|
"fddi" FDDI addresses
|
|
"ip" IPv4 addresses
|
|
"ipv6" IPv6 addresses
|
|
"ipx" IPX addresses
|
|
"jxta" JXTA message addresses
|
|
"mptcp" Multipath TCP connections
|
|
"ncp" NCP connections
|
|
"rsvp" RSVP connections
|
|
"sctp" SCTP/IP socket pairs Both IPv4 and IPv6 are supported
|
|
"sll" Linux "cooked mode" capture addresses
|
|
"tcp" TCP/IP socket pairs Both IPv4 and IPv6 are supported
|
|
"tr" Token Ring addresses
|
|
"udp" UDP/IP socket pairs Both IPv4 and IPv6 are supported
|
|
"usb" USB addresses
|
|
"wlan" IEEE 802.11 addresses
|
|
"wpan" IEEE 802.15.4 addresses
|
|
"zbee_nwk" ZigBee Network Layer addresses
|
|
|
|
The table is presented with one line for each endpoint which displays
|
|
the total number of packets/bytes and the number of packets/bytes in
|
|
each direction.
|
|
The table is sorted according to the total number of packets.
|
|
--
|
|
|
|
*-z* enrp,stat[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on Endpoint Handlespace Redundancy Protocol (ENRP).
|
|
For each message type, displays the number, rate, and share among
|
|
all message types of both packets and bytes, and the first and last
|
|
time that it is seen.
|
|
--
|
|
|
|
*-z* expert[__,error|,warn|,note|,chat|,comment__][,__filter__]::
|
|
+
|
|
--
|
|
Collects information about all expert info, and will display them in order,
|
|
grouped by severity.
|
|
|
|
Example: *-z expert,sip* will show expert items of all severity for frames that
|
|
match the sip protocol.
|
|
|
|
This option can be used multiple times on the command line.
|
|
|
|
Example: *-z "expert,note,tcp"* will only collect expert items for frames that
|
|
include the tcp protocol, with a severity of note or higher.
|
|
--
|
|
|
|
*-z* f1ap,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate the distribution of F1AP packets, grouped by packet types.
|
|
--
|
|
|
|
*-z* f5_tmm_dist,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate the F5 Ethernet trailer Traffic Managment Microkernel distribution.
|
|
Displayed information is the number of packets and bytes, grouped by the TMM
|
|
slot and number, whether packets are ingress or egress, and whether there is
|
|
a flow ID and virtual server name, a flow ID without virtual server name, or
|
|
no flow ID, along with total for all packets with F5 trailers.
|
|
--
|
|
|
|
*-z* f5_virt_dist,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate F5 Ethernet trailer Virtual Server distribution.
|
|
Displayed information is the number of packets and bytes, grouped by the
|
|
virtual server name if it exists, or by whether there is a flow ID or not
|
|
if there is no virtual server name, as well as totals for all packets with
|
|
F5 trailers.
|
|
--
|
|
|
|
*-z* fc,srt[,__filter__]::
|
|
+
|
|
--
|
|
Collect requests/response SRT (Service Response Time) data for GTP.
|
|
Data collected is the number of request/response pairs, minimum SRT,
|
|
maximum SRT, average SRT, and sum SRT for each value of the Type field
|
|
(next protocol). No statistics are gathered on unpaired messages.
|
|
--
|
|
|
|
*-z* flow,__name__,__mode__[,__filter__]::
|
|
+
|
|
--
|
|
Displays the flow of data between two nodes. Output is the same as ASCII format
|
|
saved from GUI.
|
|
|
|
__name__ specifies the flow name. It can be one of:
|
|
|
|
any All frames
|
|
icmp ICMP
|
|
icmpv6 ICMPv6
|
|
lbm_uim UIM
|
|
tcp TCP
|
|
|
|
__mode__ specifies the address type. It can be one of:
|
|
|
|
standard Any address
|
|
network Network address
|
|
|
|
Example: *-z flow,tcp,network* will show data flow for all TCP frames
|
|
--
|
|
|
|
*-z* follow,__prot__,__mode__,__filter__[,__range__]::
|
|
+
|
|
--
|
|
Displays the contents of a TCP or UDP stream between two nodes. The data
|
|
sent by the second node is prefixed with a tab to differentiate it from the
|
|
data sent by the first node.
|
|
|
|
__prot__ specifies the transport protocol. It can be one of:
|
|
|
|
tcp TCP
|
|
udp UDP
|
|
dccp DCCP
|
|
tls TLS or SSL
|
|
http HTTP streams
|
|
http2 HTTP/2 streams
|
|
quic QUIC streams
|
|
|
|
NOTE: While the usage help presents sip as an option, the proper
|
|
stream filters are not implemented so SIP calls cannot be followed
|
|
in *TShark*, only in *Wireshark*.
|
|
|
|
__mode__ specifies the output mode. It can be one of:
|
|
|
|
ascii ASCII output with dots for non-printable characters
|
|
ebcdic EBCDIC output with dots for non-printable characters
|
|
hex Hexadecimal and ASCII data with offsets
|
|
raw Hexadecimal data
|
|
yaml YAML format
|
|
|
|
Since the output in *ascii* or *ebcdic* mode may contain newlines, the length
|
|
of each section of output plus a newline precedes each section of output.
|
|
|
|
__filter__ specifies the stream to be displayed. There are three formats:
|
|
|
|
ip-addr0:port0,ip-addr1:port1
|
|
stream-index
|
|
stream-index,substream-index
|
|
|
|
The first format specifies IP addresses and TCP, UDP, or DCCP port pairs.
|
|
(TCP ports are used for TLS, HTTP, and HTTP2; QUIC does not support address
|
|
and port matching because of connection migration.)
|
|
|
|
The second format specifies stream indices, and is used for TCP, UDP, DCCP,
|
|
TLS, and HTTP. (TLS and HTTP use TCP stream indices.)
|
|
|
|
The third format, specifying streams and substreams, is used for HTTP/2 and
|
|
QUIC due to their use of multiplexing. (TCP stream and HTTP/2 stream indices
|
|
for HTTP/2, QUIC connection number and stream ID for QUIC.)
|
|
|
|
__range__ optionally specifies which "chunks" of the stream should be displayed.
|
|
|
|
Example: *-z "follow,tcp,hex,1"* will display the contents of the second TCP
|
|
stream (the first is stream 0) in "hex" format.
|
|
|
|
===================================================================
|
|
Follow: tcp,hex
|
|
Filter: tcp.stream eq 1
|
|
Node 0: 200.57.7.197:32891
|
|
Node 1: 200.57.7.198:2906
|
|
00000000 00 00 00 22 00 00 00 07 00 0a 85 02 07 e9 00 02 ...".... ........
|
|
00000010 07 e9 06 0f 00 0d 00 04 00 00 00 01 00 03 00 06 ........ ........
|
|
00000020 1f 00 06 04 00 00 ......
|
|
00000000 00 01 00 00 ....
|
|
00000026 00 02 00 00
|
|
|
|
Example: *-z "follow,tcp,ascii,200.57.7.197:32891,200.57.7.198:2906"* will
|
|
display the contents of a TCP stream between 200.57.7.197 port 32891 and
|
|
200.57.7.98 port 2906.
|
|
|
|
===================================================================
|
|
Follow: tcp,ascii
|
|
Filter: (omitted for readability)
|
|
Node 0: 200.57.7.197:32891
|
|
Node 1: 200.57.7.198:2906
|
|
38
|
|
...".....
|
|
................
|
|
4
|
|
....
|
|
|
|
Example: *-z "follow,http2,hex,0,1"* will display the contents of a HTTP/2
|
|
stream on the first TCP session (index 0) with HTTP/2 Stream ID 1.
|
|
|
|
===================================================================
|
|
Follow: http2,hex
|
|
Filter: tcp.stream eq 0 and http2.streamid eq 1
|
|
Node 0: 172.16.5.1:49178
|
|
Node 1: 172.16.5.10:8443
|
|
00000000 00 00 2c 01 05 00 00 00 01 82 04 8b 63 c1 ac 2a ..,..... ....c..*
|
|
00000010 27 1d 9d 57 ae a9 bf 87 41 8c 0b a2 5c 2e 2e da '..W.... A...\...
|
|
00000020 e1 05 c7 9a 69 9f 7a 88 25 b6 50 c3 ab b6 25 c3 ....i.z. %.P...%.
|
|
00000030 53 03 2a 2f 2a S.*/*
|
|
00000000 00 00 22 01 04 00 00 00 01 88 5f 87 35 23 98 ac .."..... .._.5#..
|
|
00000010 57 54 df 61 96 c3 61 be 94 03 8a 61 2c 6a 08 2f WT.a..a. ...a,j./
|
|
00000020 34 a0 5b b8 21 5c 0b ea 62 d1 bf 4.[.!\.. b..
|
|
0000002B 00 40 00 00 00 00 00 00 01 89 50 4e 47 0d 0a 1a .@...... ..PNG...
|
|
|
|
--
|
|
|
|
*-z* fractalgeneratorprotocol,stat[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on the Fractal Generator Protocol of Reliable
|
|
Server Pooling. For each message type, displays the number, rate
|
|
and share among all message types of both packets and bytes, and the
|
|
first and last time that it is seen.
|
|
--
|
|
|
|
*-z* gsm_a::
|
|
+
|
|
--
|
|
Count the number of GSM A-I/F messages of each type within the following
|
|
categories: BSSMAP, DTAP Mobility Management, DTAP Radio Resource
|
|
Management, DTAP Call Control, DTAP GPRS Mobility Management, DTAP SMS
|
|
messages, DTAP GPRS Session Management, DTAP Supplementary Services, DTAP
|
|
Special Conformance Testing Functions, and SACCH Radio Resource Management.
|
|
|
|
Unlike the individual statistics for each category that follow, this only
|
|
prints a line for each message type that appears, instead of including lines
|
|
for message types with a count of zero.
|
|
--
|
|
|
|
*-z* gsm_a,__category__[,__filter__]::
|
|
+
|
|
--
|
|
Count the number of messages of each type in GSM A-I/F __category__, which
|
|
can be one of:
|
|
|
|
bssmap BSSMAP
|
|
dtap_cc DTAP Call Control
|
|
dtap_gmm DTAP GPRS Mobility Management
|
|
dtap_mm DTAP Mobility Management
|
|
dtap_rr DTAP Radio Resource Management
|
|
dtap_sacch SACCH Radio Resource Management
|
|
dtap_sm DTAP GPRS Session Managment
|
|
dtap_sms DTAP Short Message Service
|
|
dtap_ss DTAP Supplementary Services
|
|
dtap_tp DTAP Special Conformance Testing Functions
|
|
--
|
|
|
|
*-z* gsm_map,operation[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on GSM MAP. For each op code, the total number of
|
|
invokes and results, along with the average and total bytes for invokes
|
|
and results separately and combined is displayed.
|
|
--
|
|
|
|
*-z* gtp,srt[,__filter__]::
|
|
+
|
|
--
|
|
Collect requests/response SRT (Service Response Time) data for GTP.
|
|
Data collected is the number of calls, minimum SRT, maximum SRT, average
|
|
SRT, and sum SRT for certain commands. Currently no statistics are gathered
|
|
on unpaired messages.
|
|
--
|
|
|
|
*-z* gtpv2,srt[,__filter__]::
|
|
+
|
|
--
|
|
Collect requests/response SRT (Service Response Time) data for GTP.
|
|
Data collected is the number of calls, minimum SRT, maximum SRT, average
|
|
SRT, and sum SRT for certain commands. Currently no statistics are gathered
|
|
on unpaired messages.
|
|
--
|
|
|
|
*-z* h225,counter[,__filter__]::
|
|
+
|
|
--
|
|
Count ITU-T H.225 messages and their reasons. In the first column you get a
|
|
list of H.225 messages and H.225 message reasons, which occur in the current
|
|
capture file. The number of occurrences of each message or reason is displayed
|
|
in the second column.
|
|
|
|
Example: *-z h225,counter*.
|
|
|
|
Example: use *-z "h225,counter,ip.addr==1.2.3.4"* to only collect stats for
|
|
H.225 packets exchanged by the host at IP address 1.2.3.4 .
|
|
|
|
This option can be used multiple times on the command line.
|
|
--
|
|
|
|
*-z* h225_ras,rtd[,__filter__]::
|
|
+
|
|
--
|
|
Collect requests/response RTD (Response Time Delay) data for ITU-T H.225 RAS.
|
|
Data collected is number of calls of each ITU-T H.225 RAS Message Type,
|
|
Minimum RTD, Maximum RTD, Average RTD, Minimum in Frame, and Maximum in Frame.
|
|
You will also get the number of Open Requests (Unresponded Requests),
|
|
Discarded Responses (Responses without matching request) and Duplicate Messages.
|
|
|
|
Example: *tshark -z h225_ras,rtd*
|
|
|
|
This option can be used multiple times on the command line.
|
|
|
|
Example: *-z "h225_ras,rtd,ip.addr==1.2.3.4"* will only collect stats for
|
|
ITU-T H.225 RAS packets exchanged by the host at IP address 1.2.3.4 .
|
|
--
|
|
|
|
*-z* hart_ip,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on HART-IP packets, grouping by message types and
|
|
message IDs within types.
|
|
--
|
|
|
|
*-z* hosts[,ip][,ipv4][,ipv6]::
|
|
+
|
|
--
|
|
Dump any collected resolved IPv4 and/or IPv6 addresses in "hosts" format.
|
|
Both IPv4 and IPv6 addresses are dumped by default. "ip" argument will dump
|
|
only IPv4 addresses.
|
|
|
|
Addresses are collected from a number of sources, including standard "hosts"
|
|
files and captured traffic. Resolution must be enabled, e.g. through the
|
|
*-n* option.
|
|
--
|
|
|
|
*-z* hpfeeds,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics for HPFEEDS traffic such as publish per channel, and opcode
|
|
distribution.
|
|
--
|
|
|
|
*-z* http,stat[,__filter__]::
|
|
+
|
|
--
|
|
Count the HTTP response status codes and the HTTP request methods.
|
|
--
|
|
|
|
*-z* http,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate the HTTP packet distribution. Displayed values are the
|
|
response status codes and request methods.
|
|
--
|
|
|
|
*-z* http_req,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate the HTTP requests by server. Displayed values are the
|
|
server name and the URI path.
|
|
--
|
|
|
|
*-z* http_seq,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate the HTTP request sequence statistics, which correlate
|
|
referring URIs with request URIs.
|
|
--
|
|
|
|
*-z* http_srv,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate the HTTP requests and responses by server. For the HTTP
|
|
requests, displayed values are the server IP address and server
|
|
hostname. For the HTTP responses, displayed values are the server
|
|
IP address and status.
|
|
--
|
|
|
|
*-z* http2,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate the HTTP/2 packet distribution. Displayed values are the
|
|
frame types.
|
|
--
|
|
|
|
*-z* icmp,srt[,__filter__]::
|
|
+
|
|
--
|
|
Compute total ICMP echo requests, replies, loss, and percent loss, as well as
|
|
minimum, maximum, mean, median and sample standard deviation SRT statistics
|
|
typical of what ping provides.
|
|
|
|
Example: [.nowrap]#*-z icmp,srt,ip.src==1.2.3.4*# will collect ICMP SRT statistics
|
|
for ICMP echo request packets originating from a specific host.
|
|
|
|
This option can be used multiple times on the command line.
|
|
--
|
|
|
|
*-z* icmpv6,srt[,__filter__]::
|
|
+
|
|
--
|
|
Compute total ICMPv6 echo requests, replies, loss, and percent loss, as well as
|
|
minimum, maximum, mean, median and sample standard deviation SRT statistics
|
|
typical of what ping provides.
|
|
|
|
Example: [.nowrap]#*-z icmpv6,srt,ipv6.src==fe80::1*# will collect ICMPv6 SRT statistics
|
|
for ICMPv6 echo request packets originating from a specific host.
|
|
|
|
This option can be used multiple times on the command line.
|
|
--
|
|
|
|
*-z* io,phs[,__filter__]::
|
|
+
|
|
--
|
|
Create Protocol Hierarchy Statistics listing both number of packets and bytes.
|
|
|
|
This option can be used multiple times on the command line.
|
|
--
|
|
|
|
*-z* io,stat,__interval__[,__filter__][,__filter__][,__filter__]...::
|
|
+
|
|
--
|
|
Collect packet/bytes statistics for the capture in intervals of
|
|
__interval__ seconds. __Interval__ can be specified either as a whole or
|
|
fractional second and can be specified with microsecond (us) resolution.
|
|
If __interval__ is 0, the statistics will be calculated over all packets.
|
|
|
|
If one or more __filters__ are specified statistics will be calculated for
|
|
all filters and presented with one column of statistics for each filter.
|
|
|
|
This option can be used multiple times on the command line.
|
|
|
|
Example: *-z io,stat,1,ip.addr==1.2.3.4* will generate 1 second
|
|
statistics for all traffic to/from host 1.2.3.4.
|
|
|
|
Example: *-z "io,stat,0.001,smb&&ip.addr==1.2.3.4"* will generate 1ms
|
|
statistics for all SMB packets to/from host 1.2.3.4.
|
|
|
|
The examples above all use the standard syntax for generating statistics
|
|
which only calculates the number of packets and bytes in each interval.
|
|
|
|
*io,stat* can also do much more statistics and calculate COUNT(), SUM(),
|
|
MIN(), MAX(), AVG() and LOAD() using a slightly different filter syntax:
|
|
--
|
|
|
|
-z io,stat,__interval__,"COUNT|SUM|MIN|MAX|AVG|LOAD(__field__)__filter__"::
|
|
+
|
|
--
|
|
NOTE: One important thing to note here is that the filter is not optional
|
|
and that the field that the calculation is based on MUST be part of the filter
|
|
string or the calculation will fail.
|
|
|
|
So: *-z io,stat,0.010,AVG(smb.time)* does not work. Use *-z
|
|
io,stat,0.010,AVG(smb.time)smb.time* instead. Also be aware that a field
|
|
can exist multiple times inside the same packet and will then be counted
|
|
multiple times in those packets.
|
|
|
|
NOTE: A second important thing to note is that the system setting for
|
|
decimal separator must be set to "."! If it is set to "," the statistics
|
|
will not be displayed per filter.
|
|
|
|
**COUNT** - Calculates the number of times that the
|
|
field __name__ (not its value) appears per interval in the filtered packet list.
|
|
''__field__'' can be any display filter name.
|
|
|
|
Example: *-z io,stat,0.010,"COUNT(smb.sid)smb.sid"*
|
|
|
|
This will count the total number of SIDs seen in each 10ms interval.
|
|
|
|
**SUM** - Unlike COUNT, the __values__ of the
|
|
specified field are summed per time interval.
|
|
''__field__'' can only be a named integer, float, double or relative time field.
|
|
|
|
Example: *tshark -z io,stat,0.010,"SUM(frame.len)frame.len"*
|
|
|
|
Reports the total number of bytes that were transmitted bidirectionally in
|
|
all the packets within a 10 millisecond interval.
|
|
|
|
**MIN/MAX/AVG** - The minimum, maximum, or average field value
|
|
in each interval is calculated. The specified field must be a named integer,
|
|
float, double or relative time field. For relative time fields, the output is
|
|
presented in seconds with six decimal digits of precision rounded to the nearest
|
|
microsecond.
|
|
|
|
In the following example, the time of the first Read_AndX call, the last Read_AndX
|
|
response values are displayed and the minimum, maximum, and average Read response times
|
|
(SRTs) are calculated. NOTE: If the DOS command shell line continuation character, ''^''
|
|
is used, each line cannot end in a comma so it is placed at the beginning of each
|
|
continuation line:
|
|
|
|
tshark -o tcp.desegment_tcp_streams:FALSE -n -q -r smb_reads.cap -z io,stat,0,
|
|
"MIN(frame.time_relative)frame.time_relative and smb.cmd==0x2e and smb.flags.response==0",
|
|
"MAX(frame.time_relative)frame.time_relative and smb.cmd==0x2e and smb.flags.response==1",
|
|
"MIN(smb.time)smb.time and smb.cmd==0x2e",
|
|
"MAX(smb.time)smb.time and smb.cmd==0x2e",
|
|
"AVG(smb.time)smb.time and smb.cmd==0x2e"
|
|
|
|
======================================================================================================
|
|
IO Statistics
|
|
Column #0: MIN(frame.time_relative)frame.time_relative and smb.cmd==0x2e and smb.flags.response==0
|
|
Column #1: MAX(frame.time_relative)frame.time_relative and smb.cmd==0x2e and smb.flags.response==1
|
|
Column #2: MIN(smb.time)smb.time and smb.cmd==0x2e
|
|
Column #3: MAX(smb.time)smb.time and smb.cmd==0x2e
|
|
Column #4: AVG(smb.time)smb.time and smb.cmd==0x2e
|
|
| Column #0 | Column #1 | Column #2 | Column #3 | Column #4 |
|
|
Time | MIN | MAX | MIN | MAX | AVG |
|
|
000.000- 0.000000 7.704054 0.000072 0.005539 0.000295
|
|
======================================================================================================
|
|
|
|
The following command displays the average SMB Read response PDU size, the
|
|
total number of read PDU bytes, the average SMB Write request PDU size, and
|
|
the total number of bytes transferred in SMB Write PDUs:
|
|
|
|
tshark -n -q -r smb_reads_writes.cap -z io,stat,0,
|
|
"AVG(smb.file.rw.length)smb.file.rw.length and smb.cmd==0x2e and smb.response_to",
|
|
"SUM(smb.file.rw.length)smb.file.rw.length and smb.cmd==0x2e and smb.response_to",
|
|
"AVG(smb.file.rw.length)smb.file.rw.length and smb.cmd==0x2f and not smb.response_to",
|
|
"SUM(smb.file.rw.length)smb.file.rw.length and smb.cmd==0x2f and not smb.response_to"
|
|
|
|
=====================================================================================
|
|
IO Statistics
|
|
Column #0: AVG(smb.file.rw.length)smb.file.rw.length and smb.cmd==0x2e and smb.response_to
|
|
Column #1: SUM(smb.file.rw.length)smb.file.rw.length and smb.cmd==0x2e and smb.response_to
|
|
Column #2: AVG(smb.file.rw.length)smb.file.rw.length and smb.cmd==0x2f and not smb.response_to
|
|
Column #3: SUM(smb.file.rw.length)smb.file.rw.length and smb.cmd==0x2f and not smb.response_to
|
|
| Column #0 | Column #1 | Column #2 | Column #3 |
|
|
Time | AVG | SUM | AVG | SUM |
|
|
000.000- 30018 28067522 72 3240
|
|
=====================================================================================
|
|
|
|
**LOAD** - The LOAD/Queue-Depth
|
|
in each interval is calculated. The specified field must be a relative time field that represents a response time. For example smb.time.
|
|
For each interval the Queue-Depth for the specified protocol is calculated.
|
|
|
|
The following command displays the average SMB LOAD.
|
|
A value of 1.0 represents one I/O in flight.
|
|
|
|
tshark -n -q -r smb_reads_writes.cap
|
|
-z "io,stat,0.001,LOAD(smb.time)smb.time"
|
|
|
|
============================================================================
|
|
IO Statistics
|
|
Interval: 0.001000 secs
|
|
Column #0: LOAD(smb.time)smb.time
|
|
| Column #0 |
|
|
Time | LOAD |
|
|
0000.000000-0000.001000 1.000000
|
|
0000.001000-0000.002000 0.741000
|
|
0000.002000-0000.003000 0.000000
|
|
0000.003000-0000.004000 1.000000
|
|
|
|
**FRAMES | BYTES**[()__filter__] - Displays the total number of frames or bytes.
|
|
The filter field is optional but if included it must be prepended with ''()''.
|
|
|
|
The following command displays five columns: the total number of frames and bytes
|
|
(transferred bidirectionally) using a single comma, the same two stats using the FRAMES and BYTES
|
|
subcommands, the total number of frames containing at least one SMB Read response, and
|
|
the total number of bytes transmitted to the client (unidirectionally) at IP address 10.1.0.64.
|
|
|
|
tshark -o tcp.desegment_tcp_streams:FALSE -n -q -r smb_reads.cap -z io,stat,0,,FRAMES,BYTES,
|
|
"FRAMES()smb.cmd==0x2e and smb.response_to","BYTES()ip.dst==10.1.0.64"
|
|
|
|
=======================================================================================================================
|
|
IO Statistics
|
|
Column #0:
|
|
Column #1: FRAMES
|
|
Column #2: BYTES
|
|
Column #3: FRAMES()smb.cmd==0x2e and smb.response_to
|
|
Column #4: BYTES()ip.dst==10.1.0.64
|
|
| Column #0 | Column #1 | Column #2 | Column #3 | Column #4 |
|
|
Time | Frames | Bytes | FRAMES | BYTES | FRAMES | BYTES |
|
|
000.000- 33576 29721685 33576 29721685 870 29004801
|
|
=======================================================================================================================
|
|
--
|
|
|
|
*-z* ip_hosts,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on IPv4 addresses, with source and destination addresses
|
|
all grouped together.
|
|
--
|
|
|
|
*-z* ip_srcdst,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on IPv4 addresses, with source and destination addresses
|
|
separated into separate categories.
|
|
--
|
|
|
|
*-z* ip6_dests,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on IPv6 destination addresses and the protocols
|
|
and ports appearing on each address.
|
|
--
|
|
|
|
*-z* ip6_hosts,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on IPv6 addresses, with source and destination addresses
|
|
all grouped together.
|
|
--
|
|
|
|
*-z* ip6_ptype,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on port types that occur on IPv6 packets.
|
|
--
|
|
|
|
*-z* ip6_srcdst,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on IPv6 addresses, with source and destination addresses
|
|
separated into separate categories.
|
|
--
|
|
|
|
*-z* isup_msg,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on ISUP messages. Displayed information is message
|
|
types and direction (originating point code and destination point code.)
|
|
--
|
|
|
|
*-z* lbmr_queue_ads_queue,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on LBM Topic Resolution Packets. Displays queue
|
|
advertisements collated by queue name and then source addresses and port.
|
|
--
|
|
|
|
*-z* lbmr_queue_ads_source,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on LBM Topic Resolution Packets. Displays queue
|
|
advertisements collated by source address and then queue and port.
|
|
--
|
|
|
|
*-z* lbmr_queue_queries_queue,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on LBM Topic Resolution Packets. Displays queue
|
|
queries collated by queue name and then receiver addresses.
|
|
--
|
|
|
|
*-z* lbmr_queue_queries_receiver,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on LBM Topic Resolution Packets. Displays queue
|
|
queries collated by receiver address and then queue.
|
|
--
|
|
|
|
*-z* lbmr_topic_ads_source,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on LBM Topic Resolution Packets. Displays topic
|
|
advertisements collated by source address and then topic name and
|
|
source string.
|
|
--
|
|
|
|
*-z* lbmr_topic_ads_topic,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on LBM Topic Resolution Packets. Displays topic
|
|
advertisements collated by topic name and then source address and
|
|
source string.
|
|
--
|
|
|
|
*-z* lbmr_topic_ads_transport,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on LBM Topic Resolution Packets. Displays topic
|
|
advertisements collated by source string and then topic name.
|
|
--
|
|
|
|
*-z* lbmr_topic_queries_pattern,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on LBM Topic Resolution Packets. Displays topic
|
|
queries collated by pattern and then receiver address.
|
|
--
|
|
|
|
*-z* lbmr_topic_queries_pattern_receiver,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on LBM Topic Resolution Packets. Displays topic
|
|
queries collated by receiver address and then pattern.
|
|
--
|
|
|
|
*-z* lbmr_topic_queries_receiver,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on LBM Topic Resolution Packets. Displays topic
|
|
queries collated by receiver address and then topic name.
|
|
--
|
|
|
|
*-z* lbmr_topic_queries_topic,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on LBM Topic Resolution Packets. Displays topic
|
|
queries collated by topic name and then receiver address.
|
|
--
|
|
|
|
*-z* mac-lte,stat[,__filter__]::
|
|
+
|
|
--
|
|
This option will activate a counter for LTE MAC messages. You will get
|
|
information about the maximum number of UEs/TTI, common messages and
|
|
various counters for each UE that appears in the log.
|
|
|
|
Example: *tshark -z mac-lte,stat*.
|
|
|
|
This option can be used multiple times on the command line.
|
|
|
|
Example: *-z "mac-lte,stat,mac-lte.rnti>3000"* will only collect stats for
|
|
UEs with an assigned RNTI whose value is more than 3000.
|
|
--
|
|
|
|
*-z* megaco,rtd[,__filter__]::
|
|
+
|
|
--
|
|
Collect requests/response RTD (Response Time Delay) data for MEGACO.
|
|
(This is similar to *-z smb,srt*). Data collected is the number of calls
|
|
for each known MEGACO Type, MinRTD, MaxRTD and AvgRTD.
|
|
Additionally you get the number of duplicate requests/responses,
|
|
unresponded requests, responses, which don't match with any request.
|
|
Example: *-z megaco,rtd*.
|
|
|
|
Example: *-z "megaco,rtd,ip.addr==1.2.3.4"* will only collect stats for
|
|
MEGACO packets exchanged by the host at IP address 1.2.3.4 .
|
|
|
|
This option can be used multiple times on the command line.
|
|
--
|
|
|
|
*-z* mgcp,rtd[,__filter__]::
|
|
+
|
|
--
|
|
Collect requests/response RTD (Response Time Delay) data for MGCP.
|
|
(This is similar to *-z smb,srt*). Data collected is the number of calls
|
|
for each known MGCP Type, MinRTD, MaxRTD and AvgRTD.
|
|
Additionally you get the number of duplicate requests/responses,
|
|
unresponded requests, responses, which don't match with any request.
|
|
Example: *-z mgcp,rtd*.
|
|
|
|
This option can be used multiple times on the command line.
|
|
|
|
Example: *-z "mgcp,rtd,ip.addr==1.2.3.4"* will only collect stats for
|
|
MGCP packets exchanged by the host at IP address 1.2.3.4 .
|
|
--
|
|
|
|
*-z* mtp3,msus[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statisics on MTP3 MSUs. For each combination of originating
|
|
point code, destination point code, and service indicator, calculates
|
|
the total number of MSUs, the total bytes, and the average bytes per MSU.
|
|
--
|
|
|
|
*-z* ncp,srt[,__filter__]::
|
|
+
|
|
--
|
|
Collect requests/response SRT (Service Response Time) data for Netware
|
|
Core Protocol. Minimum SRT, maximum SRT, average SRT, and sum SRT is
|
|
displayed for request/response pairs, organized by group, function and
|
|
subfunction, and verb. No statistics are gathered on unpaired messages.
|
|
--
|
|
|
|
*-z* osmux,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics for the OSmux voice/signaling multiplex protocol.
|
|
Displays the total number of OSmux packets, and displays for each stream
|
|
the number of packets, number of packets with the RTP market bit set,
|
|
number of AMR frames, jitter analysis, and sequence number analysis.
|
|
--
|
|
|
|
*-z* pingpongprotocol,stat[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on the Ping Pong Protocol of Reliable
|
|
Server Pooling. For each message type, displays the number, rate
|
|
and share among all message types of both packets and bytes, and the
|
|
first and last time that it is seen.
|
|
--
|
|
|
|
*-z* plen,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on packet lengths. Packets are grouped into buckets
|
|
that grow exponentially with powers of two.
|
|
--
|
|
|
|
*-z* proto,colinfo,__filter__,__field__::
|
|
+
|
|
--
|
|
Append all __field__ values for the packet to the Info column of the
|
|
one-line summary output.
|
|
This feature can be used to append arbitrary fields to the Info column
|
|
in addition to the normal content of that column.
|
|
__field__ is the display-filter name of a field which value should be placed
|
|
in the Info column.
|
|
__filter__ is a filter string that controls for which packets the field value
|
|
will be presented in the info column. __field__ will only be presented in the
|
|
Info column for the packets which match __filter__.
|
|
|
|
NOTE: In order for *TShark* to be able to extract the __field__ value
|
|
from the packet, __field__ MUST be part of the __filter__ string. If not,
|
|
*TShark* will not be able to extract its value.
|
|
|
|
For a simple example to add the "nfs.fh.hash" field to the Info column
|
|
for all packets containing the "nfs.fh.hash" field, use
|
|
|
|
*-z proto,colinfo,nfs.fh.hash,nfs.fh.hash*
|
|
|
|
To put "nfs.fh.hash" in the Info column but only for packets coming from
|
|
host 1.2.3.4 use:
|
|
|
|
*-z "proto,colinfo,nfs.fh.hash && ip.src==1.2.3.4,nfs.fh.hash"*
|
|
|
|
This option can be used multiple times on the command line.
|
|
--
|
|
|
|
*-z* ptype,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on port types that occur on IPv4 packets.
|
|
--
|
|
|
|
*-z* radius,rtd[,__filter__]::
|
|
+
|
|
--
|
|
Collect requests/response RTD (Response Time Delay) data for RADIUS.
|
|
The data collected for each RADIUS code is the number of calls,
|
|
Minimum RTD, Maximum RTD, Average RTD, Minimum in Frame, and Maximum in Frame,
|
|
along with the number of Open Requests (Unresponded Requests), Discarded
|
|
Responses (Responses without matching request) and Duplicate Messages.
|
|
--
|
|
|
|
*-z* rlc-lte,stat[,__filter__]::
|
|
+
|
|
--
|
|
This option will activate a counter for LTE RLC messages. You will get
|
|
information about common messages and various counters for each UE that appears
|
|
in the log.
|
|
|
|
Example: *tshark -z rlc-lte,stat*.
|
|
|
|
This option can be used multiple times on the command line.
|
|
|
|
Example: *-z "rlc-lte,stat,rlc-lte.ueid>3000"* will only collect stats for
|
|
UEs with a UEId of more than 3000.
|
|
--
|
|
|
|
*-z* rpc,programs::
|
|
+
|
|
--
|
|
Collect call/reply SRT data for all known ONC-RPC programs/versions.
|
|
Data collected is number of calls for each protocol/version, MinSRT,
|
|
MaxSRT and AvgSRT.
|
|
This option can only be used once on the command line.
|
|
--
|
|
|
|
*-z* rpc,srt,__program__,__version__[,__filter__]::
|
|
+
|
|
--
|
|
Collect call/reply SRT (Service Response Time) data for __program__/__version__.
|
|
Data collected is the number of calls for each procedure, MinSRT, MaxSRT,
|
|
AvgSRT, and the total time taken for each procedure.
|
|
|
|
Example: *tshark -z rpc,srt,100003,3* will collect data for NFS v3.
|
|
|
|
This option can be used multiple times on the command line.
|
|
|
|
Example: *-z rpc,srt,100003,3,nfs.fh.hash==0x12345678* will collect NFS v3
|
|
SRT statistics for a specific file.
|
|
--
|
|
|
|
*-z* rtp,streams::
|
|
+
|
|
--
|
|
Collect statistics for all RTP streams and calculate max. delta, max. and
|
|
mean jitter and packet loss percentages.
|
|
--
|
|
|
|
*-z* rtsp,stat[,__filter__]::
|
|
+
|
|
--
|
|
Count the RTSP response status codes and the RSTP request methods.
|
|
--
|
|
|
|
*-z* rtsp,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate the RTSP packet distribution. Displayed values are the
|
|
response status codes and request methods.
|
|
--
|
|
|
|
*-z* sametime,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate statistics on SAMETIME messages. Displayed values are the
|
|
messages type, send type, and user status.
|
|
--
|
|
|
|
*-z* scsi,srt,__cmdset__[,__filter__]::
|
|
+
|
|
--
|
|
Collect call/reply SRT (Service Response Time) data for SCSI commandset __cmdset__.
|
|
|
|
Commandsets are 0:SBC 1:SSC 5:MMC
|
|
|
|
Data collected
|
|
is the number of calls for each procedure, MinSRT, MaxSRT and AvgSRT.
|
|
|
|
Example: *-z scsi,srt,0* will collect data for SCSI BLOCK COMMANDS (SBC).
|
|
|
|
This option can be used multiple times on the command line.
|
|
|
|
Example: *-z scsi,srt,0,ip.addr==1.2.3.4* will collect SCSI SBC
|
|
SRT statistics for a specific iscsi/ifcp/fcip host.
|
|
--
|
|
|
|
*-z* sctp,stat::
|
|
+
|
|
--
|
|
Activate a counter for SCTP chunks. In addition to the total number of
|
|
SCTP packets, for each source and destination address and port combination
|
|
the number of chunks of the most common types (DATA, SACK, HEARTBEAT,
|
|
HEARTBEAT ACK, INIT, INIT ACK, COOKIE ECHO, COOKIE ACK, ABORT, and ERROR)
|
|
are displayed.
|
|
--
|
|
|
|
*-z* sip,stat[,__filter__]::
|
|
+
|
|
--
|
|
This option will activate a counter for SIP messages. You will get the number
|
|
of occurrences of each SIP Method and of each SIP Status-Code. Additionally
|
|
you also get the number of resent SIP Messages (only for SIP over UDP).
|
|
|
|
Example: *-z sip,stat*.
|
|
|
|
This option can be used multiple times on the command line.
|
|
|
|
Example: *-z "sip,stat,ip.addr==1.2.3.4"* will only collect stats for
|
|
SIP packets exchanged by the host at IP address 1.2.3.4 .
|
|
--
|
|
|
|
*-z* smb,sids::
|
|
+
|
|
--
|
|
When this feature is used *TShark* will print a report with all the
|
|
discovered SID and account name mappings. Only those SIDs where the
|
|
account name is known will be presented in the table.
|
|
|
|
For this feature to work you will need to either to enable
|
|
"Edit/Preferences/Protocols/SMB/Snoop SID to name mappings" in the
|
|
preferences or you can override the preferences by specifying
|
|
[.nowrap]#*-o "smb.sid_name_snooping:TRUE"*# on the *TShark* command line.
|
|
|
|
The current method used by *TShark* to find the SID->name mapping
|
|
is relatively restricted with a hope of future expansion.
|
|
--
|
|
|
|
*-z* smb,srt[,__filter__]::
|
|
+
|
|
--
|
|
Collect call/reply SRT (Service Response Time) data for SMB. Data collected
|
|
is number of calls for each SMB command, MinSRT, MaxSRT and AvgSRT.
|
|
|
|
Example: *-z smb,srt*
|
|
|
|
The data will be presented as separate tables for all normal SMB commands,
|
|
all Transaction2 commands and all NT Transaction commands.
|
|
Only those commands that are seen in the capture will have its stats
|
|
displayed.
|
|
Only the first command in a xAndX command chain will be used in the
|
|
calculation. So for common SessionSetupAndX + TreeConnectAndX chains,
|
|
only the SessionSetupAndX call will be used in the statistics.
|
|
This is a flaw that might be fixed in the future.
|
|
|
|
This option can be used multiple times on the command line.
|
|
|
|
Example: *-z "smb,srt,ip.addr==1.2.3.4"* will only collect stats for
|
|
SMB packets exchanged by the host at IP address 1.2.3.4 .
|
|
--
|
|
|
|
*-z* smb2,srt[,__filter__]::
|
|
+
|
|
--
|
|
Collect call/reply SRT (Service Response Time) data for SMB versions 2 and 3.
|
|
The data collected for each normal command type is the number of calls,
|
|
MinSRT, MaxSRT, AvgSRT, and SumSRT. No data is collected on cancel or
|
|
oplock break requests, or on unpaired commands. Only the first response to
|
|
a given request is used; retransmissions are not included in the calculation.
|
|
--
|
|
|
|
*-z* smpp_commands,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate the SMPP command distribution. Displayed values are
|
|
command IDs for both requests and responses, and status for responses.
|
|
--
|
|
|
|
*-z* snmp,srt[,__filter__]::
|
|
+
|
|
--
|
|
Collect call/reply SRT (Service Response Time) data for SNMP. The data
|
|
collected for each PDU type is the number of request/response pairs,
|
|
MinSRT, MaxSRT, AvgSRT, and SumSRT. No data is collected on unpaired
|
|
messages.
|
|
--
|
|
|
|
*-z* someip_messages,tree[,__filter__]::
|
|
+
|
|
--
|
|
Create statistic of SOME/IP messages. Messages are counted and displayed
|
|
as Messages grouped by sender/receiver.
|
|
--
|
|
|
|
*-z* someipsd_entries,tree[,__filter__]::
|
|
+
|
|
--
|
|
Create statistic of SOME/IP-SD entries. Entries are counted and displayed
|
|
as Entries grouped by sender/receiver.
|
|
--
|
|
|
|
*-z* sv::
|
|
+
|
|
--
|
|
Print out the time since the start of the capture and sample count for each
|
|
IEC 61850 Sampled Values packet.
|
|
--
|
|
|
|
*-z* ucp_messages,tree[,__filter__]::
|
|
+
|
|
--
|
|
Calculate the message distribution of UCP packets. Displayed values are
|
|
operation types for both operations and results, and whether results are
|
|
positive or negative, with error codes displayed for negative results.
|
|
--
|
|
|
|
*-z* wsp,stat[,__filter__]::
|
|
+
|
|
--
|
|
Count the PDU types and the status codes of reply packets for WSP packets.
|
|
--
|
|
|
|
--capture-comment <comment>::
|
|
+
|
|
--
|
|
Add a capture comment to the output file, if supported by the output
|
|
file format.
|
|
|
|
This option may be specified multiple times. Note that Wireshark
|
|
currently only displays the first comment of a capture file.
|
|
--
|
|
|
|
--list-time-stamp-types::
|
|
+
|
|
--
|
|
List time stamp types supported for the interface. If no time stamp type can be
|
|
set, no time stamp types are listed.
|
|
--
|
|
|
|
--time-stamp-type <type>::
|
|
+
|
|
--
|
|
Change the interface's timestamp method.
|
|
--
|
|
|
|
--color::
|
|
+
|
|
--
|
|
Enable coloring of packets according to standard Wireshark color
|
|
filters. On Windows colors are limited to the standard console
|
|
character attribute colors. Other platforms require a terminal that
|
|
handles 24-bit "true color" terminal escape sequences. See
|
|
https://gitlab.com/wireshark/wireshark/-/wikis/ColoringRules for more information on
|
|
configuring color filters.
|
|
--
|
|
|
|
--no-duplicate-keys::
|
|
+
|
|
--
|
|
If a key appears multiple times in an object, only write it a single time with
|
|
as value a json array containing all the separate values. (Only works with
|
|
-T json)
|
|
--
|
|
|
|
--elastic-mapping-filter <protocol>,<protocol>,...::
|
|
+
|
|
--
|
|
When generating the ElasticSearch mapping file, only put the specified protocols
|
|
in it, to avoid a huge mapping file that can choke some software (such as Kibana).
|
|
The option takes a list of wanted protocol abbreviations, separated by comma.
|
|
|
|
Example: ip,udp,dns puts only those three protocols in the mapping file.
|
|
--
|
|
|
|
--export-objects <protocol>,<destdir>::
|
|
+
|
|
--
|
|
Export all objects within a protocol into directory *destdir*. The available
|
|
values for *protocol* can be listed with *--export-objects help*.
|
|
|
|
The objects are directly saved in the given directory. Filenames are dependent
|
|
on the dissector, but typically it is named after the basename of a file.
|
|
Duplicate files are not overwritten, instead an increasing number is appended
|
|
before the file extension.
|
|
|
|
This interface is subject to change, adding the possibility to filter on files.
|
|
--
|
|
|
|
--enable-protocol <proto_name>::
|
|
+
|
|
--
|
|
Enable dissection of proto_name.
|
|
--
|
|
|
|
--disable-protocol <proto_name>::
|
|
+
|
|
--
|
|
Disable dissection of proto_name.
|
|
--
|
|
|
|
--enable-heuristic <short_name>::
|
|
+
|
|
--
|
|
Enable dissection of heuristic protocol.
|
|
--
|
|
|
|
--disable-heuristic <short_name>::
|
|
+
|
|
--
|
|
Disable dissection of heuristic protocol.
|
|
--
|
|
|
|
include::diagnostic-options.adoc[]
|
|
|
|
== CAPTURE FILTER SYNTAX
|
|
|
|
See the manual page of xref:https://www.tcpdump.org/manpages/pcap-filter.7.html[pcap-filter](7) or, if that doesn't exist, xref:https://www.tcpdump.org/manpages/tcpdump.1.html[tcpdump](8),
|
|
or, if that doesn't exist, https://gitlab.com/wireshark/wireshark/-/wikis/CaptureFilters.
|
|
|
|
== READ FILTER SYNTAX
|
|
|
|
For a complete table of protocol and protocol fields that are filterable
|
|
in *TShark* see the xref:wireshark-filter.html[wireshark-filter](4) manual page.
|
|
|
|
== FILES
|
|
|
|
These files contains various *Wireshark* configuration values.
|
|
|
|
Preferences::
|
|
+
|
|
--
|
|
The __preferences__ files contain global (system-wide) and personal
|
|
preference settings. If the system-wide preference file exists, it is
|
|
read first, overriding the default settings. If the personal preferences
|
|
file exists, it is read next, overriding any previous values. Note: If
|
|
the command line option *-o* is used (possibly more than once), it will
|
|
in turn override values from the preferences files.
|
|
|
|
The preferences settings are in the form __prefname:value__,
|
|
one per line,
|
|
where __prefname__ is the name of the preference
|
|
and __value__ is the value to
|
|
which it should be set; white space is allowed between *:* and
|
|
__value__. A preference setting can be continued on subsequent lines by
|
|
indenting the continuation lines with white space. A *#* character
|
|
starts a comment that runs to the end of the line:
|
|
|
|
# Capture in promiscuous mode?
|
|
# TRUE or FALSE (case-insensitive).
|
|
capture.prom_mode: TRUE
|
|
|
|
The global preferences file is looked for in the __wireshark__ directory
|
|
under the __share__ subdirectory of the main installation directory. On
|
|
macOS, this would typically be
|
|
__/Application/Wireshark.app/Contents/Resources/share__; on other
|
|
UNIX-compatible systems, such as Linux, \*BSD, Solaris, and AIX, this
|
|
would typically be __/usr/share/wireshark/preferences__ for
|
|
system-installed packages and __/usr/local/share/wireshark/preferences__
|
|
for locally-installed packages; on Windows, this would typically be
|
|
__C:\Program Files\Wireshark\preferences__.
|
|
|
|
On UNIX-compatible systems, the personal preferences file is looked for
|
|
in __$XDG_CONFIG_HOME/wireshark/preferences__, (or, if
|
|
__$XDG_CONFIG_HOME/wireshark__ does not exist while __$HOME/.wireshark__
|
|
does exist, __$HOME/.wireshark/preferences__); this is typically
|
|
__$HOME/.config/wireshark/preferences__. On Windows,
|
|
the personal preferences file is looked for in
|
|
__%APPDATA%\Wireshark\preferences__ (or, if %APPDATA% isn't defined,
|
|
__%USERPROFILE%\Application Data\Wireshark\preferences__).
|
|
--
|
|
|
|
Disabled (Enabled) Protocols::
|
|
+
|
|
--
|
|
The __disabled_protos__ files contain system-wide and personal lists of
|
|
protocols that have been disabled, so that their dissectors are never
|
|
called. The files contain protocol names, one per line, where the
|
|
protocol name is the same name that would be used in a display filter
|
|
for the protocol:
|
|
|
|
http
|
|
tcp # a comment
|
|
|
|
The global __disabled_protos__ file uses the same directory as the global
|
|
preferences file.
|
|
|
|
The personal __disabled_protos__ file uses the same directory as the
|
|
personal preferences file.
|
|
--
|
|
|
|
Name Resolution (hosts)::
|
|
+
|
|
--
|
|
If the personal __hosts__ file exists, it is
|
|
used to resolve IPv4 and IPv6 addresses before any other
|
|
attempts are made to resolve them. The file has the standard __hosts__
|
|
file syntax; each line contains one IP address and name, separated by
|
|
whitespace. The same directory as for the personal preferences file is
|
|
used.
|
|
|
|
Capture filter name resolution is handled by libpcap on UNIX-compatible
|
|
systems, such as Linux, macOS, \*BSD, Solaris, and AIX, and by Npcap or
|
|
WinPcap on Windows. As such the Wireshark personal __hosts__ file will
|
|
not be consulted for capture filter name resolution.
|
|
--
|
|
|
|
Name Resolution (subnets)::
|
|
+
|
|
--
|
|
If an IPv4 address cannot be translated via name resolution (no exact
|
|
match is found) then a partial match is attempted via the __subnets__ file.
|
|
|
|
Each line of this file consists of an IPv4 address, a subnet mask length
|
|
separated only by a / and a name separated by whitespace. While the address
|
|
must be a full IPv4 address, any values beyond the mask length are subsequently
|
|
ignored.
|
|
|
|
An example is:
|
|
|
|
# Comments must be prepended by the # sign!
|
|
192.168.0.0/24 ws_test_network
|
|
|
|
A partially matched name will be printed as "subnet-name.remaining-address".
|
|
For example, "192.168.0.1" under the subnet above would be printed as
|
|
"ws_test_network.1"; if the mask length above had been 16 rather than 24, the
|
|
printed address would be ``ws_test_network.0.1".
|
|
--
|
|
|
|
Name Resolution (ethers)::
|
|
+
|
|
--
|
|
The __ethers__ files are consulted to correlate 6-byte hardware addresses to
|
|
names. First the personal __ethers__ file is tried and if an address is not
|
|
found there the global __ethers__ file is tried next.
|
|
|
|
Each line contains one hardware address and name, separated by
|
|
whitespace. The digits of the hardware address are separated by colons
|
|
(:), dashes (-) or periods (.). The same separator character must be
|
|
used consistently in an address. The following three lines are valid
|
|
lines of an __ethers__ file:
|
|
|
|
ff:ff:ff:ff:ff:ff Broadcast
|
|
c0-00-ff-ff-ff-ff TR_broadcast
|
|
00.00.00.00.00.00 Zero_broadcast
|
|
|
|
The global __ethers__ file is looked for in the __/etc__ directory on
|
|
UNIX-compatible systems, such as Linux, macOS, \*BSD, Solaris, and AIX,
|
|
and in the main installation directory (for example, __C:\Program
|
|
Files\Wireshark__) on Windows systems.
|
|
|
|
The personal __ethers__ file is looked for in the same directory as the personal
|
|
preferences file.
|
|
|
|
Capture filter name resolution is handled by libpcap on UNIX-compatible
|
|
systems and Npcap or WinPcap on Windows. As such the Wireshark personal
|
|
__ethers__ file will not be consulted for capture filter name resolution.
|
|
--
|
|
|
|
Name Resolution (manuf)::
|
|
+
|
|
--
|
|
The __manuf__ file is used to match the 3-byte vendor portion of a 6-byte
|
|
hardware address with the manufacturer's name; it can also contain well-known
|
|
MAC addresses and address ranges specified with a netmask. The format of the
|
|
file is the same as the __ethers__ files, except that entries of the form:
|
|
|
|
00:00:0C Cisco
|
|
|
|
can be provided, with the 3-byte OUI and the name for a vendor, and
|
|
entries such as:
|
|
|
|
00-00-0C-07-AC/40 All-HSRP-routers
|
|
|
|
can be specified, with a MAC address and a mask indicating how many bits
|
|
of the address must match. The above entry, for example, has 40
|
|
significant bits, or 5 bytes, and would match addresses from
|
|
00-00-0C-07-AC-00 through 00-00-0C-07-AC-FF. The mask need not be a
|
|
multiple of 8.
|
|
|
|
The __manuf__ file is looked for in the same directory as the global
|
|
preferences file.
|
|
--
|
|
|
|
Name Resolution (services)::
|
|
+
|
|
--
|
|
The __services__ file is used to translate port numbers into names.
|
|
|
|
The file has the standard __services__ file syntax; each line contains one
|
|
(service) name and one transport identifier separated by white space. The
|
|
transport identifier includes one port number and one transport protocol name
|
|
(typically tcp, udp, or sctp) separated by a /.
|
|
|
|
An example is:
|
|
|
|
mydns 5045/udp # My own Domain Name Server
|
|
mydns 5045/tcp # My own Domain Name Server
|
|
--
|
|
|
|
Name Resolution (ipxnets)::
|
|
+
|
|
--
|
|
The __ipxnets__ files are used to correlate 4-byte IPX network numbers to
|
|
names. First the global __ipxnets__ file is tried and if that address is not
|
|
found there the personal one is tried next.
|
|
|
|
The format is the same as the __ethers__
|
|
file, except that each address is four bytes instead of six.
|
|
Additionally, the address can be represented as a single hexadecimal
|
|
number, as is more common in the IPX world, rather than four hex octets.
|
|
For example, these four lines are valid lines of an __ipxnets__ file:
|
|
|
|
C0.A8.2C.00 HR
|
|
c0-a8-1c-00 CEO
|
|
00:00:BE:EF IT_Server1
|
|
110f FileServer3
|
|
|
|
The global __ipxnets__ file is looked for in the __/etc__ directory on
|
|
UNIX-compatible systems, such as Linux, macOS, \*BSD, Solaris, and AIX,
|
|
and in the main installation directory (for example, __C:\Program
|
|
Files\Wireshark__) on Windows systems.
|
|
|
|
The personal __ipxnets__ file is looked for in the same directory as the
|
|
personal preferences file.
|
|
--
|
|
|
|
== OUTPUT
|
|
|
|
*TShark* uses UTF-8 to represent strings internally. In some cases the
|
|
output might not be valid. For example, a dissector might generate
|
|
invalid UTF-8 character sequences. Programs reading *TShark* output
|
|
should expect UTF-8 and be prepared for invalid output.
|
|
|
|
If *TShark* detects that it is writing to a TTY on a UNIX-compatible
|
|
system, such as Linux, macOS, \*BSD, Solaris, and AIX, and the locale
|
|
does not support UTF-8, output will be re-encoded to match the current
|
|
locale.
|
|
|
|
If *TShark* detects that it is writing to the console on Windows,
|
|
dissection output will be encoded as UTF-16LE. Other output will be
|
|
UTF-8. If extended characters don't display properly in your terminal
|
|
you might try setting your console code page to UTF-8 (*chcp 65001*)
|
|
and using a modern terminal application if possible.
|
|
|
|
== ENVIRONMENT VARIABLES
|
|
|
|
// Should this be moved to an include file?
|
|
|
|
WIRESHARK_CONFIG_DIR::
|
|
+
|
|
--
|
|
This environment variable overrides the location of personal
|
|
configuration files. On UNIX-compatible systems, such as Linux, macOS,
|
|
\*BSD, Solaris, and AIX, it defaults to __$XDG_CONFIG_HOME/wireshark__
|
|
(or, if that directory doesn't exist but __$HOME/.wireshark__ does
|
|
exist, __$HOME/.wireshark__); this is typically
|
|
__$HOME/.config/wireshark__. On Windows, it defaults to
|
|
__%APPDATA%\Wireshark__ (or, if %APPDATA% isn't defined,
|
|
__%USERPROFILE%\Application Data\Wireshark__). Available since
|
|
Wireshark 3.0.
|
|
--
|
|
|
|
WIRESHARK_DEBUG_WMEM_OVERRIDE::
|
|
+
|
|
--
|
|
Setting this environment variable forces the wmem framework to use the
|
|
specified allocator backend for *all* allocations, regardless of which
|
|
backend is normally specified by the code. This is mainly useful to developers
|
|
when testing or debugging. See __README.wmem__ in the source distribution for
|
|
details.
|
|
--
|
|
|
|
WIRESHARK_RUN_FROM_BUILD_DIRECTORY::
|
|
+
|
|
--
|
|
This environment variable causes the plugins and other data files to be
|
|
loaded from the build directory (where the program was compiled) rather
|
|
than from the standard locations. It has no effect when the program in
|
|
question is running with root (or setuid) permissions on UNIX-compatible
|
|
systems, such as Linux, macOS, \*BSD, Solaris, and AIX.
|
|
--
|
|
|
|
WIRESHARK_DATA_DIR::
|
|
+
|
|
--
|
|
This environment variable causes the various data files to be loaded from
|
|
a directory other than the standard locations. It has no effect when the
|
|
program in question is running with root (or setuid) permissions on
|
|
UNIX-compatible systems.
|
|
--
|
|
|
|
WIRESHARK_EXTCAP_DIR::
|
|
+
|
|
--
|
|
This environment variable causes the various extcap programs and scripts
|
|
to be run from a directory other than the standard locations. It has no
|
|
effect when the program in question is running with root (or setuid)
|
|
permissions on UNIX-compatible systems.
|
|
--
|
|
|
|
WIRESHARK_PLUGIN_DIR::
|
|
+
|
|
--
|
|
This environment variable causes the various plugins to be loaded from
|
|
a directory other than the standard locations. It has no effect when the
|
|
program in question is running with root (or setuid) permissions on
|
|
UNIX-compatible systems.
|
|
--
|
|
|
|
ERF_RECORDS_TO_CHECK::
|
|
+
|
|
--
|
|
This environment variable controls the number of ERF records checked when
|
|
deciding if a file really is in the ERF format. Setting this environment
|
|
variable a number higher than the default (20) would make false positives
|
|
less likely.
|
|
--
|
|
|
|
IPFIX_RECORDS_TO_CHECK::
|
|
+
|
|
--
|
|
This environment variable controls the number of IPFIX records checked when
|
|
deciding if a file really is in the IPFIX format. Setting this environment
|
|
variable a number higher than the default (20) would make false positives
|
|
less likely.
|
|
--
|
|
|
|
WIRESHARK_ABORT_ON_DISSECTOR_BUG::
|
|
+
|
|
--
|
|
If this environment variable is set, *TShark* will call abort(3)
|
|
when a dissector bug is encountered. abort(3) will cause the program to
|
|
exit abnormally; if you are running *TShark* in a debugger, it
|
|
should halt in the debugger and allow inspection of the process, and, if
|
|
you are not running it in a debugger, it will, on some OSes, assuming
|
|
your environment is configured correctly, generate a core dump file.
|
|
This can be useful to developers attempting to troubleshoot a problem
|
|
with a protocol dissector.
|
|
--
|
|
|
|
WIRESHARK_ABORT_ON_TOO_MANY_ITEMS::
|
|
+
|
|
--
|
|
If this environment variable is set, *TShark* will call abort(3)
|
|
if a dissector tries to add too many items to a tree (generally this
|
|
is an indication of the dissector not breaking out of a loop soon enough).
|
|
abort(3) will cause the program to exit abnormally; if you are running
|
|
*TShark* in a debugger, it should halt in the debugger and allow
|
|
inspection of the process, and, if you are not running it in a debugger,
|
|
it will, on some OSes, assuming your environment is configured correctly,
|
|
generate a core dump file. This can be useful to developers attempting to
|
|
troubleshoot a problem with a protocol dissector.
|
|
--
|
|
|
|
WIRESHARK_LOG_LEVEL::
|
|
+
|
|
--
|
|
This environment variable controls the verbosity of diagnostic messages to
|
|
the console. From less verbose to most verbose levels can be `critical`,
|
|
`warning`, `message`, `info`, `debug` or `noisy`. Levels above the
|
|
current level are also active. Levels `critical` and `error` are always
|
|
active.
|
|
--
|
|
|
|
WIRESHARK_LOG_FATAL::
|
|
+
|
|
--
|
|
Sets the fatal log level. Fatal log levels cause the program to abort.
|
|
This level can be set to `Error`, `critical` or `warning`. `Error` is
|
|
always fatal and is the default.
|
|
--
|
|
|
|
WIRESHARK_LOG_DOMAINS::
|
|
+
|
|
--
|
|
This environment variable selects which log domains are active. The filter is
|
|
given as a case-insensitive comma separated list. If set only the included
|
|
domains will be enabled. The default domain is always considered to be enabled.
|
|
Domain filter lists can be preceded by '!' to invert the sense of the match.
|
|
--
|
|
|
|
WIRESHARK_LOG_DEBUG::
|
|
+
|
|
--
|
|
List of domains with `debug` log level. This sets the level of the provided
|
|
log domains and takes precedence over the active domains filter. If preceded
|
|
by '!' this disables the `debug` level instead.
|
|
--
|
|
|
|
WIRESHARK_LOG_NOISY::
|
|
+
|
|
--
|
|
Same as above but for `noisy` log level instead.
|
|
--
|
|
|
|
== SEE ALSO
|
|
|
|
xref:wireshark-filter.html[wireshark-filter](4), xref:wireshark.html[wireshark](1), xref:editcap.html[editcap](1), xref:https://www.tcpdump.org/manpages/pcap.3pcap.html[pcap](3), xref:dumpcap.html[dumpcap](1),
|
|
xref:text2pcap.html[text2pcap](1), xref:mergecap.html[mergecap](1), xref:https://www.tcpdump.org/manpages/pcap-filter.7.html[pcap-filter](7) or xref:https://www.tcpdump.org/manpages/tcpdump.1.html[tcpdump](8)
|
|
|
|
== NOTES
|
|
|
|
This is the manual page for *TShark* {wireshark-version}.
|
|
*TShark* is part of the *Wireshark* distribution.
|
|
The latest version of *Wireshark* can be found at https://www.wireshark.org.
|
|
|
|
HTML versions of the Wireshark project man pages are available at
|
|
https://www.wireshark.org/docs/man-pages.
|
|
|
|
== AUTHORS
|
|
|
|
*TShark* uses the same packet dissection code that *Wireshark* does,
|
|
as well as using many other modules from *Wireshark*; see the list of
|
|
authors in the *Wireshark* man page for a list of authors of that code.
|