2503 lines
67 KiB
HTML
2503 lines
67 KiB
HTML
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<HTML><HEAD><TITLE>Man page of TCPDUMP</TITLE>
|
|
</HEAD><BODY>
|
|
<H1>TCPDUMP</H1>
|
|
Section: Maintenance Commands (8)<BR>Updated: 2 February 2017<BR><A HREF="#index">Index</A>
|
|
<A HREF="/cgi-bin/man/man2html">Return to Main Contents</A><HR>
|
|
|
|
<A NAME="lbAB"> </A>
|
|
<H2>NAME</H2>
|
|
|
|
tcpdump - dump traffic on a network
|
|
<A NAME="lbAC"> </A>
|
|
<H2>SYNOPSIS</H2>
|
|
|
|
|
|
<B>tcpdump</B>
|
|
|
|
[
|
|
<B>-AbdDefhHIJKlLnNOpqStuUvxX#</B>
|
|
|
|
] [
|
|
<B>-B</B>
|
|
|
|
<I>buffer_size</I>
|
|
|
|
]
|
|
<BR>
|
|
|
|
<BR>
|
|
|
|
[
|
|
<B>-c</B>
|
|
|
|
<I>count</I>
|
|
|
|
]
|
|
<BR>
|
|
|
|
<BR>
|
|
|
|
[
|
|
<B>-C</B>
|
|
|
|
<I>file_size</I>
|
|
|
|
] [
|
|
<B>-G</B>
|
|
|
|
<I>rotate_seconds</I>
|
|
|
|
] [
|
|
<B>-F</B>
|
|
|
|
<I>file</I>
|
|
|
|
]
|
|
<BR>
|
|
|
|
<BR>
|
|
|
|
[
|
|
<B>-i</B>
|
|
|
|
<I>interface</I>
|
|
|
|
]
|
|
[
|
|
<B>-j</B>
|
|
|
|
<I>tstamp_type</I>
|
|
|
|
]
|
|
[
|
|
<B>-m</B>
|
|
|
|
<I>module</I>
|
|
|
|
]
|
|
[
|
|
<B>-M</B>
|
|
|
|
<I>secret</I>
|
|
|
|
]
|
|
<BR>
|
|
|
|
<BR>
|
|
|
|
[
|
|
<B>--number</B>
|
|
|
|
]
|
|
[
|
|
<B>-Q</B>
|
|
|
|
<I>in|out|inout</I>
|
|
|
|
]
|
|
<BR>
|
|
|
|
[
|
|
<B>-r</B>
|
|
|
|
<I>file</I>
|
|
|
|
]
|
|
[
|
|
<B>-V</B>
|
|
|
|
<I>file</I>
|
|
|
|
]
|
|
[
|
|
<B>-s</B>
|
|
|
|
<I>snaplen</I>
|
|
|
|
]
|
|
[
|
|
<B>-T</B>
|
|
|
|
<I>type</I>
|
|
|
|
]
|
|
[
|
|
<B>-w</B>
|
|
|
|
<I>file</I>
|
|
|
|
]
|
|
<BR>
|
|
|
|
<BR>
|
|
|
|
[
|
|
<B>-W</B>
|
|
|
|
<I>filecount</I>
|
|
|
|
]
|
|
<BR>
|
|
|
|
<BR>
|
|
|
|
[
|
|
<B>-E</B>
|
|
|
|
<I><A HREF="mailto:spi@ipaddr">spi@ipaddr</A> algo:secret,...</I>
|
|
|
|
]
|
|
<BR>
|
|
|
|
<BR>
|
|
|
|
[
|
|
<B>-y</B>
|
|
|
|
<I>datalinktype</I>
|
|
|
|
]
|
|
[
|
|
<B>-z</B>
|
|
|
|
<I>postrotate-command</I>
|
|
|
|
]
|
|
[
|
|
<B>-Z</B>
|
|
|
|
<I>user</I>
|
|
|
|
]
|
|
<BR>
|
|
|
|
[
|
|
<B>--time-stamp-precision=</B><I>tstamp_precision</I>
|
|
|
|
]
|
|
<BR>
|
|
|
|
[
|
|
<B>--immediate-mode</B>
|
|
|
|
]
|
|
[
|
|
<B>--version</B>
|
|
|
|
]
|
|
<BR>
|
|
|
|
[
|
|
<I>expression</I>
|
|
|
|
]
|
|
<BR>
|
|
|
|
|
|
<A NAME="lbAD"> </A>
|
|
<H2>DESCRIPTION</H2>
|
|
|
|
<P>
|
|
|
|
<I>Tcpdump</I> prints out a description of the contents of packets on a
|
|
network interface that match the boolean <I>expression</I>; the
|
|
description is preceded by a time stamp, printed, by default, as hours,
|
|
minutes, seconds, and fractions of a second since midnight. It can also
|
|
be run with the
|
|
<B>-w</B>
|
|
|
|
flag, which causes it to save the packet data to a file for later
|
|
analysis, and/or with the
|
|
<B>-r</B>
|
|
|
|
flag, which causes it to read from a saved packet file rather than to
|
|
read packets from a network interface. It can also be run with the
|
|
<B>-V</B>
|
|
|
|
flag, which causes it to read a list of saved packet files. In all cases,
|
|
only packets that match
|
|
<I>expression</I>
|
|
|
|
will be processed by
|
|
<I>tcpdump</I>.
|
|
|
|
<P>
|
|
|
|
<I>Tcpdump</I>
|
|
|
|
will, if not run with the
|
|
<B>-c</B>
|
|
|
|
flag, continue capturing packets until it is interrupted by a SIGINT
|
|
signal (generated, for example, by typing your interrupt character,
|
|
typically control-C) or a SIGTERM signal (typically generated with the
|
|
<B><A HREF="/cgi-bin/man/man2html?1+kill">kill</A></B>(1)
|
|
|
|
command); if run with the
|
|
<B>-c</B>
|
|
|
|
flag, it will capture packets until it is interrupted by a SIGINT or
|
|
SIGTERM signal or the specified number of packets have been processed.
|
|
<P>
|
|
|
|
When
|
|
<I>tcpdump</I>
|
|
|
|
finishes capturing packets, it will report counts of:
|
|
<DL COMPACT>
|
|
<DT id="1"><DD>
|
|
packets ``captured'' (this is the number of packets that
|
|
<I>tcpdump</I>
|
|
|
|
has received and processed);
|
|
<DT id="2"><DD>
|
|
packets ``received by filter'' (the meaning of this depends on the OS on
|
|
which you're running
|
|
<I>tcpdump</I>,
|
|
|
|
and possibly on the way the OS was configured - if a filter was
|
|
specified on the command line, on some OSes it counts packets regardless
|
|
of whether they were matched by the filter expression and, even if they
|
|
were matched by the filter expression, regardless of whether
|
|
<I>tcpdump</I>
|
|
|
|
has read and processed them yet, on other OSes it counts only packets that were
|
|
matched by the filter expression regardless of whether
|
|
<I>tcpdump</I>
|
|
|
|
has read and processed them yet, and on other OSes it counts only
|
|
packets that were matched by the filter expression and were processed by
|
|
<I>tcpdump</I>);
|
|
|
|
<DT id="3"><DD>
|
|
packets ``dropped by kernel'' (this is the number of packets that were
|
|
dropped, due to a lack of buffer space, by the packet capture mechanism
|
|
in the OS on which
|
|
<I>tcpdump</I>
|
|
|
|
is running, if the OS reports that information to applications; if not,
|
|
it will be reported as 0).
|
|
</DL>
|
|
<P>
|
|
|
|
On platforms that support the SIGINFO signal, such as most BSDs
|
|
(including Mac OS X) and Digital/Tru64 UNIX, it will report those counts
|
|
when it receives a SIGINFO signal (generated, for example, by typing
|
|
your ``status'' character, typically control-T, although on some
|
|
platforms, such as Mac OS X, the ``status'' character is not set by
|
|
default, so you must set it with
|
|
<B><A HREF="/cgi-bin/man/man2html?1+stty">stty</A></B>(1)
|
|
|
|
in order to use it) and will continue capturing packets. On platforms that
|
|
do not support the SIGINFO signal, the same can be achieved by using the
|
|
SIGUSR1 signal.
|
|
<P>
|
|
|
|
Reading packets from a network interface may require that you have
|
|
special privileges; see the
|
|
<B>pcap (3PCAP)</B>
|
|
|
|
man page for details. Reading a saved packet file doesn't require
|
|
special privileges.
|
|
<A NAME="lbAE"> </A>
|
|
<H2>OPTIONS</H2>
|
|
|
|
<DL COMPACT>
|
|
<DT id="4"><B>-A</B>
|
|
|
|
<DD>
|
|
Print each packet (minus its link level header) in ASCII. Handy for
|
|
capturing web pages.
|
|
<DT id="5"><B>-b</B>
|
|
|
|
<DD>
|
|
Print the AS number in BGP packets in ASDOT notation rather than ASPLAIN
|
|
notation.
|
|
<DT id="6"><B>-B</B><I> buffer_size</I>
|
|
|
|
<DD>
|
|
|
|
<DT id="7"><B>--buffer-size=</B><I>buffer_size</I>
|
|
|
|
<DD>
|
|
|
|
Set the operating system capture buffer size to <I>buffer_size</I>, in
|
|
units of KiB (1024 bytes).
|
|
<DT id="8"><B>-c</B><I> count</I>
|
|
|
|
<DD>
|
|
Exit after receiving <I>count</I> packets.
|
|
<DT id="9"><B>-C</B><I> file_size</I>
|
|
|
|
<DD>
|
|
Before writing a raw packet to a savefile, check whether the file is
|
|
currently larger than <I>file_size</I> and, if so, close the current
|
|
savefile and open a new one. Savefiles after the first savefile will
|
|
have the name specified with the
|
|
<B>-w</B>
|
|
|
|
flag, with a number after it, starting at 1 and continuing upward.
|
|
The units of <I>file_size</I> are millions of bytes (1,000,000 bytes,
|
|
not 1,048,576 bytes).
|
|
<P>
|
|
Note that when used with <B>-Z</B> option (enabled by default), privileges
|
|
are dropped before opening first savefile.
|
|
<DT id="10"><B>-d</B>
|
|
|
|
<DD>
|
|
Dump the compiled packet-matching code in a human readable form to
|
|
standard output and stop.
|
|
<DT id="11"><B>-dd</B>
|
|
|
|
<DD>
|
|
Dump packet-matching code as a
|
|
<B>C</B>
|
|
|
|
program fragment.
|
|
<DT id="12"><B>-ddd</B>
|
|
|
|
<DD>
|
|
Dump packet-matching code as decimal numbers (preceded with a count).
|
|
<DT id="13"><B>-D</B>
|
|
|
|
<DD>
|
|
|
|
<DT id="14"><B>--list-interfaces</B>
|
|
|
|
<DD>
|
|
|
|
Print the list of the network interfaces available on the system and on
|
|
which
|
|
<I>tcpdump</I>
|
|
|
|
can capture packets. 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
|
|
<B>-i</B>
|
|
|
|
flag to specify an interface on which to capture.
|
|
<DT id="15"><DD>
|
|
This can be useful on systems that don't have a command to list them
|
|
(e.g., Windows systems, or UNIX systems lacking
|
|
<B>ifconfig -a</B>);
|
|
|
|
the number can be useful on Windows 2000 and later systems, where the
|
|
interface name is a somewhat complex string.
|
|
<DT id="16"><DD>
|
|
The
|
|
<B>-D</B>
|
|
|
|
flag will not be supported if
|
|
<I>tcpdump</I>
|
|
|
|
was built with an older version of
|
|
<I>libpcap</I>
|
|
|
|
that lacks the
|
|
<B>pcap_findalldevs()</B>
|
|
|
|
function.
|
|
<DT id="17"><B>-e</B>
|
|
|
|
<DD>
|
|
Print the link-level header on each dump line. This can be used, for
|
|
example, to print MAC layer addresses for protocols such as Ethernet and
|
|
IEEE 802.11.
|
|
<DT id="18"><B>-E</B>
|
|
|
|
<DD>
|
|
Use <I><A HREF="mailto:spi@ipaddr">spi@ipaddr</A> algo:secret</I> for decrypting IPsec ESP packets that
|
|
are addressed to <I>addr</I> and contain Security Parameter Index value
|
|
<I>spi</I>. This combination may be repeated with comma or newline separation.
|
|
<DT id="19"><DD>
|
|
Note that setting the secret for IPv4 ESP packets is supported at this time.
|
|
<DT id="20"><DD>
|
|
Algorithms may be
|
|
<B>des-cbc</B>,
|
|
<B>3des-cbc</B>,
|
|
<B>blowfish-cbc</B>,
|
|
<B>rc3-cbc</B>,
|
|
<B>cast128-cbc</B>, or
|
|
<B>none</B>.
|
|
The default is <B>des-cbc</B>.
|
|
The ability to decrypt packets is only present if <I>tcpdump</I> was compiled
|
|
with cryptography enabled.
|
|
<DT id="21"><DD>
|
|
<I>secret</I> is the ASCII text for ESP secret key.
|
|
If preceded by 0x, then a hex value will be read.
|
|
<DT id="22"><DD>
|
|
The option assumes RFC2406 ESP, not RFC1827 ESP.
|
|
The option is only for debugging purposes, and
|
|
the use of this option with a true `secret' key is discouraged.
|
|
By presenting IPsec secret key onto command line
|
|
you make it visible to others, via
|
|
<I><A HREF="/cgi-bin/man/man2html?1+ps">ps</A></I>(1)
|
|
|
|
and other occasions.
|
|
<DT id="23"><DD>
|
|
In addition to the above syntax, the syntax <I>file name</I> may be used
|
|
to have tcpdump read the provided file in. The file is opened upon
|
|
receiving the first ESP packet, so any special permissions that tcpdump
|
|
may have been given should already have been given up.
|
|
<DT id="24"><B>-f</B>
|
|
|
|
<DD>
|
|
Print `foreign' IPv4 addresses numerically rather than symbolically
|
|
(this option is intended to get around serious brain damage in
|
|
Sun's NIS server --- usually it hangs forever translating non-local
|
|
internet numbers).
|
|
<DT id="25"><DD>
|
|
The test for `foreign' IPv4 addresses is done using the IPv4 address and
|
|
netmask of the interface on which capture is being done. If that
|
|
address or netmask are not available, available, either because the
|
|
interface on which capture is being done has no address or netmask or
|
|
because the capture is being done on the Linux "any" interface, which
|
|
can capture on more than one interface, this option will not work
|
|
correctly.
|
|
<DT id="26"><B>-F</B><I> file</I>
|
|
|
|
<DD>
|
|
Use <I>file</I> as input for the filter expression.
|
|
An additional expression given on the command line is ignored.
|
|
<DT id="27"><B>-G</B><I> rotate_seconds</I>
|
|
|
|
<DD>
|
|
If specified, rotates the dump file specified with the
|
|
<B>-w</B>
|
|
|
|
option every <I>rotate_seconds</I> seconds.
|
|
Savefiles will have the name specified by
|
|
<B>-w</B>
|
|
|
|
which should include a time format as defined by
|
|
<B><A HREF="/cgi-bin/man/man2html?3+strftime">strftime</A></B>(3).
|
|
|
|
If no time format is specified, each new file will overwrite the previous.
|
|
<DT id="28"><DD>
|
|
If used in conjunction with the
|
|
<B>-C</B>
|
|
|
|
option, filenames will take the form of `<I>file</I><count>'.
|
|
<DT id="29"><B>-h</B>
|
|
|
|
<DD>
|
|
|
|
<DT id="30"><B>--help</B>
|
|
|
|
<DD>
|
|
|
|
Print the tcpdump and libpcap version strings, print a usage message,
|
|
and exit.
|
|
<DT id="31"><B>--version</B>
|
|
|
|
<DD>
|
|
|
|
Print the tcpdump and libpcap version strings and exit.
|
|
<DT id="32"><B>-H</B>
|
|
|
|
<DD>
|
|
Attempt to detect 802.11s draft mesh headers.
|
|
<DT id="33"><B>-i</B><I> interface</I>
|
|
|
|
<DD>
|
|
|
|
<DT id="34"><B>--interface=</B><I>interface</I>
|
|
|
|
<DD>
|
|
|
|
Listen on <I>interface</I>.
|
|
If unspecified, <I>tcpdump</I> searches the system interface list for the
|
|
lowest numbered, configured up interface (excluding loopback), which may turn
|
|
out to be, for example, ``eth0''.
|
|
<DT id="35"><DD>
|
|
On Linux systems with 2.2 or later kernels, an
|
|
<I>interface</I>
|
|
|
|
argument of ``any'' can be used to capture packets from all interfaces.
|
|
Note that captures on the ``any'' device will not be done in promiscuous
|
|
mode.
|
|
<DT id="36"><DD>
|
|
If the
|
|
<B>-D</B>
|
|
|
|
flag is supported, an interface number as printed by that flag can be
|
|
used as the
|
|
<I>interface</I>
|
|
|
|
argument, if no interface on the system has that number as a name.
|
|
<DT id="37"><B>-I</B>
|
|
|
|
<DD>
|
|
|
|
<DT id="38"><B>--monitor-mode</B>
|
|
|
|
<DD>
|
|
|
|
Put the interface in "monitor mode"; this is supported only on IEEE
|
|
802.11 Wi-Fi interfaces, and supported only on some operating systems.
|
|
<DT id="39"><DD>
|
|
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.
|
|
<DT id="40"><DD>
|
|
This flag will affect the output of the
|
|
<B>-L</B>
|
|
|
|
flag. If
|
|
<B>-I</B>
|
|
|
|
isn't specified, only those link-layer types available when not in
|
|
monitor mode will be shown; if
|
|
<B>-I</B>
|
|
|
|
is specified, only those link-layer types available when in monitor mode
|
|
will be shown.
|
|
<DT id="41"><B>--immediate-mode</B>
|
|
|
|
<DD>
|
|
Capture in "immediate mode". In this mode, packets are delivered to
|
|
tcpdump as soon as they arrive, rather than being buffered for
|
|
efficiency. This is the default when printing packets rather than
|
|
saving packets to a ``savefile'' if the packets are being printed to a
|
|
terminal rather than to a file or pipe.
|
|
<DT id="42"><B>-j</B><I> tstamp_type</I>
|
|
|
|
<DD>
|
|
|
|
<DT id="43"><B>--time-stamp-type=</B><I>tstamp_type</I>
|
|
|
|
<DD>
|
|
|
|
Set the time stamp type for the capture to <I>tstamp_type</I>. The names
|
|
to use for the time stamp types are given in
|
|
<B><A HREF="/cgi-bin/man/man2html?7+pcap-tstamp">pcap-tstamp</A></B>(7);
|
|
|
|
not all the types listed there will necessarily be valid for any given
|
|
interface.
|
|
<DT id="44"><B>-J</B>
|
|
|
|
<DD>
|
|
|
|
<DT id="45"><B>--list-time-stamp-types</B>
|
|
|
|
<DD>
|
|
|
|
List the supported time stamp types for the interface and exit. If the
|
|
time stamp type cannot be set for the interface, no time stamp types are
|
|
listed.
|
|
<DT id="46"><B>--time-stamp-precision=</B><I>tstamp_precision</I>
|
|
|
|
<DD>
|
|
When capturing, set the time stamp precision for the capture to
|
|
<I>tstamp_precision</I>. Note that availability of high precision time
|
|
stamps (nanoseconds) and their actual accuracy is platform and hardware
|
|
dependent. Also note that when writing captures made with nanosecond
|
|
accuracy to a savefile, the time stamps are written with nanosecond
|
|
resolution, and the file is written with a different magic number, to
|
|
indicate that the time stamps are in seconds and nanoseconds; not all
|
|
programs that read pcap savefiles will be able to read those captures.
|
|
</DL>
|
|
<P>
|
|
|
|
When reading a savefile, convert time stamps to the precision specified
|
|
by <I>timestamp_precision</I>, and display them with that resolution. If
|
|
the precision specified is less than the precision of time stamps in the
|
|
file, the conversion will lose precision.
|
|
<P>
|
|
|
|
The supported values for <I>timestamp_precision</I> are <B>micro</B> for
|
|
microsecond resolution and <B>nano</B> for nanosecond resolution. The
|
|
default is microsecond resolution.
|
|
<DL COMPACT>
|
|
<DT id="47"><B>-K</B>
|
|
|
|
<DD>
|
|
|
|
<DT id="48"><B>--dont-verify-checksums</B>
|
|
|
|
<DD>
|
|
|
|
Don't attempt to verify IP, TCP, or UDP checksums. This is useful for
|
|
interfaces that perform some or all of those checksum calculation in
|
|
hardware; otherwise, all outgoing TCP checksums will be flagged as bad.
|
|
<DT id="49"><B>-l</B>
|
|
|
|
<DD>
|
|
Make stdout line buffered.
|
|
Useful if you want to see the data
|
|
while capturing it.
|
|
E.g.,
|
|
<DT id="50"><DD>
|
|
<DL COMPACT><DT id="51"><DD>
|
|
<DL COMPACT><DT id="52"><DD>
|
|
<PRE>
|
|
<B>tcpdump -l | tee dat</B>
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
</DL>
|
|
|
|
<DT id="53"><DD>
|
|
or
|
|
<DT id="54"><DD>
|
|
<DL COMPACT><DT id="55"><DD>
|
|
<DL COMPACT><DT id="56"><DD>
|
|
<PRE>
|
|
<B>tcpdump -l > dat & tail -f dat</B>
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
</DL>
|
|
|
|
<DT id="57"><DD>
|
|
Note that on Windows,``line buffered'' means ``unbuffered'', so that
|
|
WinDump will write each character individually if
|
|
<B>-l</B>
|
|
|
|
is specified.
|
|
<DT id="58"><DD>
|
|
<B>-U</B>
|
|
|
|
is similar to
|
|
<B>-l</B>
|
|
|
|
in its behavior, but it will cause output to be ``packet-buffered'', so
|
|
that the output is written to stdout at the end of each packet rather
|
|
than at the end of each line; this is buffered on all platforms,
|
|
including Windows.
|
|
<DT id="59"><B>-L</B>
|
|
|
|
<DD>
|
|
|
|
<DT id="60"><B>--list-data-link-types</B>
|
|
|
|
<DD>
|
|
|
|
List the known data link types for the interface, in the specified mode,
|
|
and exit. The list of known data link types may be dependent on the
|
|
specified mode; for example, on some platforms, a Wi-Fi interface might
|
|
support one set of data link types when not in monitor mode (for
|
|
example, it might support only fake Ethernet headers, or might support
|
|
802.11 headers but not support 802.11 headers with radio information)
|
|
and another set of data link types when in monitor mode (for example, it
|
|
might support 802.11 headers, or 802.11 headers with radio information,
|
|
only in monitor mode).
|
|
<DT id="61"><B>-m</B><I> module</I>
|
|
|
|
<DD>
|
|
Load SMI MIB module definitions from file <I>module</I>.
|
|
This option
|
|
can be used several times to load several MIB modules into <I>tcpdump</I>.
|
|
<DT id="62"><B>-M</B><I> secret</I>
|
|
|
|
<DD>
|
|
Use <I>secret</I> as a shared secret for validating the digests found in
|
|
TCP segments with the TCP-MD5 option (RFC 2385), if present.
|
|
<DT id="63"><B>-n</B>
|
|
|
|
<DD>
|
|
Don't convert addresses (i.e., host addresses, port numbers, etc.) to names.
|
|
<DT id="64"><B>-N</B>
|
|
|
|
<DD>
|
|
Don't print domain name qualification of host names.
|
|
E.g.,
|
|
if you give this flag then <I>tcpdump</I> will print ``nic''
|
|
instead of ``nic.ddn.mil''.
|
|
<DT id="65"><B>-#</B>
|
|
|
|
<DD>
|
|
|
|
<DT id="66"><B>--number</B>
|
|
|
|
<DD>
|
|
|
|
Print an optional packet number at the beginning of the line.
|
|
<DT id="67"><B>-O</B>
|
|
|
|
<DD>
|
|
|
|
<DT id="68"><B>--no-optimize</B>
|
|
|
|
<DD>
|
|
|
|
Do not run the packet-matching code optimizer.
|
|
This is useful only
|
|
if you suspect a bug in the optimizer.
|
|
<DT id="69"><B>-p</B>
|
|
|
|
<DD>
|
|
|
|
<DT id="70"><B>--no-promiscuous-mode</B>
|
|
|
|
<DD>
|
|
|
|
<I>Don't</I> put the interface
|
|
into promiscuous mode.
|
|
Note that the interface might be in promiscuous
|
|
mode for some other reason; hence, `-p' cannot be used as an abbreviation for
|
|
`ether host {local-hw-addr} or ether broadcast'.
|
|
<DT id="71"><B>-Q</B><I> direction</I>
|
|
|
|
<DD>
|
|
|
|
<DT id="72"><B>--direction=</B><I>direction</I>
|
|
|
|
<DD>
|
|
|
|
Choose send/receive direction <I>direction</I> for which packets should be
|
|
captured. Possible values are `in', `out' and `inout'. Not available
|
|
on all platforms.
|
|
<DT id="73"><B>-q</B>
|
|
|
|
<DD>
|
|
Quick (quiet?) output.
|
|
Print less protocol information so output
|
|
lines are shorter.
|
|
<DT id="74"><B>-r</B><I> file</I>
|
|
|
|
<DD>
|
|
Read packets from <I>file</I> (which was created with the
|
|
<B>-w</B>
|
|
|
|
option or by other tools that write pcap or pcap-ng files).
|
|
Standard input is used if <I>file</I> is ``-''.
|
|
<DT id="75"><B>-S</B>
|
|
|
|
<DD>
|
|
|
|
<DT id="76"><B>--absolute-tcp-sequence-numbers</B>
|
|
|
|
<DD>
|
|
|
|
Print absolute, rather than relative, TCP sequence numbers.
|
|
<DT id="77"><B>-s</B><I> snaplen</I>
|
|
|
|
<DD>
|
|
|
|
<DT id="78"><B>--snapshot-length=</B><I>snaplen</I>
|
|
|
|
<DD>
|
|
|
|
Snarf <I>snaplen</I> bytes of data from each packet rather than the
|
|
default of 262144 bytes.
|
|
Packets truncated because of a limited snapshot
|
|
are indicated in the output with ``[|<I>proto</I>]'', where <I>proto</I>
|
|
is the name of the protocol level at which the truncation has occurred.
|
|
Note that taking larger snapshots both increases
|
|
the amount of time it takes to process packets and, effectively,
|
|
decreases the amount of packet buffering.
|
|
This may cause packets to be
|
|
lost.
|
|
You should limit <I>snaplen</I> to the smallest number that will
|
|
capture the protocol information you're interested in.
|
|
Setting
|
|
<I>snaplen</I> to 0 sets it to the default of 262144,
|
|
for backwards compatibility with recent older versions of
|
|
<I>tcpdump</I>.
|
|
|
|
<DT id="79"><B>-T</B><I> type</I>
|
|
|
|
<DD>
|
|
Force packets selected by "<I>expression</I>" to be interpreted the
|
|
specified <I>type</I>.
|
|
Currently known types are
|
|
<B>aodv</B> (Ad-hoc On-demand Distance Vector protocol),
|
|
<B>carp</B> (Common Address Redundancy Protocol),
|
|
<B>cnfp</B> (Cisco NetFlow protocol),
|
|
<B>lmp</B> (Link Management Protocol),
|
|
<B>pgm</B> (Pragmatic General Multicast),
|
|
<B>pgm_zmtp1</B> (ZMTP/1.0 inside PGM/EPGM),
|
|
<B>resp</B> (REdis Serialization Protocol),
|
|
<B>radius</B> (RADIUS),
|
|
<B>rpc</B> (Remote Procedure Call),
|
|
<B>rtp</B> (Real-Time Applications protocol),
|
|
<B>rtcp</B> (Real-Time Applications control protocol),
|
|
<B>snmp</B> (Simple Network Management Protocol),
|
|
<B>tftp</B> (Trivial File Transfer Protocol),
|
|
<B>vat</B> (Visual Audio Tool),
|
|
<B>wb</B> (distributed White Board),
|
|
<B>zmtp1</B> (ZeroMQ Message Transport Protocol 1.0)
|
|
and
|
|
<B>vxlan</B> (Virtual eXtensible Local Area Network).
|
|
<DT id="80"><DD>
|
|
Note that the <B>pgm</B> type above affects UDP interpretation only, the native
|
|
PGM is always recognised as IP protocol 113 regardless. UDP-encapsulated PGM is
|
|
often called "EPGM" or "PGM/UDP".
|
|
<DT id="81"><DD>
|
|
Note that the <B>pgm_zmtp1</B> type above affects interpretation of both native
|
|
PGM and UDP at once. During the native PGM decoding the application data of an
|
|
ODATA/RDATA packet would be decoded as a ZeroMQ datagram with ZMTP/1.0 frames.
|
|
During the UDP decoding in addition to that any UDP packet would be treated as
|
|
an encapsulated PGM packet.
|
|
<DT id="82"><B>-t</B>
|
|
|
|
<DD>
|
|
<I>Don't</I> print a timestamp on each dump line.
|
|
<DT id="83"><B>-tt</B>
|
|
|
|
<DD>
|
|
Print the timestamp, as seconds since January 1, 1970, 00:00:00, UTC, and
|
|
fractions of a second since that time, on each dump line.
|
|
<DT id="84"><B>-ttt</B>
|
|
|
|
<DD>
|
|
Print a delta (micro-second resolution) between current and previous line
|
|
on each dump line.
|
|
<DT id="85"><B>-tttt</B>
|
|
|
|
<DD>
|
|
Print a timestamp, as hours, minutes, seconds, and fractions of a second
|
|
since midnight, preceded by the date, on each dump line.
|
|
<DT id="86"><B>-ttttt</B>
|
|
|
|
<DD>
|
|
Print a delta (micro-second resolution) between current and first line
|
|
on each dump line.
|
|
<DT id="87"><B>-u</B>
|
|
|
|
<DD>
|
|
Print undecoded NFS handles.
|
|
<DT id="88"><B>-U</B>
|
|
|
|
<DD>
|
|
|
|
<DT id="89"><B>--packet-buffered</B>
|
|
|
|
<DD>
|
|
|
|
If the
|
|
<B>-w</B>
|
|
|
|
option is not specified, make the printed packet output
|
|
``packet-buffered''; i.e., as the description of the contents of each
|
|
packet is printed, it will be written to the standard output, rather
|
|
than, when not writing to a terminal, being written only when the output
|
|
buffer fills.
|
|
<DT id="90"><DD>
|
|
If the
|
|
<B>-w</B>
|
|
|
|
option is specified, make the saved raw packet output
|
|
``packet-buffered''; i.e., as each packet is saved, it will be written
|
|
to the output file, rather than being written only when the output
|
|
buffer fills.
|
|
<DT id="91"><DD>
|
|
The
|
|
<B>-U</B>
|
|
|
|
flag will not be supported if
|
|
<I>tcpdump</I>
|
|
|
|
was built with an older version of
|
|
<I>libpcap</I>
|
|
|
|
that lacks the
|
|
<B>pcap_dump_flush()</B>
|
|
|
|
function.
|
|
<DT id="92"><B>-v</B>
|
|
|
|
<DD>
|
|
When parsing and printing, produce (slightly more) verbose output.
|
|
For example, the time to live,
|
|
identification, total length and options in an IP packet are printed.
|
|
Also enables additional packet integrity checks such as verifying the
|
|
IP and ICMP header checksum.
|
|
<DT id="93"><DD>
|
|
When writing to a file with the
|
|
<B>-w</B>
|
|
|
|
option, report, every 10 seconds, the number of packets captured.
|
|
<DT id="94"><B>-vv</B>
|
|
|
|
<DD>
|
|
Even more verbose output.
|
|
For example, additional fields are
|
|
printed from NFS reply packets, and SMB packets are fully decoded.
|
|
<DT id="95"><B>-vvv</B>
|
|
|
|
<DD>
|
|
Even more verbose output.
|
|
For example,
|
|
telnet <B>SB</B> ... <B>SE</B> options
|
|
are printed in full.
|
|
With
|
|
<B>-X</B>
|
|
|
|
Telnet options are printed in hex as well.
|
|
<DT id="96"><B>-V</B><I> file</I>
|
|
|
|
<DD>
|
|
Read a list of filenames from <I>file</I>. Standard input is used
|
|
if <I>file</I> is ``-''.
|
|
<DT id="97"><B>-w</B><I> file</I>
|
|
|
|
<DD>
|
|
Write the raw packets to <I>file</I> rather than parsing and printing
|
|
them out.
|
|
They can later be printed with the -r option.
|
|
Standard output is used if <I>file</I> is ``-''.
|
|
<DT id="98"><DD>
|
|
This output will be buffered if written to a file or pipe, so a program
|
|
reading from the file or pipe may not see packets for an arbitrary
|
|
amount of time after they are received. Use the
|
|
<B>-U</B>
|
|
|
|
flag to cause packets to be written as soon as they are received.
|
|
<DT id="99"><DD>
|
|
The MIME type <I>application/vnd.tcpdump.pcap</I> has been registered
|
|
with IANA for <I>pcap</I> files. The filename extension <I>.pcap</I>
|
|
appears to be the most commonly used along with <I>.cap</I> and
|
|
<I>.dmp</I>. <I>Tcpdump</I> itself doesn't check the extension when
|
|
reading capture files and doesn't add an extension when writing them
|
|
(it uses magic numbers in the file header instead). However, many
|
|
operating systems and applications will use the extension if it is
|
|
present and adding one (e.g. .pcap) is recommended.
|
|
<DT id="100"><DD>
|
|
See
|
|
<B><A HREF="/cgi-bin/man/man2html?5+pcap-savefile">pcap-savefile</A></B>(5)
|
|
|
|
for a description of the file format.
|
|
<DT id="101"><B>-W</B>
|
|
|
|
<DD>
|
|
Used in conjunction with the
|
|
<B>-C</B>
|
|
|
|
option, this will limit the number
|
|
of files created to the specified number, and begin overwriting files
|
|
from the beginning, thus creating a 'rotating' buffer.
|
|
In addition, it will name
|
|
the files with enough leading 0s to support the maximum number of
|
|
files, allowing them to sort correctly.
|
|
<DT id="102"><DD>
|
|
Used in conjunction with the
|
|
<B>-G</B>
|
|
|
|
option, this will limit the number of rotated dump files that get
|
|
created, exiting with status 0 when reaching the limit. If used with
|
|
<B>-C</B>
|
|
|
|
as well, the behavior will result in cyclical files per timeslice.
|
|
<DT id="103"><B>-x</B>
|
|
|
|
<DD>
|
|
When parsing and printing,
|
|
in addition to printing the headers of each packet, print the data of
|
|
each packet (minus its link level header) in hex.
|
|
The smaller of the entire packet or
|
|
<I>snaplen</I>
|
|
|
|
bytes will be printed. Note that this is the entire link-layer
|
|
packet, so for link layers that pad (e.g. Ethernet), the padding bytes
|
|
will also be printed when the higher layer packet is shorter than the
|
|
required padding.
|
|
<DT id="104"><B>-xx</B>
|
|
|
|
<DD>
|
|
When parsing and printing,
|
|
in addition to printing the headers of each packet, print the data of
|
|
each packet,
|
|
<I>including</I>
|
|
|
|
its link level header, in hex.
|
|
<DT id="105"><B>-X</B>
|
|
|
|
<DD>
|
|
When parsing and printing,
|
|
in addition to printing the headers of each packet, print the data of
|
|
each packet (minus its link level header) in hex and ASCII.
|
|
This is very handy for analysing new protocols.
|
|
<DT id="106"><B>-XX</B>
|
|
|
|
<DD>
|
|
When parsing and printing,
|
|
in addition to printing the headers of each packet, print the data of
|
|
each packet,
|
|
<I>including</I>
|
|
|
|
its link level header, in hex and ASCII.
|
|
<DT id="107"><B>-y</B><I> datalinktype</I>
|
|
|
|
<DD>
|
|
|
|
<DT id="108"><B>--linktype=</B><I>datalinktype</I>
|
|
|
|
<DD>
|
|
|
|
Set the data link type to use while capturing packets to <I>datalinktype</I>.
|
|
<DT id="109"><B>-z</B><I> postrotate-command</I>
|
|
|
|
<DD>
|
|
Used in conjunction with the
|
|
<B>-C</B>
|
|
|
|
or
|
|
<B>-G</B>
|
|
|
|
options, this will make
|
|
<I>tcpdump</I>
|
|
|
|
run "
|
|
<I>postrotate-command file</I>
|
|
|
|
" where
|
|
<I>file</I>
|
|
|
|
is the savefile being closed after each rotation. For example, specifying
|
|
<B>-z gzip</B>
|
|
|
|
or
|
|
<B>-z bzip2</B>
|
|
|
|
will compress each savefile using gzip or bzip2.
|
|
<DT id="110"><DD>
|
|
Note that tcpdump will run the command in parallel to the capture, using
|
|
the lowest priority so that this doesn't disturb the capture process.
|
|
<DT id="111"><DD>
|
|
And in case you would like to use a command that itself takes flags or
|
|
different arguments, you can always write a shell script that will take the
|
|
savefile name as the only argument, make the flags & arguments arrangements
|
|
and execute the command that you want.
|
|
<DT id="112"><B>-Z</B><I> user</I>
|
|
|
|
<DD>
|
|
|
|
<DT id="113"><B>--relinquish-privileges=</B><I>user</I>
|
|
|
|
<DD>
|
|
|
|
If
|
|
<I>tcpdump</I>
|
|
|
|
is running as root, after opening the capture device or input savefile,
|
|
change the user ID to
|
|
<I>user</I>
|
|
|
|
and the group ID to the primary group of
|
|
<I>user</I>.
|
|
|
|
<DT id="114"><DD>
|
|
This behavior is enabled by default (<B>-Z tcpdump</B>), and can
|
|
be disabled by <B>-Z root</B>.
|
|
<P>
|
|
<DT id="115"><I> expression</I><DD>
|
|
<DL COMPACT><DT id="116"><DD>
|
|
selects which packets will be dumped.
|
|
If no <I>expression</I>
|
|
is given, all packets on the net will be dumped.
|
|
Otherwise,
|
|
only packets for which <I>expression</I> is `true' will be dumped.
|
|
<P>
|
|
|
|
For the <I>expression</I> syntax, see
|
|
<B><A HREF="/cgi-bin/man/man2html?7+pcap-filter">pcap-filter</A></B>(7).
|
|
|
|
<P>
|
|
|
|
The <I>expression</I> argument can be passed to <I>tcpdump</I> as either a single
|
|
Shell argument, or as multiple Shell arguments, whichever is more convenient.
|
|
Generally, if the expression contains Shell metacharacters, such as
|
|
backslashes used to escape protocol names, it is easier to pass it as
|
|
a single, quoted argument rather than to escape the Shell
|
|
metacharacters.
|
|
Multiple arguments are concatenated with spaces before being parsed.
|
|
</DL>
|
|
</DL>
|
|
<A NAME="lbAF"> </A>
|
|
<H2>EXAMPLES</H2>
|
|
|
|
<P>
|
|
|
|
To print all packets arriving at or departing from <I>sundown</I>:
|
|
<DL COMPACT><DT id="117"><DD>
|
|
<PRE>
|
|
<B>tcpdump host sundown</B>
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
To print traffic between <I>helios</I> and either <I>hot</I> or <I>ace</I>:
|
|
<DL COMPACT><DT id="118"><DD>
|
|
<PRE>
|
|
<B>tcpdump host helios and \( hot or ace \)</B>
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
To print all IP packets between <I>ace</I> and any host except <I>helios</I>:
|
|
<DL COMPACT><DT id="119"><DD>
|
|
<PRE>
|
|
<B>tcpdump ip host ace and not helios</B>
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
To print all traffic between local hosts and hosts at Berkeley:
|
|
<DL COMPACT><DT id="120"><DD>
|
|
<PRE>
|
|
<B>tcpdump net ucb-ether</B>
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
To print all ftp traffic through internet gateway <I>snup</I>:
|
|
(note that the expression is quoted to prevent the shell from
|
|
(mis-)interpreting the parentheses):
|
|
<DL COMPACT><DT id="121"><DD>
|
|
<PRE>
|
|
<B>tcpdump 'gateway snup and (port ftp or ftp-data)'</B>
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
To print traffic neither sourced from nor destined for local hosts
|
|
(if you gateway to one other net, this stuff should never make it
|
|
onto your local net).
|
|
<DL COMPACT><DT id="122"><DD>
|
|
<PRE>
|
|
<B>tcpdump ip and not net </B><I>localnet</I>
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
To print the start and end packets (the SYN and FIN packets) of each
|
|
TCP conversation that involves a non-local host.
|
|
<DL COMPACT><DT id="123"><DD>
|
|
<PRE>
|
|
<B>tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net </B><I>localnet</I>'
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
To print all IPv4 HTTP packets to and from port 80, i.e. print only
|
|
packets that contain data, not, for example, SYN and FIN packets and
|
|
ACK-only packets. (IPv6 is left as an exercise for the reader.)
|
|
<DL COMPACT><DT id="124"><DD>
|
|
<PRE>
|
|
<B>tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'</B>
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
To print IP packets longer than 576 bytes sent through gateway <I>snup</I>:
|
|
<DL COMPACT><DT id="125"><DD>
|
|
<PRE>
|
|
<B>tcpdump 'gateway snup and ip[2:2] > 576'</B>
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
To print IP broadcast or multicast packets that were
|
|
<I>not</I>
|
|
|
|
sent via Ethernet broadcast or multicast:
|
|
<DL COMPACT><DT id="126"><DD>
|
|
<PRE>
|
|
<B>tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'</B>
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
To print all ICMP packets that are not echo requests/replies (i.e., not
|
|
ping packets):
|
|
<DL COMPACT><DT id="127"><DD>
|
|
<PRE>
|
|
<B>tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'</B>
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<A NAME="lbAG"> </A>
|
|
<H2>OUTPUT FORMAT</H2>
|
|
|
|
<P>
|
|
|
|
The output of <I>tcpdump</I> is protocol dependent.
|
|
The following
|
|
gives a brief description and examples of most of the formats.
|
|
|
|
|
|
<P>
|
|
<B></B>
|
|
|
|
|
|
Timestamps
|
|
<P>
|
|
|
|
By default, all output lines are preceded by a timestamp.
|
|
The timestamp
|
|
is the current clock time in the form
|
|
<DL COMPACT><DT id="128"><DD>
|
|
<PRE>
|
|
<I>hh:mm:ss.frac</I>
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
and is as accurate as the kernel's clock.
|
|
The timestamp reflects the time the kernel applied a time stamp to the packet.
|
|
No attempt is made to account for the time lag between when the network
|
|
interface finished receiving the packet from the network and when the
|
|
kernel applied a time stamp to the packet; that time lag could include a
|
|
delay between the time when the network interface finished receiving a
|
|
packet from the network and the time when an interrupt was delivered to
|
|
the kernel to get it to read the packet and a delay between the time
|
|
when the kernel serviced the `new packet' interrupt and the time when it
|
|
applied a time stamp to the packet.
|
|
|
|
<P>
|
|
<B></B>
|
|
|
|
|
|
Link Level Headers
|
|
<P>
|
|
|
|
If the '-e' option is given, the link level header is printed out.
|
|
On Ethernets, the source and destination addresses, protocol,
|
|
and packet length are printed.
|
|
<P>
|
|
|
|
On FDDI networks, the '-e' option causes <I>tcpdump</I> to print
|
|
the `frame control' field, the source and destination addresses,
|
|
and the packet length.
|
|
(The `frame control' field governs the
|
|
interpretation of the rest of the packet.
|
|
Normal packets (such
|
|
as those containing IP datagrams) are `async' packets, with a priority
|
|
value between 0 and 7; for example, `<B>async4</B>'.
|
|
Such packets
|
|
are assumed to contain an 802.2 Logical Link Control (LLC) packet;
|
|
the LLC header is printed if it is <I>not</I> an ISO datagram or a
|
|
so-called SNAP packet.
|
|
<P>
|
|
|
|
On Token Ring networks, the '-e' option causes <I>tcpdump</I> to print
|
|
the `access control' and `frame control' fields, the source and
|
|
destination addresses, and the packet length.
|
|
As on FDDI networks,
|
|
packets are assumed to contain an LLC packet.
|
|
Regardless of whether
|
|
the '-e' option is specified or not, the source routing information is
|
|
printed for source-routed packets.
|
|
<P>
|
|
|
|
On 802.11 networks, the '-e' option causes <I>tcpdump</I> to print
|
|
the `frame control' fields, all of the addresses in the 802.11 header,
|
|
and the packet length.
|
|
As on FDDI networks,
|
|
packets are assumed to contain an LLC packet.
|
|
<P>
|
|
|
|
<I>(N.B.: The following description assumes familiarity with
|
|
the SLIP compression algorithm described in RFC-1144.)</I>
|
|
<P>
|
|
|
|
On SLIP links, a direction indicator (``I'' for inbound, ``O'' for outbound),
|
|
packet type, and compression information are printed out.
|
|
The packet type is printed first.
|
|
The three types are <I>ip</I>, <I>utcp</I>, and <I>ctcp</I>.
|
|
No further link information is printed for <I>ip</I> packets.
|
|
For TCP packets, the connection identifier is printed following the type.
|
|
If the packet is compressed, its encoded header is printed out.
|
|
The special cases are printed out as
|
|
<B>*S+</B><I>n</I> and <B>*SA+</B><I>n</I>, where <I>n</I> is the amount by which
|
|
the sequence number (or sequence number and ack) has changed.
|
|
If it is not a special case,
|
|
zero or more changes are printed.
|
|
A change is indicated by U (urgent pointer), W (window), A (ack),
|
|
S (sequence number), and I (packet ID), followed by a delta (+n or -n),
|
|
or a new value (=n).
|
|
Finally, the amount of data in the packet and compressed header length
|
|
are printed.
|
|
<P>
|
|
|
|
For example, the following line shows an outbound compressed TCP packet,
|
|
with an implicit connection identifier; the ack has changed by 6,
|
|
the sequence number by 49, and the packet ID by 6; there are 3 bytes of
|
|
data and 6 bytes of compressed header:
|
|
<DL COMPACT><DT id="129"><DD>
|
|
<PRE>
|
|
<B>O ctcp * A+6 S+49 I+6 3 (6)</B>
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
|
|
<P>
|
|
<B></B>
|
|
|
|
|
|
ARP/RARP Packets
|
|
<P>
|
|
|
|
Arp/rarp output shows the type of request and its arguments.
|
|
The
|
|
format is intended to be self explanatory.
|
|
Here is a short sample taken from the start of an `rlogin' from
|
|
host <I>rtsg</I> to host <I>csam</I>:
|
|
<DL COMPACT><DT id="130"><DD>
|
|
<PRE>
|
|
|
|
<TT>arp who-has csam tell rtsg
|
|
arp reply csam is-at CSAM</TT>
|
|
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
The first line says that rtsg sent an arp packet asking
|
|
for the Ethernet address of internet host csam.
|
|
Csam
|
|
replies with its Ethernet address (in this example, Ethernet addresses
|
|
are in caps and internet addresses in lower case).
|
|
<P>
|
|
|
|
This would look less redundant if we had done <I>tcpdump -n</I>:
|
|
<DL COMPACT><DT id="131"><DD>
|
|
<PRE>
|
|
|
|
<TT>arp who-has 128.3.254.6 tell 128.3.254.68
|
|
arp reply 128.3.254.6 is-at 02:07:01:00:01:c4</TT>
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
If we had done <I>tcpdump -e</I>, the fact that the first packet is
|
|
broadcast and the second is point-to-point would be visible:
|
|
<DL COMPACT><DT id="132"><DD>
|
|
<PRE>
|
|
|
|
<TT>RTSG Broadcast 0806 64: arp who-has csam tell rtsg
|
|
CSAM RTSG 0806 64: arp reply csam is-at CSAM</TT>
|
|
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
For the first packet this says the Ethernet source address is RTSG, the
|
|
destination is the Ethernet broadcast address, the type field
|
|
contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes.
|
|
|
|
<P>
|
|
<B></B>
|
|
|
|
|
|
IPv4 Packets
|
|
<P>
|
|
|
|
If the link-layer header is not being printed, for IPv4 packets,
|
|
<B>IP</B> is printed after the time stamp.
|
|
<P>
|
|
|
|
If the
|
|
<B>-v</B>
|
|
|
|
flag is specified, information from the IPv4 header is shown in
|
|
parentheses after the <B>IP</B> or the link-layer header.
|
|
The general format of this information is:
|
|
<DL COMPACT><DT id="133"><DD>
|
|
<PRE>
|
|
|
|
tos <I>tos</I>, ttl <I>ttl</I>, id <I>id</I>, offset <I>offset</I>, flags [<I>flags</I>], proto <I>proto</I>, length <I>length</I>, options (<I>options</I>)
|
|
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<I>tos</I> is the type of service field; if the ECN bits are non-zero,
|
|
those are reported as <B><A HREF="/cgi-bin/man/man2html?1+ECT">ECT</A>(1)</B>, <B>ECT(0)</B>, or <B>CE</B>.
|
|
<I>ttl</I> is the time-to-live; it is not reported if it is zero.
|
|
<I>id</I> is the IP identification field.
|
|
<I>offset</I> is the fragment offset field; it is printed whether this is
|
|
part of a fragmented datagram or not.
|
|
<I>flags</I> are the MF and DF flags; <B>+</B> is reported if MF is set,
|
|
and <B>DFP is reported if F is set. If neither are set, .</B> is
|
|
reported.
|
|
<I>proto</I> is the protocol ID field.
|
|
<I>length</I> is the total length field.
|
|
<I>options</I> are the IP options, if any.
|
|
<P>
|
|
|
|
Next, for TCP and UDP packets, the source and destination IP addresses
|
|
and TCP or UDP ports, with a dot between each IP address and its
|
|
corresponding port, will be printed, with a > separating the source and
|
|
destination. For other protocols, the addresses will be printed, with
|
|
a > separating the source and destination. Higher level protocol
|
|
information, if any, will be printed after that.
|
|
<P>
|
|
|
|
For fragmented IP datagrams, the first fragment contains the higher
|
|
level protocol header; fragments after the first contain no higher level
|
|
protocol header. Fragmentation information will be printed only with
|
|
the
|
|
<B>-v</B>
|
|
|
|
flag, in the IP header information, as described above.
|
|
|
|
<P>
|
|
<B></B>
|
|
|
|
|
|
TCP Packets
|
|
<P>
|
|
|
|
<I>(N.B.:The following description assumes familiarity with
|
|
the TCP protocol described in RFC-793.
|
|
If you are not familiar
|
|
with the protocol, this description will not
|
|
be of much use to you.)</I>
|
|
<P>
|
|
|
|
The general format of a TCP protocol line is:
|
|
<DL COMPACT><DT id="134"><DD>
|
|
<PRE>
|
|
|
|
<I>src</I> > <I>dst</I>: Flags [<I>tcpflags</I>], seq <I>data-seqno</I>, ack <I>ackno</I>, win <I>window</I>, urg <I>urgent</I>, options [<I>opts</I>], length <I>len</I>
|
|
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<I>Src</I> and <I>dst</I> are the source and destination IP
|
|
addresses and ports.
|
|
<I>Tcpflags</I> are some combination of S (SYN),
|
|
F (FIN), P (PUSH), R (RST), U (URG), W (ECN CWR), E (ECN-Echo) or
|
|
`.' (ACK), or `none' if no flags are set.
|
|
<I>Data-seqno</I> describes the portion of sequence space covered
|
|
by the data in this packet (see example below).
|
|
<I>Ackno</I> is sequence number of the next data expected the other
|
|
direction on this connection.
|
|
<I>Window</I> is the number of bytes of receive buffer space available
|
|
the other direction on this connection.
|
|
<I>Urg</I> indicates there is `urgent' data in the packet.
|
|
<I>Opts</I> are TCP options (e.g., mss 1024).
|
|
<I>Len</I> is the length of payload data.
|
|
<P>
|
|
|
|
<I>Iptype</I>, <I>Src</I>, <I>dst</I>, and <I>flags</I> are always present.
|
|
The other fields
|
|
depend on the contents of the packet's TCP protocol header and
|
|
are output only if appropriate.
|
|
<P>
|
|
|
|
Here is the opening portion of an rlogin from host <I>rtsg</I> to
|
|
host <I>csam</I>.
|
|
<DL COMPACT><DT id="135"><DD>
|
|
<PRE>
|
|
|
|
<FONT SIZE="-2"><TT>IP rtsg.1023 > csam.login: Flags [S], seq 768512:768512, win 4096, opts [mss 1024]
|
|
IP csam.login > rtsg.1023: Flags [S.], seq, 947648:947648, ack 768513, win 4096, opts [mss 1024]
|
|
IP rtsg.1023 > csam.login: Flags [.], ack 1, win 4096
|
|
IP rtsg.1023 > csam.login: Flags [P.], seq 1:2, ack 1, win 4096, length 1
|
|
IP csam.login > rtsg.1023: Flags [.], ack 2, win 4096
|
|
IP rtsg.1023 > csam.login: Flags [P.], seq 2:21, ack 1, win 4096, length 19
|
|
IP csam.login > rtsg.1023: Flags [P.], seq 1:2, ack 21, win 4077, length 1
|
|
IP csam.login > rtsg.1023: Flags [P.], seq 2:3, ack 21, win 4077, urg 1, length 1
|
|
IP csam.login > rtsg.1023: Flags [P.], seq 3:4, ack 21, win 4077, urg 1, length 1</TT></FONT>
|
|
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
The first line says that TCP port 1023 on rtsg sent a packet
|
|
to port <I>login</I>
|
|
on csam.
|
|
The <B>S</B> indicates that the <I>SYN</I> flag was set.
|
|
The packet sequence number was 768512 and it contained no data.
|
|
(The notation is `first:last' which means `sequence
|
|
numbers <I>first</I>
|
|
up to but not including <I>last</I>.)
|
|
There was no piggy-backed ack, the available receive window was 4096
|
|
bytes and there was a max-segment-size option requesting an mss of
|
|
1024 bytes.
|
|
<P>
|
|
|
|
Csam replies with a similar packet except it includes a piggy-backed
|
|
ack for rtsg's SYN.
|
|
Rtsg then acks csam's SYN.
|
|
The `.' means the ACK flag was set.
|
|
The packet contained no data so there is no data sequence number or length.
|
|
Note that the ack sequence
|
|
number is a small integer (1).
|
|
The first time <I>tcpdump</I> sees a
|
|
TCP `conversation', it prints the sequence number from the packet.
|
|
On subsequent packets of the conversation, the difference between
|
|
the current packet's sequence number and this initial sequence number
|
|
is printed.
|
|
This means that sequence numbers after the
|
|
first can be interpreted
|
|
as relative byte positions in the conversation's data stream (with the
|
|
first data byte each direction being `1').
|
|
`-S' will override this
|
|
feature, causing the original sequence numbers to be output.
|
|
<P>
|
|
|
|
On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20
|
|
in the rtsg → csam side of the conversation).
|
|
The PUSH flag is set in the packet.
|
|
On the 7th line, csam says it's received data sent by rtsg up to
|
|
but not including byte 21.
|
|
Most of this data is apparently sitting in the
|
|
socket buffer since csam's receive window has gotten 19 bytes smaller.
|
|
Csam also sends one byte of data to rtsg in this packet.
|
|
On the 8th and 9th lines,
|
|
csam sends two bytes of urgent, pushed data to rtsg.
|
|
<P>
|
|
|
|
If the snapshot was small enough that <I>tcpdump</I> didn't capture
|
|
the full TCP header, it interprets as much of the header as it can
|
|
and then reports ``[|<I>tcp</I>]'' to indicate the remainder could not
|
|
be interpreted.
|
|
If the header contains a bogus option (one with a length
|
|
that's either too small or beyond the end of the header), <I>tcpdump</I>
|
|
reports it as ``[<I>bad opt</I>]'' and does not interpret any further
|
|
options (since it's impossible to tell where they start).
|
|
If the header
|
|
length indicates options are present but the IP datagram length is not
|
|
long enough for the options to actually be there, <I>tcpdump</I> reports
|
|
it as ``[<I>bad hdr length</I>]''.
|
|
|
|
<P>
|
|
<B></B>
|
|
|
|
|
|
<B>Capturing TCP packets with particular flag combinations (SYN-ACK, URG-ACK, etc.)</B>
|
|
|
|
<P>
|
|
|
|
There are 8 bits in the control bits section of the TCP header:
|
|
<DL COMPACT>
|
|
<DT id="136"><DD>
|
|
<I>CWR | ECE | URG | ACK | PSH | RST | SYN | FIN</I>
|
|
|
|
</DL>
|
|
<P>
|
|
|
|
Let's assume that we want to watch packets used in establishing
|
|
a TCP connection.
|
|
Recall that TCP uses a 3-way handshake protocol
|
|
when it initializes a new connection; the connection sequence with
|
|
regard to the TCP control bits is
|
|
<P>
|
|
|
|
<DL COMPACT><DT id="137"><DD>
|
|
1) Caller sends SYN
|
|
</DL>
|
|
|
|
<DL COMPACT><DT id="138"><DD>
|
|
2) Recipient responds with SYN, ACK
|
|
</DL>
|
|
|
|
<DL COMPACT><DT id="139"><DD>
|
|
3) Caller sends ACK
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
Now we're interested in capturing packets that have only the
|
|
SYN bit set (Step 1).
|
|
Note that we don't want packets from step 2
|
|
(SYN-ACK), just a plain initial SYN.
|
|
What we need is a correct filter
|
|
expression for <I>tcpdump</I>.
|
|
<P>
|
|
|
|
Recall the structure of a TCP header without options:
|
|
<P>
|
|
|
|
<PRE>
|
|
0 15 31
|
|
-----------------------------------------------------------------
|
|
| source port | destination port |
|
|
-----------------------------------------------------------------
|
|
| sequence number |
|
|
-----------------------------------------------------------------
|
|
| acknowledgment number |
|
|
-----------------------------------------------------------------
|
|
| HL | rsvd |C|E|U|A|P|R|S|F| window size |
|
|
-----------------------------------------------------------------
|
|
| TCP checksum | urgent pointer |
|
|
-----------------------------------------------------------------
|
|
</PRE>
|
|
|
|
<P>
|
|
|
|
A TCP header usually holds 20 octets of data, unless options are
|
|
present.
|
|
The first line of the graph contains octets 0 - 3, the
|
|
second line shows octets 4 - 7 etc.
|
|
<P>
|
|
|
|
Starting to count with 0, the relevant TCP control bits are contained
|
|
in octet 13:
|
|
<P>
|
|
|
|
<PRE>
|
|
0 7| 15| 23| 31
|
|
----------------|---------------|---------------|----------------
|
|
| HL | rsvd |C|E|U|A|P|R|S|F| window size |
|
|
----------------|---------------|---------------|----------------
|
|
| | 13th octet | | |
|
|
</PRE>
|
|
|
|
<P>
|
|
|
|
Let's have a closer look at octet no. 13:
|
|
<P>
|
|
|
|
<PRE>
|
|
| |
|
|
|---------------|
|
|
|C|E|U|A|P|R|S|F|
|
|
|---------------|
|
|
|7 5 3 0|
|
|
</PRE>
|
|
|
|
<P>
|
|
|
|
These are the TCP control bits we are interested
|
|
in.
|
|
We have numbered the bits in this octet from 0 to 7, right to
|
|
left, so the PSH bit is bit number 3, while the URG bit is number 5.
|
|
<P>
|
|
|
|
Recall that we want to capture packets with only SYN set.
|
|
Let's see what happens to octet 13 if a TCP datagram arrives
|
|
with the SYN bit set in its header:
|
|
<P>
|
|
|
|
<PRE>
|
|
|C|E|U|A|P|R|S|F|
|
|
|---------------|
|
|
|0 0 0 0 0 0 1 0|
|
|
|---------------|
|
|
|7 6 5 4 3 2 1 0|
|
|
</PRE>
|
|
|
|
<P>
|
|
|
|
Looking at the
|
|
control bits section we see that only bit number 1 (SYN) is set.
|
|
<P>
|
|
|
|
Assuming that octet number 13 is an 8-bit unsigned integer in
|
|
network byte order, the binary value of this octet is
|
|
<DL COMPACT>
|
|
<DT id="140"><DD>
|
|
00000010
|
|
</DL>
|
|
<P>
|
|
|
|
and its decimal representation is
|
|
<P>
|
|
|
|
<PRE>
|
|
7 6 5 4 3 2 1 0
|
|
0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2 = 2
|
|
</PRE>
|
|
|
|
<P>
|
|
|
|
We're almost done, because now we know that if only SYN is set,
|
|
the value of the 13th octet in the TCP header, when interpreted
|
|
as a 8-bit unsigned integer in network byte order, must be exactly 2.
|
|
<P>
|
|
|
|
This relationship can be expressed as
|
|
<DL COMPACT><DT id="141"><DD>
|
|
<B>tcp[13] == 2</B>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
We can use this expression as the filter for <I>tcpdump</I> in order
|
|
to watch packets which have only SYN set:
|
|
<DL COMPACT><DT id="142"><DD>
|
|
<B>tcpdump -i xl0 tcp[13] == 2</B>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
The expression says "let the 13th octet of a TCP datagram have
|
|
the decimal value 2", which is exactly what we want.
|
|
<P>
|
|
|
|
Now, let's assume that we need to capture SYN packets, but we
|
|
don't care if ACK or any other TCP control bit is set at the
|
|
same time.
|
|
Let's see what happens to octet 13 when a TCP datagram
|
|
with SYN-ACK set arrives:
|
|
<P>
|
|
|
|
<PRE>
|
|
|C|E|U|A|P|R|S|F|
|
|
|---------------|
|
|
|0 0 0 1 0 0 1 0|
|
|
|---------------|
|
|
|7 6 5 4 3 2 1 0|
|
|
</PRE>
|
|
|
|
<P>
|
|
|
|
Now bits 1 and 4 are set in the 13th octet.
|
|
The binary value of
|
|
octet 13 is
|
|
<DL COMPACT>
|
|
<DT id="143"><DD>
|
|
<BR> 00010010
|
|
</DL>
|
|
<P>
|
|
|
|
which translates to decimal
|
|
<P>
|
|
|
|
<PRE>
|
|
7 6 5 4 3 2 1 0
|
|
0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2 = 18
|
|
</PRE>
|
|
|
|
<P>
|
|
|
|
Now we can't just use 'tcp[13] == 18' in the <I>tcpdump</I> filter
|
|
expression, because that would select only those packets that have
|
|
SYN-ACK set, but not those with only SYN set.
|
|
Remember that we don't care
|
|
if ACK or any other control bit is set as long as SYN is set.
|
|
<P>
|
|
|
|
In order to achieve our goal, we need to logically AND the
|
|
binary value of octet 13 with some other value to preserve
|
|
the SYN bit.
|
|
We know that we want SYN to be set in any case,
|
|
so we'll logically AND the value in the 13th octet with
|
|
the binary value of a SYN:
|
|
<P>
|
|
|
|
<PRE>
|
|
|
|
00010010 SYN-ACK 00000010 SYN
|
|
AND 00000010 (we want SYN) AND 00000010 (we want SYN)
|
|
-------- --------
|
|
= 00000010 = 00000010
|
|
</PRE>
|
|
|
|
<P>
|
|
|
|
We see that this AND operation delivers the same result
|
|
regardless whether ACK or another TCP control bit is set.
|
|
The decimal representation of the AND value as well as
|
|
the result of this operation is 2 (binary 00000010),
|
|
so we know that for packets with SYN set the following
|
|
relation must hold true:
|
|
<DL COMPACT>
|
|
<DT id="144"><DD>
|
|
( ( value of octet 13 ) AND ( 2 ) ) == ( 2 )
|
|
</DL>
|
|
<P>
|
|
|
|
This points us to the <I>tcpdump</I> filter expression
|
|
<DL COMPACT><DT id="145"><DD>
|
|
<B><BR> tcpdump -i xl0 'tcp[13] & 2 == 2'</B>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
Some offsets and field values may be expressed as names
|
|
rather than as numeric values. For example tcp[13] may
|
|
be replaced with tcp[tcpflags]. The following TCP flag
|
|
field values are also available: tcp-fin, tcp-syn, tcp-rst,
|
|
tcp-push, tcp-act, tcp-urg.
|
|
<P>
|
|
|
|
This can be demonstrated as:
|
|
<DL COMPACT><DT id="146"><DD>
|
|
<B><BR> tcpdump -i xl0 'tcp[tcpflags] & tcp-push != 0'</B>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
Note that you should use single quotes or a backslash
|
|
in the expression to hide the AND ('&') special character
|
|
from the shell.
|
|
|
|
<P>
|
|
<B></B>
|
|
|
|
|
|
<B>UDP Packets</B>
|
|
|
|
<P>
|
|
|
|
UDP format is illustrated by this rwho packet:
|
|
<DL COMPACT><DT id="147"><DD>
|
|
<PRE>
|
|
|
|
<TT>actinide.who > broadcast.who: udp 84</TT>
|
|
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
This says that port <I>who</I> on host <I>actinide</I> sent a udp
|
|
datagram to port <I>who</I> on host <I>broadcast</I>, the Internet
|
|
broadcast address.
|
|
The packet contained 84 bytes of user data.
|
|
<P>
|
|
|
|
Some UDP services are recognized (from the source or destination
|
|
port number) and the higher level protocol information printed.
|
|
In particular, Domain Name service requests (RFC-1034/1035) and Sun
|
|
RPC calls (RFC-1050) to NFS.
|
|
|
|
<P>
|
|
<B></B>
|
|
|
|
|
|
UDP Name Server Requests
|
|
<P>
|
|
|
|
<I>(N.B.:The following description assumes familiarity with
|
|
the Domain Service protocol described in RFC-1035.
|
|
If you are not familiar
|
|
with the protocol, the following description will appear to be written
|
|
in greek.)</I>
|
|
<P>
|
|
|
|
Name server requests are formatted as
|
|
<DL COMPACT><DT id="148"><DD>
|
|
<PRE>
|
|
|
|
<I>src > dst: id op? flags qtype qclass name (len)</I>
|
|
|
|
<TT>h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)</TT>
|
|
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
Host <I>h2opolo</I> asked the domain server on <I>helios</I> for an
|
|
address record (qtype=A) associated with the name <I>ucbvax.berkeley.edu.</I>
|
|
The query id was `3'.
|
|
The `+' indicates the <I>recursion desired</I> flag
|
|
was set.
|
|
The query length was 37 bytes, not including the UDP and
|
|
IP protocol headers.
|
|
The query operation was the normal one, <I>Query</I>,
|
|
so the op field was omitted.
|
|
If the op had been anything else, it would
|
|
have been printed between the `3' and the `+'.
|
|
Similarly, the qclass was the normal one,
|
|
<I>C_IN</I>, and omitted.
|
|
Any other qclass would have been printed
|
|
immediately after the `A'.
|
|
<P>
|
|
|
|
A few anomalies are checked and may result in extra fields enclosed in
|
|
square brackets: If a query contains an answer, authority records or
|
|
additional records section,
|
|
<I>ancount</I>,
|
|
|
|
<I>nscount</I>,
|
|
|
|
or
|
|
<I>arcount</I>
|
|
|
|
are printed as `[<I>n</I>a]', `[<I>n</I>n]' or `[<I>n</I>au]' where <I>n</I>
|
|
is the appropriate count.
|
|
If any of the response bits are set (AA, RA or rcode) or any of the
|
|
`must be zero' bits are set in bytes two and three, `[b2&3=<I>x</I>]'
|
|
is printed, where <I>x</I> is the hex value of header bytes two and three.
|
|
|
|
<P>
|
|
<B></B>
|
|
|
|
|
|
UDP Name Server Responses
|
|
<P>
|
|
|
|
Name server responses are formatted as
|
|
<DL COMPACT><DT id="149"><DD>
|
|
<PRE>
|
|
|
|
<I>src > dst: id op rcode flags a/n/au type class data (len)</I>
|
|
|
|
<TT>helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
|
|
helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)</TT>
|
|
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
In the first example, <I>helios</I> responds to query id 3 from <I>h2opolo</I>
|
|
with 3 answer records, 3 name server records and 7 additional records.
|
|
The first answer record is type A (address) and its data is internet
|
|
address 128.32.137.3.
|
|
The total size of the response was 273 bytes,
|
|
excluding UDP and IP headers.
|
|
The op (Query) and response code
|
|
(NoError) were omitted, as was the class (C_IN) of the A record.
|
|
<P>
|
|
|
|
In the second example, <I>helios</I> responds to query 2 with a
|
|
response code of non-existent domain (NXDomain) with no answers,
|
|
one name server and no authority records.
|
|
The `*' indicates that
|
|
the <I>authoritative answer</I> bit was set.
|
|
Since there were no
|
|
answers, no type, class or data were printed.
|
|
<P>
|
|
|
|
Other flag characters that might appear are `-' (recursion available,
|
|
RA, <I>not</I> set) and `|' (truncated message, TC, set).
|
|
If the
|
|
`question' section doesn't contain exactly one entry, `[<I>n</I>q]'
|
|
is printed.
|
|
|
|
<P>
|
|
<B></B>
|
|
|
|
|
|
SMB/CIFS decoding
|
|
<P>
|
|
|
|
<I>tcpdump</I> now includes fairly extensive SMB/CIFS/NBT decoding for data
|
|
on UDP/137, UDP/138 and TCP/139.
|
|
Some primitive decoding of IPX and
|
|
NetBEUI SMB data is also done.
|
|
<P>
|
|
|
|
By default a fairly minimal decode is done, with a much more detailed
|
|
decode done if -v is used.
|
|
Be warned that with -v a single SMB packet
|
|
may take up a page or more, so only use -v if you really want all the
|
|
gory details.
|
|
<P>
|
|
|
|
For information on SMB packet formats and what all the fields mean see
|
|
<A HREF="http://www.cifs.org">www.cifs.org</A> or the pub/samba/specs/ directory on your favorite
|
|
samba.org mirror site.
|
|
The SMB patches were written by Andrew Tridgell
|
|
(<A HREF="mailto:tridge@samba.org">tridge@samba.org</A>).
|
|
|
|
<P>
|
|
<B></B>
|
|
|
|
|
|
NFS Requests and Replies
|
|
<P>
|
|
|
|
Sun NFS (Network File System) requests and replies are printed as:
|
|
<DL COMPACT><DT id="150"><DD>
|
|
<PRE>
|
|
|
|
<I>src.sport > dst.nfs: NFS request xid xid len op args</I>
|
|
<I>src.nfs > dst.dport: NFS reply xid xid reply stat len op results</I>
|
|
|
|
<TT>
|
|
sushi.1023 > wrl.nfs: NFS request xid 26377
|
|
112 readlink fh 21,24/10.73165
|
|
wrl.nfs > sushi.1023: NFS reply xid 26377
|
|
reply ok 40 readlink "../var"
|
|
sushi.1022 > wrl.nfs: NFS request xid 8219
|
|
144 lookup fh 9,74/4096.6878 "xcolors"
|
|
wrl.nfs > sushi.1022: NFS reply xid 8219
|
|
reply ok 128 lookup fh 9,74/4134.3150
|
|
</TT>
|
|
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
In the first line, host <I>sushi</I> sends a transaction with id <I>26377</I>
|
|
to <I>wrl</I>.
|
|
The request was 112 bytes,
|
|
excluding the UDP and IP headers.
|
|
The operation was a <I>readlink</I>
|
|
(read symbolic link) on file handle (<I>fh</I>) 21,24/10.731657119.
|
|
(If one is lucky, as in this case, the file handle can be interpreted
|
|
as a major,minor device number pair, followed by the inode number and
|
|
generation number.) In the second line, <I>wrl</I> replies `ok' with
|
|
the same transaction id and the contents of the link.
|
|
<P>
|
|
|
|
In the third line, <I>sushi</I> asks (using a new transaction id) <I>wrl</I>
|
|
to lookup the name `<I>xcolors</I>' in directory file 9,74/4096.6878. In
|
|
the fourth line, <I>wrl</I> sends a reply with the respective transaction id.
|
|
<P>
|
|
|
|
Note that the data printed
|
|
depends on the operation type.
|
|
The format is intended to be self
|
|
explanatory if read in conjunction with
|
|
an NFS protocol spec.
|
|
Also note that older versions of tcpdump printed NFS packets in a
|
|
slightly different format: the transaction id (xid) would be printed
|
|
instead of the non-NFS port number of the packet.
|
|
<P>
|
|
|
|
If the -v (verbose) flag is given, additional information is printed.
|
|
For example:
|
|
<DL COMPACT><DT id="151"><DD>
|
|
<PRE>
|
|
|
|
<TT>
|
|
sushi.1023 > wrl.nfs: NFS request xid 79658
|
|
148 read fh 21,11/12.195 8192 bytes @ 24576
|
|
wrl.nfs > sushi.1023: NFS reply xid 79658
|
|
reply ok 1472 read REG 100664 ids 417/0 sz 29388
|
|
</TT>
|
|
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
(-v also prints the IP header TTL, ID, length, and fragmentation fields,
|
|
which have been omitted from this example.) In the first line,
|
|
<I>sushi</I> asks <I>wrl</I> to read 8192 bytes from file 21,11/12.195,
|
|
at byte offset 24576.
|
|
<I>Wrl</I> replies `ok'; the packet shown on the
|
|
second line is the first fragment of the reply, and hence is only 1472
|
|
bytes long (the other bytes will follow in subsequent fragments, but
|
|
these fragments do not have NFS or even UDP headers and so might not be
|
|
printed, depending on the filter expression used).
|
|
Because the -v flag
|
|
is given, some of the file attributes (which are returned in addition
|
|
to the file data) are printed: the file type (``REG'', for regular file),
|
|
the file mode (in octal), the uid and gid, and the file size.
|
|
<P>
|
|
|
|
If the -v flag is given more than once, even more details are printed.
|
|
<P>
|
|
|
|
Note that NFS requests are very large and much of the detail won't be printed
|
|
unless <I>snaplen</I> is increased.
|
|
Try using `<B>-s 192</B>' to watch
|
|
NFS traffic.
|
|
<P>
|
|
|
|
NFS reply packets do not explicitly identify the RPC operation.
|
|
Instead,
|
|
<I>tcpdump</I> keeps track of ``recent'' requests, and matches them to the
|
|
replies using the transaction ID.
|
|
If a reply does not closely follow the
|
|
corresponding request, it might not be parsable.
|
|
|
|
<P>
|
|
<B></B>
|
|
|
|
|
|
AFS Requests and Replies
|
|
<P>
|
|
|
|
Transarc AFS (Andrew File System) requests and replies are printed
|
|
as:
|
|
|
|
<P>
|
|
<B></B>
|
|
|
|
|
|
<DL COMPACT><DT id="152"><DD>
|
|
<PRE>
|
|
|
|
<I>src.sport > dst.dport: rx packet-type</I>
|
|
<I>src.sport > dst.dport: rx packet-type service call call-name args</I>
|
|
<I>src.sport > dst.dport: rx packet-type service reply call-name args</I>
|
|
|
|
<TT>
|
|
elvis.7001 > pike.afsfs:
|
|
rx data fs call rename old fid 536876964/1/1 ".newsrc.new"
|
|
new fid 536876964/1/1 ".newsrc"
|
|
pike.afsfs > elvis.7001: rx data fs reply rename
|
|
</TT>
|
|
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
In the first line, host elvis sends a RX packet to pike.
|
|
This was
|
|
a RX data packet to the fs (fileserver) service, and is the start of
|
|
an RPC call.
|
|
The RPC call was a rename, with the old directory file id
|
|
of 536876964/1/1 and an old filename of `.newsrc.new', and a new directory
|
|
file id of 536876964/1/1 and a new filename of `.newsrc'.
|
|
The host pike
|
|
responds with a RPC reply to the rename call (which was successful, because
|
|
it was a data packet and not an abort packet).
|
|
<P>
|
|
|
|
In general, all AFS RPCs are decoded at least by RPC call name.
|
|
Most
|
|
AFS RPCs have at least some of the arguments decoded (generally only
|
|
the `interesting' arguments, for some definition of interesting).
|
|
<P>
|
|
|
|
The format is intended to be self-describing, but it will probably
|
|
not be useful to people who are not familiar with the workings of
|
|
AFS and RX.
|
|
<P>
|
|
|
|
If the -v (verbose) flag is given twice, acknowledgement packets and
|
|
additional header information is printed, such as the RX call ID,
|
|
call number, sequence number, serial number, and the RX packet flags.
|
|
<P>
|
|
|
|
If the -v flag is given twice, additional information is printed,
|
|
such as the RX call ID, serial number, and the RX packet flags.
|
|
The MTU negotiation information is also printed from RX ack packets.
|
|
<P>
|
|
|
|
If the -v flag is given three times, the security index and service id
|
|
are printed.
|
|
<P>
|
|
|
|
Error codes are printed for abort packets, with the exception of Ubik
|
|
beacon packets (because abort packets are used to signify a yes vote
|
|
for the Ubik protocol).
|
|
<P>
|
|
|
|
Note that AFS requests are very large and many of the arguments won't
|
|
be printed unless <I>snaplen</I> is increased.
|
|
Try using `<B>-s 256</B>'
|
|
to watch AFS traffic.
|
|
<P>
|
|
|
|
AFS reply packets do not explicitly identify the RPC operation.
|
|
Instead,
|
|
<I>tcpdump</I> keeps track of ``recent'' requests, and matches them to the
|
|
replies using the call number and service ID.
|
|
If a reply does not closely
|
|
follow the
|
|
corresponding request, it might not be parsable.
|
|
<P>
|
|
|
|
<P>
|
|
<B></B>
|
|
|
|
|
|
KIP AppleTalk (DDP in UDP)
|
|
<P>
|
|
|
|
AppleTalk DDP packets encapsulated in UDP datagrams are de-encapsulated
|
|
and dumped as DDP packets (i.e., all the UDP header information is
|
|
discarded).
|
|
The file
|
|
<I>/etc/atalk.names</I>
|
|
|
|
is used to translate AppleTalk net and node numbers to names.
|
|
Lines in this file have the form
|
|
<DL COMPACT><DT id="153"><DD>
|
|
<PRE>
|
|
|
|
<I>number name</I>
|
|
|
|
<TT>1.254 ether
|
|
16.1 icsd-net
|
|
1.254.110 ace</TT>
|
|
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
The first two lines give the names of AppleTalk networks.
|
|
The third
|
|
line gives the name of a particular host (a host is distinguished
|
|
from a net by the 3rd octet in the number -
|
|
a net number <I>must</I> have two octets and a host number <I>must</I>
|
|
have three octets.) The number and name should be separated by
|
|
whitespace (blanks or tabs).
|
|
The
|
|
<I>/etc/atalk.names</I>
|
|
|
|
file may contain blank lines or comment lines (lines starting with
|
|
a `#').
|
|
<P>
|
|
|
|
AppleTalk addresses are printed in the form
|
|
<DL COMPACT><DT id="154"><DD>
|
|
<PRE>
|
|
|
|
<I>net.host.port</I>
|
|
|
|
<TT>144.1.209.2 > icsd-net.112.220
|
|
office.2 > icsd-net.112.220
|
|
jssmag.149.235 > icsd-net.2</TT>
|
|
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
(If the
|
|
<I>/etc/atalk.names</I>
|
|
|
|
doesn't exist or doesn't contain an entry for some AppleTalk
|
|
host/net number, addresses are printed in numeric form.)
|
|
In the first example, NBP (DDP port 2) on net 144.1 node 209
|
|
is sending to whatever is listening on port 220 of net icsd node 112.
|
|
The second line is the same except the full name of the source node
|
|
is known (`office').
|
|
The third line is a send from port 235 on
|
|
net jssmag node 149 to broadcast on the icsd-net NBP port (note that
|
|
the broadcast address (255) is indicated by a net name with no host
|
|
number - for this reason it's a good idea to keep node names and
|
|
net names distinct in /etc/atalk.names).
|
|
<P>
|
|
|
|
NBP (name binding protocol) and ATP (AppleTalk transaction protocol)
|
|
packets have their contents interpreted.
|
|
Other protocols just dump
|
|
the protocol name (or number if no name is registered for the
|
|
protocol) and packet size.
|
|
<P>
|
|
<B>NBP packets</B> are formatted like the following examples:
|
|
<DL COMPACT><DT id="155"><DD>
|
|
<PRE>
|
|
|
|
<FONT SIZE="-2"><TT>icsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
|
|
jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
|
|
techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186</TT></FONT>
|
|
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
The first line is a name lookup request for laserwriters sent by net icsd host
|
|
112 and broadcast on net jssmag.
|
|
The nbp id for the lookup is 190.
|
|
The second line shows a reply for this request (note that it has the
|
|
same id) from host jssmag.209 saying that it has a laserwriter
|
|
resource named "RM1140" registered on port 250.
|
|
The third line is
|
|
another reply to the same request saying host techpit has laserwriter
|
|
"techpit" registered on port 186.
|
|
<P>
|
|
<B>ATP packet</B> formatting is demonstrated by the following example:
|
|
<DL COMPACT><DT id="156"><DD>
|
|
<PRE>
|
|
|
|
<FONT SIZE="-2"><TT>jssmag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001
|
|
helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
|
|
helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
|
|
helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
|
|
helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
|
|
helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000
|
|
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
|
|
helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
|
|
helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
|
|
jssmag.209.165 > helios.132: atp-req 12266<3,5> 0xae030001
|
|
helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
|
|
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
|
|
jssmag.209.165 > helios.132: atp-rel 12266<0-7> 0xae030001
|
|
jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002</TT></FONT>
|
|
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
Jssmag.209 initiates transaction id 12266 with host helios by requesting
|
|
up to 8 packets (the `<0-7>').
|
|
The hex number at the end of the line
|
|
is the value of the `userdata' field in the request.
|
|
<P>
|
|
|
|
Helios responds with 8 512-byte packets.
|
|
The `:digit' following the
|
|
transaction id gives the packet sequence number in the transaction
|
|
and the number in parens is the amount of data in the packet,
|
|
excluding the atp header.
|
|
The `*' on packet 7 indicates that the
|
|
EOM bit was set.
|
|
<P>
|
|
|
|
Jssmag.209 then requests that packets 3 & 5 be retransmitted.
|
|
Helios
|
|
resends them then jssmag.209 releases the transaction.
|
|
Finally,
|
|
jssmag.209 initiates the next request.
|
|
The `*' on the request
|
|
indicates that XO (`exactly once') was <I>not</I> set.
|
|
<P>
|
|
<A NAME="lbAH"> </A>
|
|
<H2>SEE ALSO</H2>
|
|
|
|
<A HREF="/cgi-bin/man/man2html?1+stty">stty</A>(1), pcap(3PCAP), <A HREF="/cgi-bin/man/man2html?4+bpf">bpf</A>(4), <A HREF="/cgi-bin/man/man2html?4P+nit">nit</A>(4P), <A HREF="/cgi-bin/man/man2html?5+pcap-savefile">pcap-savefile</A>(5),
|
|
<A HREF="/cgi-bin/man/man2html?7+pcap-filter">pcap-filter</A>(7), <A HREF="/cgi-bin/man/man2html?7+pcap-tstamp">pcap-tstamp</A>(7)
|
|
<P>
|
|
|
|
<DL COMPACT><DT id="157"><DD>
|
|
<I><A HREF="http://www.iana.org/assignments/media-types/application/vnd.tcpdump.pcap">http://www.iana.org/assignments/media-types/application/vnd.tcpdump.pcap</A></I>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
<A NAME="lbAI"> </A>
|
|
<H2>AUTHORS</H2>
|
|
|
|
The original authors are:
|
|
<P>
|
|
|
|
Van Jacobson,
|
|
Craig Leres and
|
|
Steven McCanne, all of the
|
|
Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
|
|
<P>
|
|
|
|
It is currently being maintained by tcpdump.org.
|
|
<P>
|
|
|
|
The current version is available via http:
|
|
<P>
|
|
|
|
<DL COMPACT><DT id="158"><DD>
|
|
<I><A HREF="https://www.tcpdump.org/">https://www.tcpdump.org/</A></I>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
The original distribution is available via anonymous ftp:
|
|
<P>
|
|
|
|
<DL COMPACT><DT id="159"><DD>
|
|
<I><A HREF="ftp://ftp.ee.lbl.gov/old/tcpdump.tar.Z">ftp://ftp.ee.lbl.gov/old/tcpdump.tar.Z</A></I>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
IPv6/IPsec support is added by WIDE/KAME project.
|
|
This program uses Eric Young's SSLeay library, under specific configurations.
|
|
<A NAME="lbAJ"> </A>
|
|
<H2>BUGS</H2>
|
|
|
|
To report a security issue please send an e-mail to <A HREF="mailto:security@tcpdump.org">security@tcpdump.org</A>.
|
|
<P>
|
|
|
|
To report bugs and other problems, contribute patches, request a
|
|
feature, provide generic feedback etc please see the file
|
|
<I>CONTRIBUTING</I>
|
|
|
|
in the tcpdump source tree root.
|
|
<P>
|
|
|
|
NIT doesn't let you watch your own outbound traffic, BPF will.
|
|
We recommend that you use the latter.
|
|
<P>
|
|
|
|
On Linux systems with 2.0[.x] kernels:
|
|
<DL COMPACT>
|
|
<DT id="160"><DD>
|
|
packets on the loopback device will be seen twice;
|
|
<DT id="161"><DD>
|
|
packet filtering cannot be done in the kernel, so that all packets must
|
|
be copied from the kernel in order to be filtered in user mode;
|
|
<DT id="162"><DD>
|
|
all of a packet, not just the part that's within the snapshot length,
|
|
will be copied from the kernel (the 2.0[.x] packet capture mechanism, if
|
|
asked to copy only part of a packet to userland, will not report the
|
|
true length of the packet; this would cause most IP packets to get an
|
|
error from
|
|
<B>tcpdump</B>);
|
|
|
|
<DT id="163"><DD>
|
|
capturing on some PPP devices won't work correctly.
|
|
</DL>
|
|
<P>
|
|
|
|
We recommend that you upgrade to a 2.2 or later kernel.
|
|
<P>
|
|
|
|
Some attempt should be made to reassemble IP fragments or, at least
|
|
to compute the right length for the higher level protocol.
|
|
<P>
|
|
|
|
Name server inverse queries are not dumped correctly: the (empty)
|
|
question section is printed rather than real query in the answer
|
|
section.
|
|
Some believe that inverse queries are themselves a bug and
|
|
prefer to fix the program generating them rather than <I>tcpdump</I>.
|
|
<P>
|
|
|
|
A packet trace that crosses a daylight savings time change will give
|
|
skewed time stamps (the time change is ignored).
|
|
<P>
|
|
|
|
Filter expressions on fields other than those in Token Ring headers will
|
|
not correctly handle source-routed Token Ring packets.
|
|
<P>
|
|
|
|
Filter expressions on fields other than those in 802.11 headers will not
|
|
correctly handle 802.11 data packets with both To DS and From DS set.
|
|
<P>
|
|
|
|
<B>ip6 proto</B>
|
|
|
|
should chase header chain, but at this moment it does not.
|
|
<B>ip6 protochain</B>
|
|
|
|
is supplied for this behavior.
|
|
<P>
|
|
|
|
Arithmetic expression against transport layer headers, like <B>tcp[0]</B>,
|
|
does not work against IPv6 packets.
|
|
It only looks at IPv4 packets.
|
|
<P>
|
|
|
|
<HR>
|
|
<A NAME="index"> </A><H2>Index</H2>
|
|
<DL>
|
|
<DT id="164"><A HREF="#lbAB">NAME</A><DD>
|
|
<DT id="165"><A HREF="#lbAC">SYNOPSIS</A><DD>
|
|
<DT id="166"><A HREF="#lbAD">DESCRIPTION</A><DD>
|
|
<DT id="167"><A HREF="#lbAE">OPTIONS</A><DD>
|
|
<DT id="168"><A HREF="#lbAF">EXAMPLES</A><DD>
|
|
<DT id="169"><A HREF="#lbAG">OUTPUT FORMAT</A><DD>
|
|
<DT id="170"><A HREF="#lbAH">SEE ALSO</A><DD>
|
|
<DT id="171"><A HREF="#lbAI">AUTHORS</A><DD>
|
|
<DT id="172"><A HREF="#lbAJ">BUGS</A><DD>
|
|
</DL>
|
|
<HR>
|
|
This document was created by
|
|
<A HREF="/cgi-bin/man/man2html">man2html</A>,
|
|
using the manual pages.<BR>
|
|
Time: 00:06:17 GMT, March 31, 2021
|
|
</BODY>
|
|
</HTML>
|