 |
Index for
Section 8 |
|
 |
Alphabetical
listing for T |
|
 |
Bottom of
page |
|
tcpdump(8)
NAME
tcpdump - Dump traffic on a network
SYNOPSIS
/usr/sbin/tcpdump [-deflmnNOpqStvxX] [-c count] [-Ffile] [-iinterface]
[-rfile] [-ssnaplen] [-wfile] expression
OPTIONS
-c Exits after receiving count packets.
-d Dumps the compiled packet-matching code to standard output and stop.
-e Prints the link-level header on each dump line.
-f Prints "foreign" internet addresses numerically rather than
symbolically.
-F file
Uses file as input for the filter expression. Any additional
expressions on the command line are ignored.
-i interface
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.
-l Makes stdout line buffered. This is useful if you want to see the data
while capturing it.
-m Enables multiline output from some protocols. This affects most Sun
RPC decoding, as those protocols are often difficult to display on a
single line.
-n Does not convert addresses (for example, host addresses and port
numbers) to names.
-N Does not print domain name qualification of host names. For example,
with the -N option, tcpdump prints nic instead of nic.ddn.mil.
-O Does not run the packet-matching code optimizer. This is useful only
if you suspect a bug in the optimizer.
-p 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.
-q Quick (quiet) output. Prints less protocol information so output lines
are shorter.
-r file
Reads packets from file (which was created with the -w option).
Standard input is used if a hyphen (-) is used to specify file.
-s snaplen
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.
-S Prints absolute, rather than relative, TCP sequence numbers.
-t Does not print a timestamp on each dump line.
-tt Prints an unformatted timestamp on each dump line.
-v 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.
-vv Prints even more verbose output. For example, additional fields are
printed from NFS reply packets.
-w file
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.
-x Prints each packet (minus its link level header) in hexadecimal format.
The smaller of the entire packet or snaplen bytes is printed.
-X Prints packets in both hexadecimal and ASCII formats.
expression
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:
type 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.
dir 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.
proto 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:
dst host host
True if the IP destination field of the packet is host, which may be
either an address or a name.
src host host
True if the IP source field of the packet is host.
host 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.
ether dst ehost
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).
ether src ehost
True if the Ethernet source address is ehost.
ether host ehost
True if either the Ethernet source or destination address is ehost.
gateway host
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.
dst net net
[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.
src net net
[IPv4 networks only] True if the IP source address of the packet has a
network number of net.
net net
[IPv4 networks only] True if either the IP source or destination
address of the packet has a network number of net.
dst port port
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).
src port port
True if the packet has a source port value of port.
port 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
less length
True if the packet has a length less than or equal to length. The
following example is equivalent:
len <= length
greater length
True if the packet has a length greater than or equal to length. The
following example is equivalent:
len >= length.
ip proto protocol
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.
ether broadcast
True if the packet is an Ethernet broadcast packet. The ether keyword
is optional.
ip broadcast
[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.
ether multicast
True if the packet is an Ethernet multicast packet. The ether keyword
is optional. This is shorthand for `ether[0] & 1 != 0'.
ip multicast
[IPv4 networks only] True if the packet is an IPv4 multicast packet.
ether proto protocol
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.)
decnet src host
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.)
decnet dst host
True if the DECnet destination address is host.
decnet host host
True if either the DECnet source or destination address is host.
ip, arp, rarp, decnet, ipv6, icmpv6
Abbreviations for:
ether proto p
Where p is one of the above protocols.
lat, moprc, mopdl
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.
tcp, udp, icmp
Abbreviations for:
ip proto p
Where p is one of the protocols listed earlier.
expr relop expr
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.
DESCRIPTION
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).
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 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 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
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:
src The destination IP addresses and ports.
dst The destination IP addresses and ports.
flags
The sum combination of S (SYN), F (FIN), P (PUSH) or R (RST) or a
single period (.) for no flags.
data-seqno
The portion of sequence space covered by the data in this packet (see
the following example).
ack The sequence number of the next data expected from the other direction
on this connection.
window
The number of bytes of receive buffer space available from the other
direction on this connection.
urg Indicates there is urgent data in the packet.
options
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 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
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
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
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
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
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.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 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 .x 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.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
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)
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: 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
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
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:
id The fragment ID
size The fragment size (in bytes) excluding the IP header
offset 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
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.
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) 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.
EXAMPLES
1. To print all packets arriving at or departing from sundown:
tcpdump host sundown
2. 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 )'
3. To print all IP packets between ace and any host except helios:
tcpdump ip host ace and not helios
4. To print all traffic between local hosts and hosts at Berkeley:
tcpdump net ucb-ether
5. To print all FTP traffic through Internet gateway snup:
tcpdump 'gateway snup and (port ftp or ftp-data)'
6. 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
7. 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'
8. To print IP packets longer than 576 bytes sent through gateway snup:
tcpdump 'gateway snup and ip[2:2] > 576'
9. 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'
10. 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'
11. To print all RIPv6 packets, enter:
tcpdump -i ln0 -s 1500 -envv ipv6 and udp port 521
12. 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
SEE ALSO
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.
|
Index for
Section 8 |
|
|
Alphabetical
listing for T |
|
 |
Top of
page |
|