tcpdump(8) System Manager's Manual tcpdump(8)
NAME
tcpdump - Dump traffic on a network
SYNOPSIS
/usr/sbin/tcpdump [-deflmnNOpqStvx] [-c count] [-Ffile]
[-iinterface] [-rfile] [-ssnaplen]
[-wfile] expression
FLAGS
Exits after receiving count packets. Dumps the compiled packet-match-
ing 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 in-
terface. 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 decod-
ing, 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 flag, 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). Stan-
dard 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). Pack-
ets 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 ver-
bose output. For example, additional fields are printed from NFS reply
packets. Writes the raw packets to file rather than parsing and print-
ing them. They can later be printed with the -r option. Standard out-
put is used if a hyphen (-) is used to specify file. Prints each
packet (minus its link level header) in hex. The smaller of the entire
packet or snaplen bytes is printed. Selects the packets to dump. If
no expression is given, all packets on the network are dumped. Other-
wise, 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, 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 speci-
fied, 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 speci-
fied 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 con-
tain other fields, but you cannot name them explicitly in a fil-
ter 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 de-
scribed 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 do-
main 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 ei-
ther 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 equiv-
alent: 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.
Ehost may be either a name from /etc/ethers or a number (see
ethers(3) for numeric format). True if the Ethernet source ad-
dress is ehost. True if either the Ethernet source or destina-
tion address is ehost. True if the packet used host as a gate-
way. 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. True if the IP destination address of the packet has a
network number of net, which may be either an address or a name.
True if the IP source address of the packet has a network number
of net. 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 proto-
col 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 ei-
ther 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 pro-
tocol type protocol. Protocol can be a number or one of the
names icmp, 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 Eth-
ernet broadcast packet. The ether keyword is optional. 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'. True if the packet is an IP multicast
packet. True if the packet is of ether type protocol. The pro-
tocol argument can be a number or a name like ip, 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 DECnet source address is host, which may be an ad-
dress of the form ``10.123'', or a DECnet host name. (DECnet
host name support is only available on systems that are config-
ured 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 tcp-
dump utility does not currently know how to parse these proto-
cols. Abbreviations for: ip proto p Where p is one of the pro-
tocols 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 opera-
tor, 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 opera-
tion. The byte offset, relative to the indicated protocol
layer, is given by expr. The size variable is optional and in-
dicates the number of bytes in the field of interest; it can be
either one, two, or four, and defaults to one. The length oper-
ator, 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 un-
fragmented datagrams and frag zero of fragmented datagrams.
This check is implicitly applied to the tcp and udp index opera-
tions. 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 prim-
itives and operators (parentheses are special to the Shell and
must be escaped). Negation (! or not) Concatenation (and) Al-
ternation (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 con-
catenation.
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 ) Expres-
sion arguments can be passed to tcpdump as either a single argu-
ment 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 ar-
guments are concatenated with spaces before being parsed.
DESCRIPTION
The tcpdump utility prints out the headers of packets on a network in-
terface that match the boolean expression. Your kernel must be config-
ured with the packetfilter option. (See packetfilter(7).) After kernel
configuration, any user can invoke tcpdump once the superuser has en-
abled promiscuous-mode operation using pfconfig(8).
RESTRICTIONS
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) ques-
tion 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.
EXAMPLES
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 com-
plex expressions, you can enclose expressions in single quotation marks
(` ') to prevent the shell from processing special characters. For ex-
ample, 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 ftp-data)' 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'
OUTPUT FORMAT
The output of the tcpdump utility is protocol dependent. The following
sections describe most of the formats and provide examples.
Link Level Headers
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 Log-
ical 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 com-
pression algorithm described in RFC 1144.
On SLIP links, a direction indicator (``I'' for inbound, ``O'' for out-
bound), 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 spe-
cial cases are printed as *S+n and *SA+n, where n is the amount by
which the sequence number (or sequence number and acknowledgement) 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
(acknowledgement), 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 acknowledgement 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 point-to-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
The following description assumes familiarity with the TCP protocol de-
scribed in RFC 793.
The general format of a TCP protocol line is: src > dst: flags data-se-
qno 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 cov-
ered by the data in this packet (see the following example). The se-
quence 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-segment-size 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 be-
tween 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
flag 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
The UDP format is illustrated by the following rwho packet: ac-
tinide.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 particu-
lar, Domain Name service requests (RFC 1034 and RFC 1035) and Sun RPC
calls (RFC 1050) to NFS.
UDP Name Server Requests
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.
A following anomalies are checked and may result in extra fields en-
closed 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 re-
sponse 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
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 authori-
tative 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 (-) (recur-
sion 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 flag to increase the snaplen if you need
to seriously investigate name server traffic.
Sun RPC Requests and Replies
Sun RPC (RFC 1057) is decoded, as are several of the protocols that use
Sun RPC, listed in the following table: tab(@); lfHB lfHB lfHB l lfCW l
. _
Name@Users@Description
_
[email protected], portmap@Maps RPC program numbers to TCP/UDP ports
MOUNT@mount, mountd@Maps file names to NFS file handles
[email protected]@NFS remote file locking
[email protected], rpc.lockd@Remote status monitor
[email protected], 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 re-
sults 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 informa-
tion 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 re-
ply 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.mount-v1: 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 re-
ply 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 .x file.
If the -v (verbose) flag is given, additional information is printed.
If the -v flag 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 For exam-
ple: alpha1.zk3.dec.com.da31fba5 > alpha2.zk3.dec.com.proplist-v3: 276
call \ proproc3_get OSF/1 fh 8,18434/1.4 mask:-1 11 entries
alpha2.zk3.dec.com.da31fba5 > alpha1.zk3.dec.com.proplist-v3: 296 reply
\ proproc3_get status OK 368 bytes 11 entries
For property list calls, you can request the mask value (see the refer-
ence 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. In-
stead, 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)
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 Ap-
pleTalk 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 ex-
ist 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 con-
tents 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 re-
ply to the same request indicating host techpit has laserwriter techpit
registered on port 186.
ATP packet formatting is demonstrated by the following example: jss-
mag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001 helios.132 >
jssmag.209.165: atp-resp 12266:0 (512) 0xae040000 helios.132 > jss-
mag.209.165: atp-resp 12266:1 (512) 0xae040000 helios.132 > jss-
mag.209.165: atp-resp 12266:2 (512) 0xae040000 helios.132 > jss-
mag.209.165: atp-resp 12266:3 (512) 0xae040000 helios.132 > jss-
mag.209.165: atp-resp 12266:4 (512) 0xae040000 helios.132 > jss-
mag.209.165: atp-resp 12266:5 (512) 0xae040000 helios.132 > jss-
mag.209.165: atp-resp 12266:6 (512) 0xae040000 helios.132 > jss-
mag.209.165: atp-resp*12266:7 (512) 0xae040000 jssmag.209.165 > he-
lios.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 Host jssmag.209 initiates transaction ID 12266 with host he-
lios 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, ex-
cluding 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. Fi-
nally, 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
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 frag-
ment contains the higher level protocol header and the fragment infor-
mation is printed after the protocol information. Fragments after the
first contain no higher level protocol header and the fragment informa-
tion is printed after the source and destination addresses. The fol-
lowing 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 be-
cause 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
By default, all output lines are preceded by a timestamp. The time-
stamp 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.
RELATED INFORMATION
Commands: nfswatch(8), pfstat(1), pfconfig(8), tcpslice(8)
Files: packetfilter(7), bpf(7) delim off
tcpdump(8)