1943 lines
61 KiB
Groff
1943 lines
61 KiB
Groff
.\" @(#) $Header: /tcpdump/master/tcpdump/tcpdump.1,v 1.114 2002/01/04 07:37:49 guy Exp $ (LBL)
|
|
.\"
|
|
.\" Copyright (c) 1987, 1988, 1989, 1990, 1991, 1992, 1994, 1995, 1996, 1997
|
|
.\" The Regents of the University of California. All rights reserved.
|
|
.\" All rights reserved.
|
|
.\"
|
|
.\" Redistribution and use in source and binary forms, with or without
|
|
.\" modification, are permitted provided that: (1) source code distributions
|
|
.\" retain the above copyright notice and this paragraph in its entirety, (2)
|
|
.\" distributions including binary code include the above copyright notice and
|
|
.\" this paragraph in its entirety in the documentation or other materials
|
|
.\" provided with the distribution, and (3) all advertising materials mentioning
|
|
.\" features or use of this software display the following acknowledgement:
|
|
.\" ``This product includes software developed by the University of California,
|
|
.\" Lawrence Berkeley Laboratory and its contributors.'' Neither the name of
|
|
.\" the University nor the names of its contributors may be used to endorse
|
|
.\" or promote products derived from this software without specific prior
|
|
.\" written permission.
|
|
.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
|
|
.\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
|
|
.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
|
|
.\"
|
|
.\" $FreeBSD$
|
|
.\"
|
|
.TH TCPDUMP 1 "3 January 2001"
|
|
.SH NAME
|
|
tcpdump \- dump traffic on a network
|
|
.SH SYNOPSIS
|
|
.na
|
|
.B tcpdump
|
|
[
|
|
.B \-adeflnNOpqRStuvxX
|
|
] [
|
|
.B \-c
|
|
.I count
|
|
]
|
|
.br
|
|
.ti +8
|
|
[
|
|
.B \-C
|
|
.I file_size
|
|
] [
|
|
.B \-F
|
|
.I file
|
|
]
|
|
.br
|
|
.ti +8
|
|
[
|
|
.B \-i
|
|
.I interface
|
|
]
|
|
[
|
|
.B \-m
|
|
.I module
|
|
]
|
|
[
|
|
.B \-r
|
|
.I file
|
|
]
|
|
.br
|
|
.ti +8
|
|
[
|
|
.B \-s
|
|
.I snaplen
|
|
]
|
|
[
|
|
.B \-T
|
|
.I type
|
|
]
|
|
[
|
|
.B \-w
|
|
.I file
|
|
]
|
|
.br
|
|
.ti +8
|
|
[
|
|
.B \-E
|
|
.I algo:secret
|
|
]
|
|
[
|
|
.I expression
|
|
]
|
|
.br
|
|
.ad
|
|
.SH DESCRIPTION
|
|
.LP
|
|
\fITcpdump\fP prints out the headers of packets on a network interface
|
|
that match the boolean \fIexpression\fP. It can also be run with the
|
|
.B \-w
|
|
flag, which causes it to save the packet data to a file for later
|
|
analysis, and/or with the
|
|
.B \-b
|
|
flag, which causes it to read from a saved packet file rather than to
|
|
read packets from a network interface. In all cases, only packets that
|
|
match
|
|
.I expression
|
|
will be processed by
|
|
.IR tcpdump .
|
|
.LP
|
|
.I Tcpdump
|
|
will, if not run with the
|
|
.B \-c
|
|
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
|
|
.BR kill (1)
|
|
command); if run with the
|
|
.B \-c
|
|
flag, it will capture packets until it is interrupted by a SIGINT or
|
|
SIGTERM signal or the specified number of packets have been processed.
|
|
.LP
|
|
When
|
|
.I tcpdump
|
|
finishes capturing packets, it will report counts of:
|
|
.IP
|
|
packets ``received by filter'' (the meaning of this depends on the OS on
|
|
which you're running
|
|
.IR tcpdump ,
|
|
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 on other OSes
|
|
it counts only packets that were matched by the filter expression and
|
|
were processed by
|
|
.IR tcpdump );
|
|
.IP
|
|
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
|
|
is running, if the OS reports that information to applications; if not,
|
|
it will be reported as 0).
|
|
.LP
|
|
On platforms that support the SIGINFO signal, such as most BSDs, it will
|
|
report those counts when it receives a SIGINFO signal (generated, for
|
|
example, by typing your ``status'' character, typically control-T) and
|
|
will continue capturing packets.
|
|
.LP
|
|
Reading packets from a network interface may require that you have
|
|
special privileges:
|
|
.TP
|
|
.B Under SunOS 3.x or 4.x with NIT or BPF:
|
|
You must have read access to
|
|
.I /dev/nit
|
|
or
|
|
.IR /dev/bpf* .
|
|
.TP
|
|
.B Under Solaris with DLPI:
|
|
You must have read/write access to the network pseudo device, e.g.
|
|
.IR /dev/le .
|
|
On at least some versions of Solaris, however, this is not sufficient to
|
|
allow
|
|
.I tcpdump
|
|
to capture in promiscuous mode; on those versions of Solaris, you must
|
|
be root, or
|
|
.I tcpdump
|
|
must be installed setuid to root, in order to capture in promiscuous
|
|
mode.
|
|
.TP
|
|
.B Under HP-UX with DLPI:
|
|
You must be root or
|
|
.I tcpdump
|
|
must be installed setuid to root.
|
|
.TP
|
|
.B Under IRIX with snoop:
|
|
You must be root or
|
|
.I tcpdump
|
|
must be installed setuid to root.
|
|
.TP
|
|
.B Under Linux:
|
|
You must be root or
|
|
.I tcpdump
|
|
must be installed setuid to root.
|
|
.TP
|
|
.B Under Ultrix and Digital UNIX:
|
|
Once the super-user has enabled promiscuous-mode operation using
|
|
.IR pfconfig (8),
|
|
any user may capture network traffic with
|
|
.IR tcpdump .
|
|
.TP
|
|
.B Under BSD:
|
|
You must have read access to
|
|
.IR /dev/bpf* .
|
|
.LP
|
|
Reading a saved packet file doesn't require special privileges.
|
|
.SH OPTIONS
|
|
.TP
|
|
.B \-a
|
|
Attempt to convert network and broadcast addresses to names.
|
|
.TP
|
|
.B \-c
|
|
Exit after receiving \fIcount\fP packets.
|
|
.TP
|
|
.B \-C
|
|
Before writing a raw packet to a savefile, check whether the file is
|
|
currently larger than \fIfile_size\fP 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
|
|
flag, with a number after it, starting at 2 and continuing upward.
|
|
The units of \fIfile_size\fP are millions of bytes (1,000,000 bytes,
|
|
not 1,048,576 bytes).
|
|
.TP
|
|
.B \-d
|
|
Dump the compiled packet-matching code in a human readable form to
|
|
standard output and stop.
|
|
.TP
|
|
.B \-dd
|
|
Dump packet-matching code as a
|
|
.B C
|
|
program fragment.
|
|
.TP
|
|
.B \-ddd
|
|
Dump packet-matching code as decimal numbers (preceded with a count).
|
|
.TP
|
|
.B \-e
|
|
Print the link-level header on each dump line.
|
|
.TP
|
|
.B \-E
|
|
Use \fIalgo:secret\fP for decrypting IPsec ESP packets.
|
|
Algorithms may be
|
|
\fBdes-cbc\fP,
|
|
\fB3des-cbc\fP,
|
|
\fBblowfish-cbc\fP,
|
|
\fBrc3-cbc\fP,
|
|
\fBcast128-cbc\fP, or
|
|
\fBnone\fP.
|
|
The default is \fBdes-cbc\fP.
|
|
The ability to decrypt packets is only present if \fItcpdump\fP was compiled
|
|
with cryptography enabled.
|
|
\fIsecret\fP the ascii text for ESP secret key.
|
|
We cannot take arbitrary binary value at this moment.
|
|
The option assumes RFC2406 ESP, not RFC1827 ESP.
|
|
The option is only for debugging purposes, and
|
|
the use of this option with truly `secret' key is discouraged.
|
|
By presenting IPsec secret key onto command line
|
|
you make it visible to others, via
|
|
.IR ps (1)
|
|
and other occasions.
|
|
.TP
|
|
.B \-f
|
|
Print `foreign' internet addresses numerically rather than symbolically
|
|
(this option is intended to get around serious brain damage in
|
|
Sun's yp server \(em usually it hangs forever translating non-local
|
|
internet numbers).
|
|
.TP
|
|
.B \-F
|
|
Use \fIfile\fP as input for the filter expression.
|
|
An additional expression given on the command line is ignored.
|
|
.TP
|
|
.B \-i
|
|
Listen on \fIinterface\fP.
|
|
If unspecified, \fItcpdump\fP searches the system interface list for the
|
|
lowest numbered, configured up interface (excluding loopback).
|
|
Ties are broken by choosing the earliest match.
|
|
.IP
|
|
On Linux systems with 2.2 or later kernels, an
|
|
.I interface
|
|
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.
|
|
.TP
|
|
.B \-l
|
|
Make stdout line buffered.
|
|
Useful if you want to see the data
|
|
while capturing it.
|
|
E.g.,
|
|
.br
|
|
``tcpdump\ \ \-l\ \ |\ \ tee dat'' or
|
|
``tcpdump\ \ \-l \ \ > dat\ \ &\ \ tail\ \ \-f\ \ dat''.
|
|
.TP
|
|
.B \-m
|
|
Load SMI MIB module definitions from file \fImodule\fR.
|
|
This option
|
|
can be used several times to load several MIB modules into \fItcpdump\fP.
|
|
.TP
|
|
.B \-n
|
|
Don't convert addresses (i.e., host addresses, port numbers, etc.) to names.
|
|
.TP
|
|
.B \-N
|
|
Don't print domain name qualification of host names.
|
|
E.g.,
|
|
if you give this flag then \fItcpdump\fP will print ``nic''
|
|
instead of ``nic.ddn.mil''.
|
|
.TP
|
|
.B \-O
|
|
Do not run the packet-matching code optimizer.
|
|
This is useful only
|
|
if you suspect a bug in the optimizer.
|
|
.TP
|
|
.B \-p
|
|
\fIDon't\fP 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'.
|
|
.TP
|
|
.B \-q
|
|
Quick (quiet?) output.
|
|
Print less protocol information so output
|
|
lines are shorter.
|
|
.TP
|
|
.B \-R
|
|
Assume ESP/AH packets to be based on old specification (RFC1825 to RFC1829).
|
|
If specified, \fItcpdump\fP will not print replay prevention field.
|
|
Since there is no protocol version field in ESP/AH specification,
|
|
\fItcpdump\fP cannot deduce the version of ESP/AH protocol.
|
|
.TP
|
|
.B \-r
|
|
Read packets from \fIfile\fR (which was created with the -w option).
|
|
Standard input is used if \fIfile\fR is ``-''.
|
|
.TP
|
|
.B \-S
|
|
Print absolute, rather than relative, TCP sequence numbers.
|
|
.TP
|
|
.B \-s
|
|
Snarf \fIsnaplen\fP bytes of data from each packet rather than the
|
|
default of 68 (with SunOS's NIT, the minimum is actually 96).
|
|
68 bytes is adequate for IP, ICMP, TCP
|
|
and UDP but may truncate protocol information from name server and NFS
|
|
packets (see below).
|
|
Packets truncated because of a limited snapshot
|
|
are indicated in the output with ``[|\fIproto\fP]'', where \fIproto\fP
|
|
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 \fIsnaplen\fP to the smallest number that will
|
|
capture the protocol information you're interested in.
|
|
Setting
|
|
\fIsnaplen\fP to 0 means use the required length to catch whole packets.
|
|
.TP
|
|
.B \-T
|
|
Force packets selected by "\fIexpression\fP" to be interpreted the
|
|
specified \fItype\fR.
|
|
Currently known types are
|
|
\fBcnfp\fR (Cisco NetFlow protocol),
|
|
\fBrpc\fR (Remote Procedure Call),
|
|
\fBrtp\fR (Real-Time Applications protocol),
|
|
\fBrtcp\fR (Real-Time Applications control protocol),
|
|
\fBsnmp\fR (Simple Network Management Protocol),
|
|
\fBvat\fR (Visual Audio Tool),
|
|
and
|
|
\fBwb\fR (distributed White Board).
|
|
.TP
|
|
.B \-t
|
|
\fIDon't\fP print a timestamp on each dump line.
|
|
.TP
|
|
.B \-tt
|
|
Print an unformatted timestamp on each dump line.
|
|
.TP
|
|
.B \-ttt
|
|
Print a delta (in micro-seconds) between current and previous line
|
|
on each dump line.
|
|
.TP
|
|
.B \-tttt
|
|
Print a timestamp in default format proceeded by date on each dump line.
|
|
.B \-u
|
|
Print undecoded NFS handles.
|
|
.TP
|
|
.B \-v
|
|
(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.
|
|
.TP
|
|
.B \-vv
|
|
Even more verbose output.
|
|
For example, additional fields are
|
|
printed from NFS reply packets, and SMB packets are fully decoded.
|
|
.TP
|
|
.B \-vvv
|
|
Even more verbose output.
|
|
For example,
|
|
telnet \fBSB\fP ... \fBSE\fP options
|
|
are printed in full.
|
|
With
|
|
.B \-X
|
|
telnet options are printed in hex as well.
|
|
.TP
|
|
.B \-w
|
|
Write the raw packets to \fIfile\fR rather than parsing and printing
|
|
them out.
|
|
They can later be printed with the \-r option.
|
|
Standard output is used if \fIfile\fR is ``-''.
|
|
.TP
|
|
.B \-x
|
|
Print each packet (minus its link level header) in hex.
|
|
The smaller of the entire packet or
|
|
.I snaplen
|
|
bytes will be printed.
|
|
.TP
|
|
.B \-X
|
|
When printing hex, print ascii too.
|
|
Thus if
|
|
.B \-x
|
|
is also set, the packet is printed in hex/ascii.
|
|
This is very handy for analysing new protocols.
|
|
Even if
|
|
.B \-x
|
|
is not also set, some parts of some packets may be printed
|
|
in hex/ascii.
|
|
.IP "\fI expression\fP"
|
|
.RS
|
|
selects which packets will be dumped.
|
|
If no \fIexpression\fP
|
|
is given, all packets on the net will be dumped.
|
|
Otherwise,
|
|
only packets for which \fIexpression\fP is `true' will be dumped.
|
|
.LP
|
|
The \fIexpression\fP consists of one or more
|
|
.I primitives.
|
|
Primitives usually consist of an
|
|
.I id
|
|
(name or number) preceded by one or more qualifiers.
|
|
There are three
|
|
different kinds of qualifier:
|
|
.IP \fItype\fP
|
|
qualifiers say what kind of thing the id name or number refers to.
|
|
Possible types are
|
|
.BR host ,
|
|
.B net
|
|
and
|
|
.BR port .
|
|
E.g., `host foo', `net 128.3', `port 20'.
|
|
If there is no type
|
|
qualifier,
|
|
.B host
|
|
is assumed.
|
|
.IP \fIdir\fP
|
|
qualifiers specify a particular transfer direction to and/or from
|
|
.IR id .
|
|
Possible directions are
|
|
.BR src ,
|
|
.BR dst ,
|
|
.B "src or dst"
|
|
and
|
|
.B "src and"
|
|
.BR dst .
|
|
E.g., `src foo', `dst net 128.3', `src or dst port ftp-data'.
|
|
If
|
|
there is no dir qualifier,
|
|
.B "src or dst"
|
|
is assumed.
|
|
For `null' link layers (i.e. point to point protocols such as slip) the
|
|
.B inbound
|
|
and
|
|
.B outbound
|
|
qualifiers can be used to specify a desired direction.
|
|
.IP \fIproto\fP
|
|
qualifiers restrict the match to a particular protocol.
|
|
Possible
|
|
protos are:
|
|
.BR ether ,
|
|
.BR fddi ,
|
|
.BR tr ,
|
|
.BR ip ,
|
|
.BR ip6 ,
|
|
.BR arp ,
|
|
.BR rarp ,
|
|
.BR decnet ,
|
|
.BR lat ,
|
|
.BR sca ,
|
|
.BR moprc ,
|
|
.BR mopdl ,
|
|
.BR iso ,
|
|
.BR esis ,
|
|
.BR isis ,
|
|
.BR icmp ,
|
|
.BR icmp6 ,
|
|
.B tcp
|
|
and
|
|
.BR udp .
|
|
E.g., `ether src foo', `arp net 128.3', `tcp port 21'.
|
|
If there is
|
|
no proto qualifier, all protocols consistent with the type are
|
|
assumed.
|
|
E.g., `src foo' means `(ip or arp or rarp) src foo'
|
|
(except the latter is not legal syntax), `net bar' means `(ip or
|
|
arp or rarp) net bar' and `port 53' means `(tcp or udp) port 53'.
|
|
.LP
|
|
[`fddi' is actually an alias for `ether'; the parser treats them
|
|
identically as meaning ``the data link level used on the specified
|
|
network interface.'' FDDI headers contain Ethernet-like source
|
|
and destination addresses, and often contain Ethernet-like packet
|
|
types, so you can filter on these FDDI fields just as with the
|
|
analogous Ethernet fields.
|
|
FDDI headers also contain other fields,
|
|
but you cannot name them explicitly in a filter expression.
|
|
.LP
|
|
Similarly, `tr' is an alias for `ether'; the previous paragraph's
|
|
statements about FDDI headers also apply to Token Ring headers.]
|
|
.LP
|
|
In addition to the above, there are some special `primitive' keywords
|
|
that don't follow the pattern:
|
|
.BR gateway ,
|
|
.BR broadcast ,
|
|
.BR less ,
|
|
.B greater
|
|
and arithmetic expressions.
|
|
All of these are described below.
|
|
.LP
|
|
More complex filter expressions are built up by using the words
|
|
.BR and ,
|
|
.B or
|
|
and
|
|
.B not
|
|
to combine primitives.
|
|
E.g., `host foo and not port ftp and not port ftp-data'.
|
|
To save typing, identical qualifier lists can be omitted.
|
|
E.g.,
|
|
`tcp dst port ftp or ftp-data or domain' is exactly the same as
|
|
`tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.
|
|
.LP
|
|
Allowable primitives are:
|
|
.IP "\fBdst host \fIhost\fR"
|
|
True if the IPv4/v6 destination field of the packet is \fIhost\fP,
|
|
which may be either an address or a name.
|
|
.IP "\fBsrc host \fIhost\fR"
|
|
True if the IPv4/v6 source field of the packet is \fIhost\fP.
|
|
.IP "\fBhost \fIhost\fP
|
|
True if either the IPv4/v6 source or destination of the packet is \fIhost\fP.
|
|
Any of the above host expressions can be prepended with the keywords,
|
|
\fBip\fP, \fBarp\fP, \fBrarp\fP, or \fBip6\fP as in:
|
|
.in +.5i
|
|
.nf
|
|
\fBip host \fIhost\fR
|
|
.fi
|
|
.in -.5i
|
|
which is equivalent to:
|
|
.in +.5i
|
|
.nf
|
|
\fBether proto \fI\\ip\fB and host \fIhost\fR
|
|
.fi
|
|
.in -.5i
|
|
If \fIhost\fR is a name with multiple IP addresses, each address will
|
|
be checked for a match.
|
|
.IP "\fBether dst \fIehost\fP
|
|
True if the ethernet destination address is \fIehost\fP.
|
|
\fIEhost\fP
|
|
may be either a name from /etc/ethers or a number (see
|
|
.IR ethers (3N)
|
|
for numeric format).
|
|
.IP "\fBether src \fIehost\fP
|
|
True if the ethernet source address is \fIehost\fP.
|
|
.IP "\fBether host \fIehost\fP
|
|
True if either the ethernet source or destination address is \fIehost\fP.
|
|
.IP "\fBgateway\fP \fIhost\fP
|
|
True if the packet used \fIhost\fP as a gateway.
|
|
I.e., the ethernet
|
|
source or destination address was \fIhost\fP but neither the IP source
|
|
nor the IP destination was \fIhost\fP.
|
|
\fIHost\fP must be a name and
|
|
must be found both by the machine's host-name-to-IP-address resolution
|
|
mechanisms (host name file, DNS, NIS, etc.) and by the machine's
|
|
host-name-to-Ethernet-address resolution mechanism (/etc/ethers, etc.).
|
|
(An equivalent expression is
|
|
.in +.5i
|
|
.nf
|
|
\fBether host \fIehost \fBand not host \fIhost\fR
|
|
.fi
|
|
.in -.5i
|
|
which can be used with either names or numbers for \fIhost / ehost\fP.)
|
|
This syntax does not work in IPv6-enabled configuration at this moment.
|
|
.IP "\fBdst net \fInet\fR"
|
|
True if the IPv4/v6 destination address of the packet has a network
|
|
number of \fInet\fP.
|
|
\fINet\fP may be either a name from /etc/networks
|
|
or a network number (see \fInetworks(4)\fP for details).
|
|
.IP "\fBsrc net \fInet\fR"
|
|
True if the IPv4/v6 source address of the packet has a network
|
|
number of \fInet\fP.
|
|
.IP "\fBnet \fInet\fR"
|
|
True if either the IPv4/v6 source or destination address of the packet has a network
|
|
number of \fInet\fP.
|
|
.IP "\fBnet \fInet\fR \fBmask \fInetmask\fR"
|
|
True if the IP address matches \fInet\fR with the specific \fInetmask\fR.
|
|
May be qualified with \fBsrc\fR or \fBdst\fR.
|
|
Note that this syntax is not valid for IPv6 \fInet\fR.
|
|
.IP "\fBnet \fInet\fR/\fIlen\fR"
|
|
True if the IPv4/v6 address matches \fInet\fR with a netmask \fIlen\fR
|
|
bits wide.
|
|
May be qualified with \fBsrc\fR or \fBdst\fR.
|
|
.IP "\fBdst port \fIport\fR"
|
|
True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and has a
|
|
destination port value of \fIport\fP.
|
|
The \fIport\fP can be a number or a name used in /etc/services (see
|
|
.IR tcp (4P)
|
|
and
|
|
.IR udp (4P)).
|
|
If a name is used, both the port
|
|
number and protocol are checked.
|
|
If a number or ambiguous name is used,
|
|
only the port number is checked (e.g., \fBdst port 513\fR will print both
|
|
tcp/login traffic and udp/who traffic, and \fBport domain\fR will print
|
|
both tcp/domain and udp/domain traffic).
|
|
.IP "\fBsrc port \fIport\fR"
|
|
True if the packet has a source port value of \fIport\fP.
|
|
.IP "\fBport \fIport\fR"
|
|
True if either the source or destination port of the packet is \fIport\fP.
|
|
Any of the above port expressions can be prepended with the keywords,
|
|
\fBtcp\fP or \fBudp\fP, as in:
|
|
.in +.5i
|
|
.nf
|
|
\fBtcp src port \fIport\fR
|
|
.fi
|
|
.in -.5i
|
|
which matches only tcp packets whose source port is \fIport\fP.
|
|
.IP "\fBless \fIlength\fR"
|
|
True if the packet has a length less than or equal to \fIlength\fP.
|
|
This is equivalent to:
|
|
.in +.5i
|
|
.nf
|
|
\fBlen <= \fIlength\fP.
|
|
.fi
|
|
.in -.5i
|
|
.IP "\fBgreater \fIlength\fR"
|
|
True if the packet has a length greater than or equal to \fIlength\fP.
|
|
This is equivalent to:
|
|
.in +.5i
|
|
.nf
|
|
\fBlen >= \fIlength\fP.
|
|
.fi
|
|
.in -.5i
|
|
.IP "\fBip proto \fIprotocol\fR"
|
|
True if the packet is an IP packet (see
|
|
.IR ip (4P))
|
|
of protocol type \fIprotocol\fP.
|
|
\fIProtocol\fP can be a number or one of the names
|
|
\fIicmp\fP, \fIicmp6\fP, \fIigmp\fP, \fIigrp\fP, \fIpim\fP, \fIah\fP,
|
|
\fIesp\fP, \fIvrrp\fP, \fIudp\fP, or \fItcp\fP.
|
|
Note that the identifiers \fItcp\fP, \fIudp\fP, and \fIicmp\fP are also
|
|
keywords and must be escaped via backslash (\\), which is \\\\ in the C-shell.
|
|
Note that this primitive does not chase the protocol header chain.
|
|
.IP "\fBip6 proto \fIprotocol\fR"
|
|
True if the packet is an IPv6 packet of protocol type \fIprotocol\fP.
|
|
Note that this primitive does not chase the protocol header chain.
|
|
.IP "\fBip6 protochain \fIprotocol\fR"
|
|
True if the packet is IPv6 packet,
|
|
and contains protocol header with type \fIprotocol\fR
|
|
in its protocol header chain.
|
|
For example,
|
|
.in +.5i
|
|
.nf
|
|
\fBip6 protochain 6\fR
|
|
.fi
|
|
.in -.5i
|
|
matches any IPv6 packet with TCP protocol header in the protocol header chain.
|
|
The packet may contain, for example,
|
|
authentication header, routing header, or hop-by-hop option header,
|
|
between IPv6 header and TCP header.
|
|
The BPF code emitted by this primitive is complex and
|
|
cannot be optimized by BPF optimizer code in \fItcpdump\fP,
|
|
so this can be somewhat slow.
|
|
.IP "\fBip protochain \fIprotocol\fR"
|
|
Equivalent to \fBip6 protochain \fIprotocol\fR, but this is for IPv4.
|
|
.IP "\fBether broadcast\fR"
|
|
True if the packet is an ethernet broadcast packet.
|
|
The \fIether\fP
|
|
keyword is optional.
|
|
.IP "\fBip broadcast\fR"
|
|
True if the packet is an IP broadcast packet.
|
|
It checks for both
|
|
the all-zeroes and all-ones broadcast conventions, and looks up
|
|
the local subnet mask.
|
|
.IP "\fBether multicast\fR"
|
|
True if the packet is an ethernet multicast packet.
|
|
The \fIether\fP
|
|
keyword is optional.
|
|
This is shorthand for `\fBether[0] & 1 != 0\fP'.
|
|
.IP "\fBip multicast\fR"
|
|
True if the packet is an IP multicast packet.
|
|
.IP "\fBip6 multicast\fR"
|
|
True if the packet is an IPv6 multicast packet.
|
|
.IP "\fBether proto \fIprotocol\fR"
|
|
True if the packet is of ether type \fIprotocol\fR.
|
|
\fIProtocol\fP can be a number or one of the names
|
|
\fIip\fP, \fIip6\fP, \fIarp\fP, \fIrarp\fP, \fIatalk\fP, \fIaarp\fP,
|
|
\fIdecnet\fP, \fIsca\fP, \fIlat\fP, \fImopdl\fP, \fImoprc\fP,
|
|
\fIiso\fP, \fIstp\fP, \fIipx\fP, or \fInetbeui\fP.
|
|
Note these identifiers are also keywords
|
|
and must be escaped via backslash (\\).
|
|
.IP
|
|
[In the case of FDDI (e.g., `\fBfddi protocol arp\fR') and Token Ring
|
|
(e.g., `\fBtr protocol arp\fR'), for most of those protocols, the
|
|
protocol identification comes from the 802.2 Logical Link Control (LLC)
|
|
header, which is usually layered on top of the FDDI or Token Ring
|
|
header.
|
|
.IP
|
|
When filtering for most protocol identifiers on FDDI or Token Ring,
|
|
\fItcpdump\fR checks only the protocol ID field of an LLC header in
|
|
so-called SNAP format with an Organizational Unit Identifier (OUI) of
|
|
0x000000, for encapsulated Ethernet; it doesn't check whether the packet
|
|
is in SNAP format with an OUI of 0x000000.
|
|
.IP
|
|
The exceptions are \fIiso\fP, for which it checks the DSAP (Destination
|
|
Service Access Point) and SSAP (Source Service Access Point) fields of
|
|
the LLC header, \fIstp\fP and \fInetbeui\fP, where it checks the DSAP of
|
|
the LLC header, and \fIatalk\fP, where it checks for a SNAP-format
|
|
packet with an OUI of 0x080007 and the Appletalk etype.
|
|
.IP
|
|
In the case of Ethernet, \fItcpdump\fR checks the Ethernet type field
|
|
for most of those protocols; the exceptions are \fIiso\fP, \fIsap\fP,
|
|
and \fInetbeui\fP, for which it checks for an 802.3 frame and then
|
|
checks the LLC header as it does for FDDI and Token Ring, \fIatalk\fP,
|
|
where it checks both for the Appletalk etype in an Ethernet frame and
|
|
for a SNAP-format packet as it does for FDDI and Token Ring, \fIaarp\fP,
|
|
where it checks for the Appletalk ARP etype in either an Ethernet frame
|
|
or an 802.2 SNAP frame with an OUI of 0x000000, and \fIipx\fP, where it
|
|
checks for the IPX etype in an Ethernet frame, the IPX DSAP in the LLC
|
|
header, the 802.3 with no LLC header encapsulation of IPX, and the IPX
|
|
etype in a SNAP frame.]
|
|
.IP "\fBdecnet src \fIhost\fR"
|
|
True if the DECNET source address is
|
|
.IR host ,
|
|
which may be an address of the form ``10.123'', or a DECNET host
|
|
name.
|
|
[DECNET host name support is only available on Ultrix systems
|
|
that are configured to run DECNET.]
|
|
.IP "\fBdecnet dst \fIhost\fR"
|
|
True if the DECNET destination address is
|
|
.IR host .
|
|
.IP "\fBdecnet host \fIhost\fR"
|
|
True if either the DECNET source or destination address is
|
|
.IR host .
|
|
.IP "\fBip\fR, \fBip6\fR, \fBarp\fR, \fBrarp\fR, \fBatalk\fR, \fBaarp\fR, \fBdecnet\fR, \fBiso\fR, \fBstp\fR, \fBipx\fR, \fInetbeui\fP"
|
|
Abbreviations for:
|
|
.in +.5i
|
|
.nf
|
|
\fBether proto \fIp\fR
|
|
.fi
|
|
.in -.5i
|
|
where \fIp\fR is one of the above protocols.
|
|
.IP "\fBlat\fR, \fBmoprc\fR, \fBmopdl\fR"
|
|
Abbreviations for:
|
|
.in +.5i
|
|
.nf
|
|
\fBether proto \fIp\fR
|
|
.fi
|
|
.in -.5i
|
|
where \fIp\fR is one of the above protocols.
|
|
Note that
|
|
\fItcpdump\fP does not currently know how to parse these protocols.
|
|
.IP "\fBvlan \fI[vlan_id]\fR"
|
|
True if the packet is an IEEE 802.1Q VLAN packet.
|
|
If \fI[vlan_id]\fR is specified, only true is the packet has the specified
|
|
\fIvlan_id\fR.
|
|
Note that the first \fBvlan\fR keyword encountered in \fIexpression\fR
|
|
changes the decoding offsets for the remainder of \fIexpression\fR
|
|
on the assumption that the packet is a VLAN packet.
|
|
.IP "\fBtcp\fR, \fBudp\fR, \fBicmp\fR"
|
|
Abbreviations for:
|
|
.in +.5i
|
|
.nf
|
|
\fBip proto \fIp\fR\fB or ip6 proto \fIp\fR
|
|
.fi
|
|
.in -.5i
|
|
where \fIp\fR is one of the above protocols.
|
|
.IP "\fBiso proto \fIprotocol\fR"
|
|
True if the packet is an OSI packet of protocol type \fIprotocol\fP.
|
|
\fIProtocol\fP can be a number or one of the names
|
|
\fIclnp\fP, \fIesis\fP, or \fIisis\fP.
|
|
.IP "\fBclnp\fR, \fBesis\fR, \fBisis\fR"
|
|
Abbreviations for:
|
|
.in +.5i
|
|
.nf
|
|
\fBiso proto \fIp\fR
|
|
.fi
|
|
.in -.5i
|
|
where \fIp\fR is one of the above protocols.
|
|
Note that \fItcpdump\fR does an incomplete job of parsing these protocols.
|
|
.IP "\fIexpr relop expr\fR"
|
|
True if the relation holds, where \fIrelop\fR is one of >, <, >=, <=, =, !=,
|
|
and \fIexpr\fR is an arithmetic expression composed of integer constants
|
|
(expressed in standard C syntax), the normal binary operators
|
|
[+, -, *, /, &, |], a length operator, and special packet data accessors.
|
|
To access
|
|
data inside the packet, use the following syntax:
|
|
.in +.5i
|
|
.nf
|
|
\fIproto\fB [ \fIexpr\fB : \fIsize\fB ]\fR
|
|
.fi
|
|
.in -.5i
|
|
\fIProto\fR is one of \fBether, fddi, tr,
|
|
ip, arp, rarp, tcp, udp, icmp\fR or \fBip6\fR, and
|
|
indicates the protocol layer for the index operation.
|
|
Note that \fItcp, udp\fR and other upper-layer protocol types only
|
|
apply to IPv4, not IPv6 (this will be fixed in the future).
|
|
The byte offset, relative to the indicated protocol layer, is
|
|
given by \fIexpr\fR.
|
|
\fISize\fR is optional and indicates the number of bytes in the
|
|
field of interest; it can be either one, two, or four, and defaults to one.
|
|
The length operator, indicated by the keyword \fBlen\fP, gives the
|
|
length of the packet.
|
|
|
|
For example, `\fBether[0] & 1 != 0\fP' catches all multicast traffic.
|
|
The expression `\fBip[0] & 0xf != 5\fP'
|
|
catches all IP packets with options.
|
|
The expression
|
|
`\fBip[6:2] & 0x1fff = 0\fP'
|
|
catches only unfragmented datagrams and frag zero of fragmented datagrams.
|
|
This check is implicitly applied to the \fBtcp\fP and \fBudp\fP
|
|
index operations.
|
|
For instance, \fBtcp[0]\fP always means the first
|
|
byte of the TCP \fIheader\fP, and never means the first byte of an
|
|
intervening fragment.
|
|
|
|
Some offsets and field values may be expressed as names rather than
|
|
as numeric values.
|
|
The following protocol header field offsets are
|
|
available: \fBicmptype\fP (ICMP type field), \fBicmpcode\fP (ICMP
|
|
code field), and \fBtcpflags\fP (TCP flags field).
|
|
|
|
The following ICMP type field values are available: \fBicmp-echoreply\fP,
|
|
\fBicmp-unreach\fP, \fBicmp-sourcequench\fP, \fBicmp-redirect\fP,
|
|
\fBicmp-echo\fP, \fBicmp-routeradvert\fP, \fBicmp-routersolicit\fP,
|
|
\fBicmp-timxceed\fP, \fBicmp-paramprob\fP, \fBicmp-tstamp\fP,
|
|
\fBicmp-tstampreply\fP, \fBicmp-ireq\fP, \fBicmp-ireqreply\fP,
|
|
\fBicmp-maskreq\fP, \fBicmp-maskreply\fP.
|
|
|
|
The following TCP flags field values are available: \fBtcp-fin\fP,
|
|
\fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-push\fP, \fBtcp-push\fP,
|
|
\fBtcp-ack\fP, \fBtcp-urg\fP.
|
|
.LP
|
|
Primitives may be combined using:
|
|
.IP
|
|
A parenthesized group of primitives and operators
|
|
(parentheses are special to the Shell and must be escaped).
|
|
.IP
|
|
Negation (`\fB!\fP' or `\fBnot\fP').
|
|
.IP
|
|
Concatenation (`\fB&&\fP' or `\fBand\fP').
|
|
.IP
|
|
Alternation (`\fB||\fP' or `\fBor\fP').
|
|
.LP
|
|
Negation has highest precedence.
|
|
Alternation and concatenation have equal precedence and associate
|
|
left to right.
|
|
Note that explicit \fBand\fR tokens, not juxtaposition,
|
|
are now required for concatenation.
|
|
.LP
|
|
If an identifier is given without a keyword, the most recent keyword
|
|
is assumed.
|
|
For example,
|
|
.in +.5i
|
|
.nf
|
|
\fBnot host vs and ace\fR
|
|
.fi
|
|
.in -.5i
|
|
is short for
|
|
.in +.5i
|
|
.nf
|
|
\fBnot host vs and host ace\fR
|
|
.fi
|
|
.in -.5i
|
|
which should not be confused with
|
|
.in +.5i
|
|
.nf
|
|
\fBnot ( host vs or ace )\fR
|
|
.fi
|
|
.in -.5i
|
|
.LP
|
|
Expression arguments can be passed to \fItcpdump\fP as either a single
|
|
argument or as multiple arguments, whichever is more convenient.
|
|
Generally, if the expression contains Shell metacharacters, it is
|
|
easier to pass it as a single, quoted argument.
|
|
Multiple arguments are concatenated with spaces before being parsed.
|
|
.SH EXAMPLES
|
|
.LP
|
|
To print all packets arriving at or departing from \fIsundown\fP:
|
|
.RS
|
|
.nf
|
|
\fBtcpdump host sundown\fP
|
|
.fi
|
|
.RE
|
|
.LP
|
|
To print traffic between \fIhelios\fR and either \fIhot\fR or \fIace\fR:
|
|
.RS
|
|
.nf
|
|
\fBtcpdump host helios and \\( hot or ace \\)\fP
|
|
.fi
|
|
.RE
|
|
.LP
|
|
To print all IP packets between \fIace\fR and any host except \fIhelios\fR:
|
|
.RS
|
|
.nf
|
|
\fBtcpdump ip host ace and not helios\fP
|
|
.fi
|
|
.RE
|
|
.LP
|
|
To print all traffic between local hosts and hosts at Berkeley:
|
|
.RS
|
|
.nf
|
|
.B
|
|
tcpdump net ucb-ether
|
|
.fi
|
|
.RE
|
|
.LP
|
|
To print all ftp traffic through internet gateway \fIsnup\fP:
|
|
(note that the expression is quoted to prevent the shell from
|
|
(mis-)interpreting the parentheses):
|
|
.RS
|
|
.nf
|
|
.B
|
|
tcpdump 'gateway snup and (port ftp or ftp-data)'
|
|
.fi
|
|
.RE
|
|
.LP
|
|
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).
|
|
.RS
|
|
.nf
|
|
.B
|
|
tcpdump ip and not net \fIlocalnet\fP
|
|
.fi
|
|
.RE
|
|
.LP
|
|
To print the start and end packets (the SYN and FIN packets) of each
|
|
TCP conversation that involves a non-local host.
|
|
.RS
|
|
.nf
|
|
.B
|
|
tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net \fIlocalnet\fP'
|
|
.fi
|
|
.RE
|
|
.LP
|
|
To print IP packets longer than 576 bytes sent through gateway \fIsnup\fP:
|
|
.RS
|
|
.nf
|
|
.B
|
|
tcpdump 'gateway snup and ip[2:2] > 576'
|
|
.fi
|
|
.RE
|
|
.LP
|
|
To print IP broadcast or multicast packets that were
|
|
.I not
|
|
sent via ethernet broadcast or multicast:
|
|
.RS
|
|
.nf
|
|
.B
|
|
tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
|
|
.fi
|
|
.RE
|
|
.LP
|
|
To print all ICMP packets that are not echo requests/replies (i.e., not
|
|
ping packets):
|
|
.RS
|
|
.nf
|
|
.B
|
|
tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
|
|
.fi
|
|
.RE
|
|
.SH OUTPUT FORMAT
|
|
.LP
|
|
The output of \fItcpdump\fP is protocol dependent.
|
|
The following
|
|
gives a brief description and examples of most of the formats.
|
|
.de HD
|
|
.sp 1.5
|
|
.B
|
|
..
|
|
.HD
|
|
Link Level Headers
|
|
.LP
|
|
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.
|
|
.LP
|
|
On FDDI networks, the '-e' option causes \fItcpdump\fP 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, `\fBasync4\fR'.
|
|
Such packets
|
|
are assumed to contain an 802.2 Logical Link Control (LLC) packet;
|
|
the LLC header is printed if it is \fInot\fR an ISO datagram or a
|
|
so-called SNAP packet.
|
|
.LP
|
|
On Token Ring networks, the '-e' option causes \fItcpdump\fP 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.
|
|
.LP
|
|
\fI(N.B.: The following description assumes familiarity with
|
|
the SLIP compression algorithm described in RFC-1144.)\fP
|
|
.LP
|
|
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 \fIip\fP, \fIutcp\fP, and \fIctcp\fP.
|
|
No further link information is printed for \fIip\fR 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
|
|
\fB*S+\fIn\fR and \fB*SA+\fIn\fR, where \fIn\fR 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.
|
|
.LP
|
|
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:
|
|
.RS
|
|
.nf
|
|
\fBO ctcp * A+6 S+49 I+6 3 (6)\fP
|
|
.fi
|
|
.RE
|
|
.HD
|
|
ARP/RARP Packets
|
|
.LP
|
|
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 \fIrtsg\fP to host \fIcsam\fP:
|
|
.RS
|
|
.nf
|
|
.sp .5
|
|
\f(CWarp who-has csam tell rtsg
|
|
arp reply csam is-at CSAM\fR
|
|
.sp .5
|
|
.fi
|
|
.RE
|
|
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).
|
|
.LP
|
|
This would look less redundant if we had done \fItcpdump \-n\fP:
|
|
.RS
|
|
.nf
|
|
.sp .5
|
|
\f(CWarp 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\fP
|
|
.fi
|
|
.RE
|
|
.LP
|
|
If we had done \fItcpdump \-e\fP, the fact that the first packet is
|
|
broadcast and the second is point-to-point would be visible:
|
|
.RS
|
|
.nf
|
|
.sp .5
|
|
\f(CWRTSG Broadcast 0806 64: arp who-has csam tell rtsg
|
|
CSAM RTSG 0806 64: arp reply csam is-at CSAM\fR
|
|
.sp .5
|
|
.fi
|
|
.RE
|
|
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.
|
|
.HD
|
|
TCP Packets
|
|
.LP
|
|
\fI(N.B.:The following description assumes familiarity with
|
|
the TCP protocol described in RFC-793.
|
|
If you are not familiar
|
|
with the protocol, neither this description nor \fItcpdump\fP will
|
|
be of much use to you.)\fP
|
|
.LP
|
|
The general format of a tcp protocol line is:
|
|
.RS
|
|
.nf
|
|
.sp .5
|
|
\fIsrc > dst: flags data-seqno ack window urgent options\fP
|
|
.sp .5
|
|
.fi
|
|
.RE
|
|
\fISrc\fP and \fIdst\fP are the source and destination IP
|
|
addresses and ports.
|
|
\fIFlags\fP are some combination of S (SYN),
|
|
F (FIN), P (PUSH) or R (RST) or a single `.' (no flags).
|
|
\fIData-seqno\fP describes the portion of sequence space covered
|
|
by the data in this packet (see example below).
|
|
\fIAck\fP is sequence number of the next data expected the other
|
|
direction on this connection.
|
|
\fIWindow\fP is the number of bytes of receive buffer space available
|
|
the other direction on this connection.
|
|
\fIUrg\fP indicates there is `urgent' data in the packet.
|
|
\fIOptions\fP are tcp options enclosed in angle brackets (e.g., <mss 1024>).
|
|
.LP
|
|
\fISrc, dst\fP and \fIflags\fP are always present.
|
|
The other fields
|
|
depend on the contents of the packet's tcp protocol header and
|
|
are output only if appropriate.
|
|
.LP
|
|
Here is the opening portion of an rlogin from host \fIrtsg\fP to
|
|
host \fIcsam\fP.
|
|
.RS
|
|
.nf
|
|
.sp .5
|
|
\s-2\f(CWrtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
|
|
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
|
|
rtsg.1023 > csam.login: . ack 1 win 4096
|
|
rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
|
|
csam.login > rtsg.1023: . ack 2 win 4096
|
|
rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
|
|
csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
|
|
csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
|
|
csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1\fR\s+2
|
|
.sp .5
|
|
.fi
|
|
.RE
|
|
The first line says that tcp port 1023 on rtsg sent a packet
|
|
to port \fIlogin\fP
|
|
on csam.
|
|
The \fBS\fP indicates that the \fISYN\fP flag was set.
|
|
The packet sequence number was 768512 and it contained no data.
|
|
(The notation is `first:last(nbytes)' which means `sequence
|
|
numbers \fIfirst\fP
|
|
up to but not including \fIlast\fP which is \fInbytes\fP bytes of user data'.)
|
|
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.
|
|
.LP
|
|
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 no
|
|
flags were set.
|
|
The packet contained no data so there is no data sequence number.
|
|
Note that the ack sequence
|
|
number is a small integer (1).
|
|
The first time \fItcpdump\fP 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.
|
|
.LP
|
|
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.
|
|
.LP
|
|
If the snapshot was small enough that \fItcpdump\fP didn't capture
|
|
the full TCP header, it interprets as much of the header as it can
|
|
and then reports ``[|\fItcp\fP]'' 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), \fItcpdump\fP
|
|
reports it as ``[\fIbad opt\fP]'' 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, \fItcpdump\fP reports
|
|
it as ``[\fIbad hdr length\fP]''.
|
|
.HD
|
|
.B Capturing TCP packets with particular flag combinations (SYN-ACK, URG-ACK, etc.)
|
|
.PP
|
|
There are 8 bits in the control bits section of the TCP header:
|
|
.IP
|
|
.I CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
|
|
.PP
|
|
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
|
|
.PP
|
|
.RS
|
|
1) Caller sends SYN
|
|
.RE
|
|
.RS
|
|
2) Recipient responds with SYN, ACK
|
|
.RE
|
|
.RS
|
|
3) Caller sends ACK
|
|
.RE
|
|
.PP
|
|
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 \fItcpdump\fP.
|
|
.PP
|
|
Recall the structure of a TCP header without options:
|
|
.PP
|
|
.nf
|
|
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 |
|
|
-----------------------------------------------------------------
|
|
.fi
|
|
.PP
|
|
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.
|
|
.PP
|
|
Starting to count with 0, the relevant TCP control bits are contained
|
|
in octet 13:
|
|
.PP
|
|
.nf
|
|
0 7| 15| 23| 31
|
|
----------------|---------------|---------------|----------------
|
|
| HL | rsvd |C|E|U|A|P|R|S|F| window size |
|
|
----------------|---------------|---------------|----------------
|
|
| | 13th octet | | |
|
|
.fi
|
|
.PP
|
|
Let's have a closer look at octet no. 13:
|
|
.PP
|
|
.nf
|
|
| |
|
|
|---------------|
|
|
|C|E|U|A|P|R|S|F|
|
|
|---------------|
|
|
|7 5 3 0|
|
|
.fi
|
|
.PP
|
|
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.
|
|
.PP
|
|
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:
|
|
.PP
|
|
.nf
|
|
|C|E|U|A|P|R|S|F|
|
|
|---------------|
|
|
|0 0 0 0 0 0 1 0|
|
|
|---------------|
|
|
|7 6 5 4 3 2 1 0|
|
|
.fi
|
|
.PP
|
|
Looking at the
|
|
control bits section we see that only bit number 1 (SYN) is set.
|
|
.PP
|
|
Assuming that octet number 13 is an 8-bit unsigned integer in
|
|
network byte order, the binary value of this octet is
|
|
.IP
|
|
00000010
|
|
.PP
|
|
and its decimal representation is
|
|
.PP
|
|
.nf
|
|
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
|
|
.fi
|
|
.PP
|
|
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.
|
|
.PP
|
|
This relationship can be expressed as
|
|
.RS
|
|
.B
|
|
tcp[13] == 2
|
|
.RE
|
|
.PP
|
|
We can use this expression as the filter for \fItcpdump\fP in order
|
|
to watch packets which have only SYN set:
|
|
.RS
|
|
.B
|
|
tcpdump -i xl0 tcp[13] == 2
|
|
.RE
|
|
.PP
|
|
The expression says "let the 13th octet of a TCP datagram have
|
|
the decimal value 2", which is exactly what we want.
|
|
.PP
|
|
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:
|
|
.PP
|
|
.nf
|
|
|C|E|U|A|P|R|S|F|
|
|
|---------------|
|
|
|0 0 0 1 0 0 1 0|
|
|
|---------------|
|
|
|7 6 5 4 3 2 1 0|
|
|
.fi
|
|
.PP
|
|
Now bits 1 and 4 are set in the 13th octet.
|
|
The binary value of
|
|
octet 13 is
|
|
.IP
|
|
00010010
|
|
.PP
|
|
which translates to decimal
|
|
.PP
|
|
.nf
|
|
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
|
|
.fi
|
|
.PP
|
|
Now we can't just use 'tcp[13] == 18' in the \fItcpdump\fP 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.
|
|
.PP
|
|
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:
|
|
.PP
|
|
.nf
|
|
|
|
00010010 SYN-ACK 00000010 SYN
|
|
AND 00000010 (we want SYN) AND 00000010 (we want SYN)
|
|
-------- --------
|
|
= 00000010 = 00000010
|
|
.fi
|
|
.PP
|
|
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:
|
|
.IP
|
|
( ( value of octet 13 ) AND ( 2 ) ) == ( 2 )
|
|
.PP
|
|
This points us to the \fItcpdump\fP filter expression
|
|
.RS
|
|
.B
|
|
tcpdump -i xl0 'tcp[13] & 2 == 2'
|
|
.RE
|
|
.PP
|
|
Note that you should use single quotes or a backslash
|
|
in the expression to hide the AND ('&') special character
|
|
from the shell.
|
|
.HD
|
|
.B
|
|
UDP Packets
|
|
.LP
|
|
UDP format is illustrated by this rwho packet:
|
|
.RS
|
|
.nf
|
|
.sp .5
|
|
\f(CWactinide.who > broadcast.who: udp 84\fP
|
|
.sp .5
|
|
.fi
|
|
.RE
|
|
This says that port \fIwho\fP on host \fIactinide\fP sent a udp
|
|
datagram to port \fIwho\fP on host \fIbroadcast\fP, the Internet
|
|
broadcast address.
|
|
The packet contained 84 bytes of user data.
|
|
.LP
|
|
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.
|
|
.HD
|
|
UDP Name Server Requests
|
|
.LP
|
|
\fI(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.)\fP
|
|
.LP
|
|
Name server requests are formatted as
|
|
.RS
|
|
.nf
|
|
.sp .5
|
|
\fIsrc > dst: id op? flags qtype qclass name (len)\fP
|
|
.sp .5
|
|
\f(CWh2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)\fR
|
|
.sp .5
|
|
.fi
|
|
.RE
|
|
Host \fIh2opolo\fP asked the domain server on \fIhelios\fP for an
|
|
address record (qtype=A) associated with the name \fIucbvax.berkeley.edu.\fP
|
|
The query id was `3'.
|
|
The `+' indicates the \fIrecursion desired\fP flag
|
|
was set.
|
|
The query length was 37 bytes, not including the UDP and
|
|
IP protocol headers.
|
|
The query operation was the normal one, \fIQuery\fP,
|
|
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,
|
|
\fIC_IN\fP, and omitted.
|
|
Any other qclass would have been printed
|
|
immediately after the `A'.
|
|
.LP
|
|
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,
|
|
.IR ancount ,
|
|
.IR nscount ,
|
|
or
|
|
.I arcount
|
|
are printed as `[\fIn\fPa]', `[\fIn\fPn]' or `[\fIn\fPau]' where \fIn\fP
|
|
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=\fIx\fP]'
|
|
is printed, where \fIx\fP is the hex value of header bytes two and three.
|
|
.HD
|
|
UDP Name Server Responses
|
|
.LP
|
|
Name server responses are formatted as
|
|
.RS
|
|
.nf
|
|
.sp .5
|
|
\fIsrc > dst: id op rcode flags a/n/au type class data (len)\fP
|
|
.sp .5
|
|
\f(CWhelios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
|
|
helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)\fR
|
|
.sp .5
|
|
.fi
|
|
.RE
|
|
In the first example, \fIhelios\fP responds to query id 3 from \fIh2opolo\fP
|
|
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.
|
|
.LP
|
|
In the second example, \fIhelios\fP 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 \fIauthoritative answer\fP bit was set.
|
|
Since there were no
|
|
answers, no type, class or data were printed.
|
|
.LP
|
|
Other flag characters that might appear are `\-' (recursion available,
|
|
RA, \fInot\fP set) and `|' (truncated message, TC, set).
|
|
If the
|
|
`question' section doesn't contain exactly one entry, `[\fIn\fPq]'
|
|
is printed.
|
|
.LP
|
|
Note that name server requests and responses tend to be large and the
|
|
default \fIsnaplen\fP of 68 bytes may not capture enough of the packet
|
|
to print.
|
|
Use the \fB\-s\fP flag to increase the snaplen if you
|
|
need to seriously investigate name server traffic.
|
|
`\fB\-s 128\fP'
|
|
has worked well for me.
|
|
|
|
.HD
|
|
SMB/CIFS decoding
|
|
.LP
|
|
\fItcpdump\fP 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.
|
|
|
|
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.
|
|
|
|
If you are decoding SMB sessions containing unicode strings then you
|
|
may wish to set the environment variable USE_UNICODE to 1.
|
|
A patch to
|
|
auto-detect unicode srings would be welcome.
|
|
|
|
For information on SMB packet formats and what all te fields mean see
|
|
www.cifs.org or the pub/samba/specs/ directory on your favourite
|
|
samba.org mirror site.
|
|
The SMB patches were written by Andrew Tridgell
|
|
(tridge@samba.org).
|
|
|
|
.HD
|
|
NFS Requests and Replies
|
|
.LP
|
|
Sun NFS (Network File System) requests and replies are printed as:
|
|
.RS
|
|
.nf
|
|
.sp .5
|
|
\fIsrc.xid > dst.nfs: len op args\fP
|
|
\fIsrc.nfs > dst.xid: reply stat len op results\fP
|
|
.sp .5
|
|
\f(CW
|
|
sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165
|
|
wrl.nfs > sushi.6709: reply ok 40 readlink "../var"
|
|
sushi.201b > wrl.nfs:
|
|
144 lookup fh 9,74/4096.6878 "xcolors"
|
|
wrl.nfs > sushi.201b:
|
|
reply ok 128 lookup fh 9,74/4134.3150
|
|
\fR
|
|
.sp .5
|
|
.fi
|
|
.RE
|
|
In the first line, host \fIsushi\fP sends a transaction with id \fI6709\fP
|
|
to \fIwrl\fP (note that the number following the src host is a
|
|
transaction id, \fInot\fP the source port).
|
|
The request was 112 bytes,
|
|
excluding the UDP and IP headers.
|
|
The operation was a \fIreadlink\fP
|
|
(read symbolic link) on file handle (\fIfh\fP) 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.)
|
|
\fIWrl\fP replies `ok' with the contents of the link.
|
|
.LP
|
|
In the third line, \fIsushi\fP asks \fIwrl\fP to lookup the name
|
|
`\fIxcolors\fP' in directory file 9,74/4096.6878.
|
|
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.
|
|
.LP
|
|
If the \-v (verbose) flag is given, additional information is printed.
|
|
For example:
|
|
.RS
|
|
.nf
|
|
.sp .5
|
|
\f(CW
|
|
sushi.1372a > wrl.nfs:
|
|
148 read fh 21,11/12.195 8192 bytes @ 24576
|
|
wrl.nfs > sushi.1372a:
|
|
reply ok 1472 read REG 100664 ids 417/0 sz 29388
|
|
\fP
|
|
.sp .5
|
|
.fi
|
|
.RE
|
|
(\-v also prints the IP header TTL, ID, length, and fragmentation fields,
|
|
which have been omitted from this example.) In the first line,
|
|
\fIsushi\fP asks \fIwrl\fP to read 8192 bytes from file 21,11/12.195,
|
|
at byte offset 24576.
|
|
\fIWrl\fP 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.
|
|
.LP
|
|
If the \-v flag is given more than once, even more details are printed.
|
|
.LP
|
|
Note that NFS requests are very large and much of the detail won't be printed
|
|
unless \fIsnaplen\fP is increased.
|
|
Try using `\fB\-s 192\fP' to watch
|
|
NFS traffic.
|
|
.LP
|
|
NFS reply packets do not explicitly identify the RPC operation.
|
|
Instead,
|
|
\fItcpdump\fP 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.
|
|
.HD
|
|
AFS Requests and Replies
|
|
.LP
|
|
Transarc AFS (Andrew File System) requests and replies are printed
|
|
as:
|
|
.HD
|
|
.RS
|
|
.nf
|
|
.sp .5
|
|
\fIsrc.sport > dst.dport: rx packet-type\fP
|
|
\fIsrc.sport > dst.dport: rx packet-type service call call-name args\fP
|
|
\fIsrc.sport > dst.dport: rx packet-type service reply call-name args\fP
|
|
.sp .5
|
|
\f(CW
|
|
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
|
|
\fR
|
|
.sp .5
|
|
.fi
|
|
.RE
|
|
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).
|
|
.LP
|
|
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).
|
|
.LP
|
|
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.
|
|
.LP
|
|
If the -v (verbose) flag is given twice, acknowledgement packets and
|
|
additional header information is printed, such as the the RX call ID,
|
|
call number, sequence number, serial number, and the RX packet flags.
|
|
.LP
|
|
If the -v flag is given twice, additional information is printed,
|
|
such as the the RX call ID, serial number, and the RX packet flags.
|
|
The MTU negotiation information is also printed from RX ack packets.
|
|
.LP
|
|
If the -v flag is given three times, the security index and service id
|
|
are printed.
|
|
.LP
|
|
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).
|
|
.LP
|
|
Note that AFS requests are very large and many of the arguments won't
|
|
be printed unless \fIsnaplen\fP is increased.
|
|
Try using `\fB-s 256\fP'
|
|
to watch AFS traffic.
|
|
.LP
|
|
AFS reply packets do not explicitly identify the RPC operation.
|
|
Instead,
|
|
\fItcpdump\fP 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.
|
|
|
|
.HD
|
|
KIP Appletalk (DDP in UDP)
|
|
.LP
|
|
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
|
|
is used to translate appletalk net and node numbers to names.
|
|
Lines in this file have the form
|
|
.RS
|
|
.nf
|
|
.sp .5
|
|
\fInumber name\fP
|
|
|
|
\f(CW1.254 ether
|
|
16.1 icsd-net
|
|
1.254.110 ace\fR
|
|
.sp .5
|
|
.fi
|
|
.RE
|
|
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 \fImust\fP have two octets and a host number \fImust\fP
|
|
have three octets.) The number and name should be separated by
|
|
whitespace (blanks or tabs).
|
|
The
|
|
.I /etc/atalk.names
|
|
file may contain blank lines or comment lines (lines starting with
|
|
a `#').
|
|
.LP
|
|
Appletalk addresses are printed in the form
|
|
.RS
|
|
.nf
|
|
.sp .5
|
|
\fInet.host.port\fP
|
|
|
|
\f(CW144.1.209.2 > icsd-net.112.220
|
|
office.2 > icsd-net.112.220
|
|
jssmag.149.235 > icsd-net.2\fR
|
|
.sp .5
|
|
.fi
|
|
.RE
|
|
(If the
|
|
.I /etc/atalk.names
|
|
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).
|
|
.LP
|
|
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.
|
|
|
|
\fBNBP packets\fP are formatted like the following examples:
|
|
.RS
|
|
.nf
|
|
.sp .5
|
|
\s-2\f(CWicsd-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\fR\s+2
|
|
.sp .5
|
|
.fi
|
|
.RE
|
|
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.
|
|
|
|
\fBATP packet\fP formatting is demonstrated by the following example:
|
|
.RS
|
|
.nf
|
|
.sp .5
|
|
\s-2\f(CWjssmag.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\fR\s+2
|
|
.sp .5
|
|
.fi
|
|
.RE
|
|
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.
|
|
.LP
|
|
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.
|
|
.LP
|
|
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 \fInot\fP set.
|
|
|
|
.HD
|
|
IP Fragmentation
|
|
.LP
|
|
Fragmented Internet datagrams are printed as
|
|
.RS
|
|
.nf
|
|
.sp .5
|
|
\fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB+)\fR
|
|
\fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB)\fR
|
|
.sp .5
|
|
.fi
|
|
.RE
|
|
(The first form indicates there are more fragments.
|
|
The second
|
|
indicates this is the last fragment.)
|
|
.LP
|
|
\fIId\fP is the fragment id.
|
|
\fISize\fP is the fragment
|
|
size (in bytes) excluding the IP header.
|
|
\fIOffset\fP is this
|
|
fragment's offset (in bytes) in the original datagram.
|
|
.LP
|
|
The fragment information is output for each fragment.
|
|
The first
|
|
fragment contains the higher level protocol header and the frag
|
|
info is printed after the protocol info.
|
|
Fragments
|
|
after the first contain no higher level protocol header and the
|
|
frag info is printed after the source and destination addresses.
|
|
For example, here is part of an ftp from arizona.edu to lbl-rtsg.arpa
|
|
over a CSNET connection that doesn't appear to handle 576 byte datagrams:
|
|
.RS
|
|
.nf
|
|
.sp .5
|
|
\s-2\f(CWarizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
|
|
arizona > rtsg: (frag 595a:204@328)
|
|
rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560\fP\s+2
|
|
.sp .5
|
|
.fi
|
|
.RE
|
|
There are a couple of things to note here: First, addresses in the
|
|
2nd line don't include port numbers.
|
|
This is because the TCP
|
|
protocol information is all in the first fragment and we have no idea
|
|
what the port or sequence numbers are when we print the later fragments.
|
|
Second, the tcp sequence information in the first line is printed as if there
|
|
were 308 bytes of user data when, in fact, there are 512 bytes (308 in
|
|
the first frag and 204 in the second).
|
|
If you are looking for holes
|
|
in the sequence space or trying to match up acks
|
|
with packets, this can fool you.
|
|
.LP
|
|
A packet with the IP \fIdon't fragment\fP flag is marked with a
|
|
trailing \fB(DF)\fP.
|
|
.HD
|
|
Timestamps
|
|
.LP
|
|
By default, all output lines are preceded by a timestamp.
|
|
The timestamp
|
|
is the current clock time in the form
|
|
.RS
|
|
.nf
|
|
\fIhh:mm:ss.frac\fP
|
|
.fi
|
|
.RE
|
|
and is as accurate as the kernel's clock.
|
|
The timestamp reflects the time the kernel first saw the packet.
|
|
No attempt
|
|
is made to account for the time lag between when the
|
|
ethernet interface removed the packet from the wire and when the kernel
|
|
serviced the `new packet' interrupt.
|
|
.SH "SEE ALSO"
|
|
bpf(4), pcap(3)
|
|
.SH AUTHORS
|
|
The original authors are:
|
|
.LP
|
|
Van Jacobson,
|
|
Craig Leres and
|
|
Steven McCanne, all of the
|
|
Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
|
|
.LP
|
|
It is currently being maintained by tcpdump.org.
|
|
.LP
|
|
The current version is available via http:
|
|
.LP
|
|
.RS
|
|
.I http://www.tcpdump.org/
|
|
.RE
|
|
.LP
|
|
The original distribution is available via anonymous ftp:
|
|
.LP
|
|
.RS
|
|
.I ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
|
|
.RE
|
|
.LP
|
|
IPv6/IPsec support is added by WIDE/KAME project.
|
|
This program uses Eric Young's SSLeay library, under specific configuration.
|
|
.SH BUGS
|
|
Please send problems, bugs, questions, desirable enhancements, etc. to:
|
|
.LP
|
|
.RS
|
|
tcpdump-workers@tcpdump.org
|
|
.RE
|
|
.LP
|
|
Please send source code contributions, etc. to:
|
|
.LP
|
|
.RS
|
|
patches@tcpdump.org
|
|
.RE
|
|
.LP
|
|
NIT doesn't let you watch your own outbound traffic, BPF will.
|
|
We recommend that you use the latter.
|
|
.LP
|
|
On Linux systems with 2.0[.x] kernels:
|
|
.IP
|
|
packets on the loopback device will be seen twice;
|
|
.IP
|
|
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;
|
|
.IP
|
|
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
|
|
.BR tcpdump ).
|
|
.LP
|
|
We recommend that you upgrade to a 2.2 or later kernel.
|
|
.LP
|
|
Some attempt should be made to reassemble IP fragments or, at least
|
|
to compute the right length for the higher level protocol.
|
|
.LP
|
|
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 \fItcpdump\fP.
|
|
.LP
|
|
A packet trace that crosses a daylight savings time change will give
|
|
skewed time stamps (the time change is ignored).
|
|
.LP
|
|
Filter expressions that manipulate FDDI or Token Ring headers assume
|
|
that all FDDI and Token Ring packets are SNAP-encapsulated Ethernet
|
|
packets.
|
|
This is true for IP, ARP, and DECNET Phase IV, but is not true
|
|
for protocols such as ISO CLNS.
|
|
Therefore, the filter may inadvertently
|
|
accept certain packets that do not properly match the filter expression.
|
|
.LP
|
|
Filter expressions on fields other than those that manipulate Token Ring
|
|
headers will not correctly handle source-routed Token Ring packets.
|
|
.LP
|
|
.BR "ip6 proto"
|
|
should chase header chain, but at this moment it does not.
|
|
.BR "ip6 protochain"
|
|
is supplied for this behavior.
|
|
.LP
|
|
Arithmetic expression against transport layer headers, like \fBtcp[0]\fP,
|
|
does not work against IPv6 packets.
|
|
It only looks at IPv4 packets.
|