tcpdump - Dump traffic on a network
/usr/sbin/tcpdump [-deflmnNOpqStvxX] [-c count] [-Ffile]
[-iinterface] [-rfile] [-ssnaplen] [-wfile] expression
Exits after receiving count packets. Dumps the compiled
packet-matching code to standard output and stop. Prints
the link-level header on each dump line. Prints "foreign"
internet addresses numerically rather than symbolically.
Uses file as input for the filter expression. Any additional
expressions on the command line are ignored. Listens
on interface. If unspecified, tcpdump searches the
system interface list for the lowest numbered, configured
up interface (excluding loopback). Ties are broken by
choosing the earliest match. Makes stdout line buffered.
This is useful if you want to see the data while capturing
it. Enables multiline output from some protocols. This
affects most Sun RPC decoding, as those protocols are
often difficult to display on a single line. Does not
convert addresses (for example, host addresses and port
numbers) to names. Does not print domain name qualification
of host names. For example, with the -N option, tcpdump
prints nic instead of nic.ddn.mil. Does not run the
packet-matching code optimizer. This is useful only if
you suspect a bug in the optimizer. Does not put the
interface into promiscuous mode. Note the interface might
be in promiscuous mode for some other reason; therefore,
-p cannot be used as an abbreviation for ether host
{localhost} or broadcast. Quick (quiet) output. Prints
less protocol information so output lines are shorter.
Reads packets from file (which was created with the -w
option). Standard input is used if a hyphen (-) is used
to specify file. Displays snaplen bytes of data from each
packet rather than the default of 68 (with NIT, the minimum
is 96). The default of 68 bytes is adequate for IP,
ICMP, TCP, and UDP, but may truncate protocol information
from name server and NFS packets (discussed later in this
reference page). Packets truncated because of a limited
snapshot are indicated in the output with "[|proto]",
where proto is the name of the protocol level at which the
truncation has occurred.
Note
Taking larger snapshots both increases the amount
of time it takes to process packets and decreases
the amount of packet buffering. This may cause
packets to be lost. You should limit snaplen to
the smallest number that will capture the needed
protocol information. Prints absolute, rather than
relative, TCP sequence numbers. Does not print a
timestamp on each dump line. Prints an unformatted
timestamp on each dump line. Prints slightly more
verbose output. For example, the time to live and
type of service information in an IP packet is
printed. If -m is also specified, Sun RPC packets
sent using TCP are decoded twice: first as RPC,
then as TCP. Normally the TCP decoding is
suppressed. Prints even more verbose output. For
example, additional fields are printed from NFS
reply packets. Writes the raw packets to file
rather than parsing and printing them. They can
later be printed with the -r option. Standard output
is used if a hyphen (-) is used to specify
file. Prints each packet (minus its link level
header) in hexadecimal format. The smaller of the
entire packet or snaplen bytes is printed. Prints
packets in both hexadecimal and ASCII formats.
Selects the packets to dump. If no expression is
given, all packets on the network are dumped. Otherwise,
only packets for which expression is "true"
are dumped.
The expression consists of one or more primitives.
Primitives usually consist of an id (name or number)
preceded by one or more of the following qualifiers:
Defines the object to which the id name or
number refers. The following types are allowed:
host, net, and port. For example:
host foo net 128.3 port 20
If no type qualifier is specified, host is the
default. Specifies a particular transfer direction
to or from id. The following directions are
allowed: src, dst, src or dst, and src and dst. For
example:
src foo dst net 128.3 src or dst port 20 src and
dst port 123
If no dir qualifier is specified, src or dst is the
default. Restricts the match to a particular protocol.
The following protocols are allowed: ether,
fddi, ip, ipv6, icmpv6, arp, rarp, decnet, lat,
moprc, mopdl, tcp, and udp. For example:
ether src foo arp net 128.3 tcp port 21
If no proto qualifier is specified, all protocols
consistent with the type are assumed. For example,
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, port 53 means (tcp or udp)
port 53.
The fddi argument is 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.
In addition to the above, there are some special "primitive"
keywords that do not follow the pattern: gateway,
broadcast, less, greater, and arithmetic expressions. All
of these are described later in this reference page.
More complex filter expressions are built up by using the
words and, or, and not to combine primitives. For example:
host foo and not port ftp and not port ftp-data
To save typing, identical qualifier lists can be omitted.
For example, the following two lines are treated the same:
tcp dst port ftp or ftp-data or domain tcp dst port ftp or
tcp dst port ftp-data or tcp dst port domain
Allowable primitives are: True if the IP destination field
of the packet is host, which may be either an address or a
name. True if the IP source field of the packet is host.
True if either the IP source or destination of the packet
is host. The following keywords can precede any of these
host expressions: ip, arp, or rarp. For example, the following
examples are equivalent:
ip host host ether proto ip and host host
If host is a name with multiple IP addresses, each
address is checked for a match. True if the Ethernet
destination address is ehost. The ehost may be
either a name from /etc/ethers or a number (see
ethers(3) for numeric format). True if the Ethernet
source address is ehost. True if either the
Ethernet source or destination address is ehost.
True if the packet used host as a gateway. That
is, the Ethernet source or destination address was
host but neither the IP source nor the IP destination
was host. The host argument must be a name
and must be found in both /etc/hosts and
/etc/ethers.
The following expression is equivalent:
ether host ehost and not host host
You can use either names or numbers for host and
ehost. [IPv4 networks only] True if the IP destination
address of the packet has a network number
of net, which may be either an address or a name.
[IPv4 networks only] True if the IP source address
of the packet has a network number of net. [IPv4
networks only] True if either the IP source or
destination address of the packet has a network
number of net. True if the packet is IP/TCP or
IP/UDP and has a destination port value of port.
The port can be a number or a name used in
/etc/services (see tcp(7) and udp(7)). 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. (For example, dst
port 513 prints both TCP login service traffic and
UDP who service traffic, and port domain prints
both TCP/DOMAIN and UDP/DOMAIN traffic). True if
the packet has a source port value of port. True
if either the source or destination port of the
packet is port. The following keywords can precede
any of these port expressions: tcp or udp. For
example, the following example matches only TCP
packets.
tcp src port port True if the packet has a length
less than or equal to length. The following example
is equivalent:
len <= length True if the packet has a length
greater than or equal to length. The following
example is equivalent:
len >= length. True if the packet is an IP packet
(see ip(7)) of protocol type protocol. The protocol
can be a number or one of the names ipv6, icmp,
icmpv6, udp, nd, or tcp.
Note
The identifiers tcp, udp, and icmp are also keywords
and must be escaped via backslash (\), which
is \\ in the C-shell. True if the packet is an
Ethernet broadcast packet. The ether keyword is
optional. [IPv4 networks only] 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. True if the packet
is an Ethernet multicast packet. The ether keyword
is optional. This is shorthand for `ether[0] & 1 !=
0'. [IPv4 networks only] True if the packet is an
IPv4 multicast packet. True if the packet is of
ether type protocol. The protocol argument can be a
number or a name like ip, ipv6, arp, or rarp. Note
these identifiers are also keywords and must be
escaped via backslash (\). (In the case of FDDI
(for example, fddi protocol arp), the protocol
identification comes from the 802.2 Logical Link
Control (LLC) header, which is usually layered on
top of the FDDI header. The tcpdump utility
assumes, when filtering on the protocol identifier,
that all FDDI packets include an LLC header, and
that the LLC header is in so-called SNAP format.)
True if the packet is an IEEE 802.1Q VLAN (tagged)
packet. If vlan-id is specified, only packets from
that particular VLAN will match. Every part of the
tcpdump expression that is evaluated before the
first vlan keyword catches either tagged or
untagged packets. Every part of the tcpdump expression
that is evaluated after the first vlan keyword
catches only tagged packets.
For example, the expression arp catches both tagged
ARP packets and untagged ARP packets. The expression
arp or vlan 1001 catches tagged ARP packets,
untagged ARP packets, and VLAN 1001 packets. However,
the expression vlan 1001 or arp catches only
VLAN 1001 packets and tagged ARP packets. True if
the DECnet source address is host, which may be an
address of the form "10.123", or a DECnet host
name. (DECnet host name support is only available
on systems that are configured to run DECnet.)
True if the DECnet destination address is host.
True if either the DECnet source or destination
address is host. Abbreviations for:
ether proto p
Where p is one of the above protocols. Abbreviations
for:
ether proto p
Where p is one of the above protocols.
Note
The tcpdump utility does not currently know how to
parse these protocols. Abbreviations for:
ip proto p
Where p is one of the protocols listed earlier.
True if the relation holds, where relop is >, <,
>=, <=, =, or !=, and expr 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: proto [expr :
size]
The proto variable is one of ether, fddi, ip, arp,
rarp, tcp, udp, or icmp, and indicates the protocol
layer for the index operation. The byte offset,
relative to the indicated protocol layer, is given
by expr. The size variable 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
len, gives the length of the packet.
For example, `ether[0] & 1 != 0' catches all multicast
traffic. The expression `ip[0] & 0xf != 5'
catches all IP packets with options. The expression
`ip[2:2] & 0x1fff = 0' catches only unfragmented
datagrams and frag zero of fragmented datagrams.
This check is implicitly applied to the tcp and udp
index operations. For instance, tcp[0] always means
the first byte of the TCP header, and never means
the first byte of an intervening fragment.
Primitives may be combined using: A parenthesized group of
primitives and operators (parentheses are special to the
Shell and must be escaped). Negation (! or not) Concatenation
(and) Alternation (or)
Negation has highest precedence. Alternation and concatenation
have equal precedence and associate left to right.
Note that explicit and tokens (not juxtaposition) are
required for concatenation.
If an identifier is given without a keyword, the most
recent keyword is assumed. For example, the following two
examples are equivalent:
not host vs and ace
not host vs and host ace
However, the following example is not equivalent to the
previous two:
not ( host vs or ace )
Expression arguments can be passed to tcpdump 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.
The tcpdump utility prints out the headers of packets on a
network interface that match the boolean expression.
Decoding of tftp options complies with RFC 1782 (see the
tftpd(8) and tftp(1) reference pages). Your kernel must be
configured with the packetfilter option. (See packetfilter(7).) After kernel configuration, any user can invoke
tcpdump once the superuser has enabled promiscuous-mode
operation using pfconfig(8).
The output of the tcpdump utility is protocol dependent.
The following sections describe most of the formats and
provide examples.
Link Level Headers [Toc] [Back]
The -e option is used to print the link level header. On
Ethernets, the source and destination addresses, protocol,
and packet length are printed.
On FDDI networks, the -e option causes the tcpdump utility
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, async4. Such packets are assumed to
contain an 802.2 Logical Link Control (LLC) packet; the
LLC header is printed if it is not an ISO datagram or a
so-called SNAP packet.
Note
The following description assumes familiarity with the
SLIP compression algorithm described in RFC 1144.
On SLIP links, a direction indicator ("I" for inbound, "O"
for outbound), packet type, and compression information
are printed.
The packet type is printed first. The three types of packets
are ip, utcp, and ctcp. No further link information
is printed for ip packets.
For TCP packets, the connection identifier is printed
after the type. If the packet is compressed, its encoded
header is printed. The special cases are printed as *S+n
and *SA+n, where n is the amount by which the sequence
number (or sequence number and acknowledgment) 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 (acknowledgment), 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.
The following example shows an outbound compressed TCP
packet, with an implicit connection identifier; the value
of the acknowledgment 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:
O ctcp * A+6 S+49 I+6 3 (6)
ARP/RARP Packets
ARP and RARP output shows the type of request and its
arguments. The format is intended to be self explanatory.
The following example is taken from the start of an rlogin
from host rtsg to host csam:
arp who-has csam tell rtsg arp reply csam is-at CSAM
The first line indicates that host rtsg sent an ARP packet
asking for the Ethernet address of Internet host csam.
Host csam replies with its Ethernet address (in this example,
Ethernet addresses are uppercase and Internet
addresses in lowercase).
This would look less redundant if we had done tcpdump -n:
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
If you issue the tcpdump -e command, the first packet is
explicitly a broadcast packet and the second is a pointto-point
packet:
RTSG Broadcast 0806 64: arp who-has csam tell rtsg CSAM
RTSG 0806 64: arp reply csam is-at CSAM
For the first packet, the Ethernet source address is RTSG,
the destination is the broadcast address, the type field
contain hex 0806 (type ETHER_ARP) and the total length is
64 bytes.
TCP Packets [Toc] [Back]
The following description assumes familiarity with the TCP
protocol described in RFC 793.
The general format of a TCP protocol line is:
src > dst: flags data-seqno ack window urgent options
The fields represent the following: The destination IP
addresses and ports. The destination IP addresses and
ports. The sum combination of S (SYN), F (FIN), P (PUSH)
or R (RST) or a single period (.) for no flags. The portion
of sequence space covered by the data in this packet
(see the following example). The sequence number of the
next data expected from the other direction on this connection.
The number of bytes of receive buffer space
available from the other direction on this connection.
Indicates there is urgent data in the packet. The TCP
options enclosed in angle brackets. For example,
<mss 1024>
The src, dst, and flags fields are always present. The
other fields depend on the contents of the packet's TCP
protocol header and are output only if appropriate.
The following example shows the opening portion of an
rlogin session from host rtsg to host csam:
rtsg.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
The first line indicates that TCP port 1023 on system rtsg
sent a packet to port login on host csam. The S indicates
that the SYN flag was set. The packet sequence number was
768512 and it contained no data. (The notation is
first:last(nbytes) which means sequence numbers first up
to but not including last which is nbytes bytes of user
data.) There was no piggy-backed ack, the available
receive window was 4096 bytes and there was a max-segmentsize
option requesting an mss of 1024 bytes.
Host csam replies with a similar packet except it includes
a piggy-backed ack for the SYN sent by rtsg. Host rtsg
then sends an ack reply to the SYN sent by csam. The
period (.) 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 tcpdump 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). The -S option overrides this feature,
causing the original sequence numbers to be output.
The sixth line indicates that host rtsg sends host csam 19
bytes of data (bytes 2 through 20 in the rtsg to csam side
of the conversation). The PUSH flag is set in the packet.
The seventh line indicates that host csam has received
data sent by host rtsg up to but not including byte 21.
Most of this data is apparently sitting in the socket
buffer because the receive window on host csam is 19
bytes smaller. Host csam also sends one byte of data to
host rtsg in this packet. The eighth and ninth lines show
that host csam sends two bytes of urgent, pushed data to
rtsg.
UDP Packets [Toc] [Back]
The UDP format is illustrated by the following rwho
packet:
actinide.who > broadcast.who: udp 84
This line of output indicates that port who on host
actinide sent a UDP datagram to port who on host broadcast,
the Internet broadcast address. The packet contained
84 bytes of user data.
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 and RFC 1035) and Sun RPC calls (RFC
1050) to NFS.
UDP Name Server Requests [Toc] [Back]
The following description assumes familiarity with the
Domain Service protocol described in RFC 1035.
Name server requests are formatted as follows:
src > dst: id op? flags qtype qclass name (len)
For example:
h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu.
(37)
Host h2opolo queried the domain server on host helios for
an address record (qtype=A) associated with the name ucbvax.berkeley.edu.
The query ID was 3. The plus sign (+)
indicates the recursion desired flag was set. The query
length was 37 bytes, not including the UDP and IP protocol
headers. The query operation was the normal one, Query,
so the op field was omitted. If the op field had been
anything else, it would have been printed between the 3
and the plus sign (+). Similarly, the qclass was the normal
one, C_IN, and omitted. Any other qclass would have
been printed immediately after the A.
The following anomalies are checked and may result in
extra fields enclosed in square brackets: If a query contains
an answer, name server or authority section,
ancount, nscount, or arcount are printed as [na], [nn] or
[nau] where n 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 and 3, [b2&3=x] is
printed, where x is the hex value of header bytes 2 and 3.
UDP Name Server Responses [Toc] [Back]
Name server responses are formatted as follows:
src > dst: id op rcode flags a/n/au type class data (len)
For example:
helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)
In the first example, host helios responds to query ID 3
from host h2opolo with 3 answer records, 3 name server
records, and 7 authority 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 is 273
bytes, excluding UDP and IP headers. The op (Query) and
response code (NoError) are omitted, as is the class
(C_IN) of the A record.
In the second example, host helios responds to query 2
with a response code of nonexistent domain (NXDomain) with
no answers, one name server and no authority records. The
asterisk (*) indicates that the authoritative answer bit
is set. Since there are no answers, no type, class or
data are printed.
Other flag characters that might appear are the minus sign
(-) (recursion available, RA, not set) and vertical bar
(|) (truncated message, TC, set). If the `question' section
doesn't contain exactly one entry, [nq] is printed.
Note that name server requests and responses tend to be
large, and the default value of snaplen, 96 bytes, may
not capture enough of the packet to print. Use the -s
option to increase the snaplen if you need to seriously
investigate name server traffic.
TFTP Packets [Toc] [Back]
Only the initial Trivial File Transfer Protocol (TFTP)
connection requests and client side options, if present,
are decoded and printed as described in RFC 1782.
Sun RPC Requests and Replies [Toc] [Back]
Sun RPC (RFC 1057) is decoded, as are several of the protocols
that use Sun RPC, listed in the following table:
---------------------------------------------------------
Name Users Description
---------------------------------------------------------
PORTMAP libc.a, portmap Maps RPC program numbers
to TCP/UDP ports
MOUNT mount, mountd Maps file names to NFS
file handles
NLM rpc.lockd NFS remote file locking
STAT rpc.statd, rpc.lockd Remote status monitor
YP libc.a, ypserv Network Information
Services
YPBIND ypbind, ypset NIS domain manipulation
NFS UNIX Network File System
---------------------------------------------------------
Requests sent using TCP must start at the beginning of a
packet to be decoded. Normally they are; however, applications
that have multiple requests outstanding (for example,
NFS) may not always do this.
Replies can only be decoded if the request was found and
only if they start a packet.
The general form of a RPC request and reply is as follows:
src.xid > dst.prot-v#: len call op args src.xid >
dst.prot-v#: len reply op results
For example, NFS mounting a file system generates:
clnt.312dbc68 > svc.pmap-v2: 56 call getport prog "nfs"
V3 prot UDP port 0 svc.312dbc68 > clnt.pmap-v2: 28 reply
getport 2049 clnt.312deff8 > svc.pmap-v2: 56 call getport
prog "mount" V3 prot UDP port 0 svc.312deff8 >
clnt.pmap-v2: 28 reply getport 1034 clnt.312deff8 >
svc.mount-v3: 124 call mount "/build" svc.312deff8 >
clnt.mount-v3: 68 reply mount OSF/1 fh 8,3079/1.2
clnt.907312 > svc.nfs-v3: 148 call getattr OSF/1 fh
8,3079/1.2 svc.907312 > clnt.nfs-v3: 112 reply getattr
{dir size 1024 mtime ... }
In general, the UDP or TCP protocol information is not
printed. This is generally not important for UDP; however,
it can be for TCP. If the -m and -v options are in
effect, both RPC and TCP decoding are done. For example,
a showmount -e srv command generates information such as
the following:
clnt.3123f473 > svc.pmap-v2: 56 call getport prog "mount"
V1 prot TCP port 0
(ttl 29, id 19672) svc.3123f473 >
clnt.pmap-v2: 28 reply getport 892
(ttl 30, id 31644) clnt.1032 > svc.892: S
25280000:25280000(0) win 32768 <mss 1460,nop,wscale 0>
(DF) (ttl 59, id 19674) svc.892 >
clnt.1032: S 483136000:483136000(0) ack 25280001 win 33580
<mss 1460,nop,wscale 0> (ttl 60, id
31645) clnt.1032 > svc.892: . ack 1 win 33580 (DF) (ttl
59, id 19675) clnt.2f221c23 > svc.mount-v1: 40 call return
export list TCP: clnt.1032 > svc.892: P 1:45(44) ack 1 win
33580 (DF) (ttl 59, id 19676) svc.2f221c23 > clnt.mountv1:
184 reply export
"/usr": "client" "clnt"
"/build":
... TCP: svc.892 > clnt.1032: P 1:189(188) ack 45
win 33580 (ttl 60, id 31648) clnt.1032 > svc.892: F
45:45(0) ack 189 win 33580 (DF) (ttl 59, id 19679) svc.892
> clnt.1032: . ack 46 win 33580 (ttl 60, id 31649) svc.892
> clnt.1032: F 189:189(0) ack 46 win 33580 (ttl 60, id
31650) clnt.1032 > svc.892: . ack 190 win 33580 (DF) (ttl
59, id 19681)
The following is another NFS sample:
sushi.6709 > wrl.nfs-v2: 112 call readlink fh
21,24/10.731657119 wrl.6709 > sushi.nfs-v2: 40 reply readlink
"../var" sushi.201b > wrl.nfs-v2: 144 call lookup fh
9,74/4096.6878 "xcolors" wrl.201b > sushi.nfs-v2: 128
reply lookup fh 9,74/4134.3150
In the first line, host sushi sends a transaction with ID
6709 to host wrl (the number following the src host is a
transaction ID, not the source port). The request was 112
bytes, excluding the UDP and IP headers. The operation
was a readlink (read symbolic link) on file handle (fh)
21,24/10.731657119. (In some cases, the file handle can
be interpreted as a major and minor device number pair,
followed by the inode number and generation number.) Host
wrl replies ok with the contents of the link.
In the third line, host sushi asks host wrl to look up the
name xcolors 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 a protocol specification rpcgen file.
If the -v (verbose) option is given, additional information
is printed.
If the -v option is given more than once, more details may
be printed.
Note that RPC requests are very large and much of the
detail is not printed. Property list information may also
be obtained using tcpdump. For example:
alpha1.zk3.dec.com.da31fba5 > alpha2.zk3.dec.com.proplistv3:
\
276 call proproc3_get OSF/1 fh 8,18434/1.4 mask:-1 11
entries
alpha2.zk3.dec.com.da31fba5 > alpha1.zk3.dec.com.proplistv3:
\
296 reply proproc3_get status OK 368 bytes 11 entries
For property list calls, you can request the mask value
(see the setproplist(3) reference page) and the number of
property list entries. Property list replies return the
status, the number of bytes in the property list and the
number of entries in property list.
Note that NFS requests are very large and much of the
detail is not printed unless the value of snaplen is
increased. Try using -s 192 to watch RPC traffic.
RPC reply packets do not explicitly identify the RPC operation.
Instead, tcpdump 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.
NFS and Sun are registered trademarks of Sun Microsystems,
Inc.
KIP AppleTalk (DDP in UDP) [Toc] [Back]
AppleTalk DDP packets encapsulated in UDP datagrams are
de-encapsulated and dumped as DDP packets (for example,
all the UDP header information is discarded). The file
/etc/atalk.names is used to translate AppleTalk network
numbers and node numbers to names. Lines in this file have
the following form:
number name
For example:
1.254 ether
16.1 icsd-net
1.254.110 ace
The first two lines provide the names of AppleTalk networks.
The third line provides the name of a particular
host (a host is distinguished from a network by the third
octet in the number. (A network number must have two
octets and a host number must have three octets.) The
number and name are separated by either blanks or tabs.
The /etc/atalk.names file may contain blank lines or comment
lines (lines starting with a pound sign (#)).
AppleTalk addresses are printed in the following form:
net.host.port
For example:
144.1.209.2 > icsd-net.112.220 office.2 > icsd-net.112.220
jssmag.149.235 > icsd-net.2
(If the /etc/atalk.names file does not exist or does not
contain an entry for some AppleTalk host or network number,
addresses are printed in numeric form.)
In the first example, the name binding protocol (NBP) (DDP
port 2) on network 144.1 node 209 sends to whatever is
listening on port 220 of network icsd node 112. The second
line is the same except the full name of the source node
is known (office). The third line sends from port 235 on
network jssmag node 149 to broadcast on the icsd-net NBP
port. (Note that the broadcast address (255) is indicated
by a network name with no host number. For this reason it
is a good idea to keep node names and network names distinct
in /etc/atalk.names).
NBP and ATP (AppleTalk transaction protocol) packets have
their contents interpreted. Other protocols dump the protocol
name (or number if no name is registered for the
protocol) and packet size.
NBP packets are formatted as shown in the following examples:
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
The first line shows a name lookup request for laserwriters
sent by network host icsd 112 and broadcast on network
jssmag. The NBP ID for the lookup is 190. The second line
shows a reply to this request (it has the same ID) from
host jssmag.209 indicating that it has a laserwriter
resource named RM1140 registered on port 250. The third
line shows another reply to the same request indicating
host techpit has laserwriter techpit registered on port
186.
ATP packet formatting is demonstrated by the following
example:
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: atpresp
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: atpresp
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
Host jssmag.209 initiates transaction ID 12266 with host
helios by requesting up to eight packets (0-7). The hex
number at the end of the line is the value of the userdata
field in the request.
Host helios responds with eight 512-byte packets. The
:digit following the transaction ID gives the packet
sequence number in the transaction and the number in
parenthesis is the amount of data in the packet, excluding
the ATP header. The asterisk (*) on packet 7 indicates
that the EOM bit was set.
Host jssmag.209 then requests that packets 3 and 5 be
retransmitted. Host helios resends them, then jssmag.209
releases the transaction. Finally, jssmag.209 initiates
the next request. The asterisk (*) on the request indicates
that exactly once (XO) was not set.
AppleTalk is a registered trademark of Apple Computer,
Inc.
IP Fragmentation [Toc] [Back]
Fragmented Internet datagrams are printed as follows:
(frag id:size@offset+) (frag id:size@offset)
The first line indicates there are more fragments. The
second indicates this is the last fragment.
The following list explains the fields: The fragment ID
The fragment size (in bytes) excluding the IP header The
fragment's offset (in bytes) in the original datagram
The fragment information is output for each fragment. The
first fragment contains the higher level protocol header
and the fragment information is printed after the protocol
information. Fragments after the first contain no higher
level protocol header and the fragment information is
printed after the source and destination addresses. The
following example shows part of an FTP session from arizona.edu
to lbl-rtsg.arpa over a CSNET connection that
does not appear to handle 576 byte datagrams:
arizona.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
Note the following: Addresses in the second line do not
include port numbers. This is because the TCP protocol
information is in the first fragment and we do not know
what the port or sequence numbers are when we print the
later fragments. TCP sequence information in the first
line is printed as if there were 308 bytes of user data;
however, there are 512 bytes (308 in the first fragment
and 204 in the second). If you are looking for holes in
the sequence space or trying to match up acknowledgements
with packets, this can be misleading.
A packet with the IP `do not fragment' flag is
marked with a trailing (DF).
Timestamps [Toc] [Back]
By default, all output lines are preceded by a timestamp.
The timestamp is the current clock time in the following
form:
hh:mm:ss.frac
It 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 difference between
when the Ethernet interface removed the packet from the
wire and when the kernel serviced the new packet interrupt.
To watch either outbound or inbound traffic, you need to
have enabled copyall mode using the pfconfig command. For
example, pfconfig +c ln0.
Name server inverse queries are not dumped correctly: The
(empty) question section is printed rather than real query
in the answer section.
A packet trace that crosses a daylight saving time change
produces skewed time stamps (the time change is ignored).
Filter expressions that manipulate FDDI headers assume
that all FDDI packets are 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.
To print all packets arriving at or departing from sundown:
tcpdump host sundown To print traffic between helios
and either hot or ace: tcpdump host helios and \( hot or
ace \)
Note that to ease typing complex expressions, you
can enclose expressions in single quotation marks
(` ') to prevent the shell from processing special
characters. For example, the previous example
could be entered as follows: tcpdump `host helios
and ( hot or ace )' To print all IP packets between
ace and any host except helios: tcpdump ip host ace
and not helios To print all traffic between local
hosts and hosts at Berkeley: tcpdump net ucb-ether
To print all FTP traffic through Internet gateway
snup: tcpdump 'gateway snup and (port ftp or ftpdata)'
To print traffic neither sourced from nor
destined for local hosts (if your network is connected
to one other network by a gateway, the following
does not produce any results on your local
network): tcpdump ip and not net localnet To print
the start and end packets (the SYN and FIN packets)
of each TCP conversation that involves a nonlocal
host: tcpdump 'tcp[13] & 3 != 0 and not src and dst
net localnet' To print IP packets longer than 576
bytes sent through gateway snup: tcpdump 'gateway
snup and ip[2:2] > 576' To print IP broadcast or
multicast packets that were not sent via Ethernet
broadcast or multicast: tcpdump 'ether[0] & 1 = 0
and ip[16] >= 224' To print all ICMP packets that
are not echo requests or replies (that is, not ping
packets): tcpdump 'icmp[0] != 8 and icmp[0] != 0'
To print all RIPv6 packets, enter: tcpdump -i ln0
-s 1500 -envv ipv6 and udp port 521 To print all
IPv6 packets arriving at or departing from a host
with the Ethernet address a:b:c:d:e:f, enter: tcpdump
-i ln0 -s 1500 -envv ipv6 and ether host
a:b:c:d:e:f
Commands: pfstat(1), nfswatch(8), pfconfig(8), tcpslice(8)
Files: bpf(7), packetfilter(7)
RFC 1782, TFTP Option Extension, Harkin A., Malkin, G.
RFC 2080, RIPng for IPv6, Malkin, G., Minnear, R.
tcpdump(8)
[ Back ] |
