Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Apropos / Subsearch:
optional field

tcpdump(8)							   tcpdump(8)


  tcpdump - Dump traffic on a network


  /usr/sbin/tcpdump [-deflmnNOpqStvxX] [-c count] [-Ffile] [-iinterface]
  [-rfile] [-ssnaplen] [-wfile]	expression


  -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 symboli-

  -F file
      Uses file	as input for the filter	expression.  Any additional expres-
      sions 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	can-
      not 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).  Stan-
      dard 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 informa-
      tion from	name server and	NFS packets (discussed later in	this refer-
      ence page).  Packets truncated because of	a limited snapshot are indi-
      cated in the output with "[|proto]", where proto is the name of the
      protocol level at	which the truncation has occurred.


	 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.

      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 fol-
      lowing 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 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
	      filter expression.

  In addition to the above, there are some special "primitive" keywords	that
  do not follow	the pattern: gateway, broadcast, less, greater,	and arith-
  metic	expressions.  All of these are described later in this reference

  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

  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 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).

  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	fol-
      lowing 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 proto-
      col. The protocol	can be a number	or one of the names ipv6, icmp,
      icmpv6, udp, nd, or tcp.


	 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] &&amp; 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 identif-
      iers are also keywords and must be escaped via backslash (\). (In	the
      case of FDDI (for	example, fddi protocol arp), the protocol identifica-
      tion 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

  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.


	 The tcpdump utility does not currently	know how to parse these	pro-

  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] &&amp; 1 != 0' catches all multicast traffic. The
      expression `ip[0]	&&amp; 0xf != 5' catches all	IP packets with	options. The
      expression `ip[2:2] &&amp; 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 sin-
  gle, quoted argument.	Multiple arguments are concatenated with spaces
  before being parsed.


  The tcpdump utility prints out the headers of	packets	on a network inter-
  face 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

  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.


       The following description assumes familiarity with the SLIP compres-
       sion 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

  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	for-
  mat 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 Ether-
  net 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 tell
       arp reply 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.

      The sum combination of S (SYN), F	(FIN), P (PUSH)	or R (RST) or a	sin-
      gle period (.) for no flags.

      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.

      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.

      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

  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 conversa-
  tion,	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 posi-
  tions	in the conversation's data stream (with	the first data byte each
  direction being 1).  The -S option overrides this feature, causing the ori-
  ginal	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	pro-
  tocol	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 (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	 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

  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

  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 seri-
  ously	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
  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
  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"
       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 gen-
  eration 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

       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 setpro-
  plist(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

  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	dis-
  carded).  The	file /etc/atalk.names is used to translate AppleTalk network
  numbers and node numbers to names. Lines in this file	have the following

       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:


  For example: > 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

  In the first example,	the name binding protocol (NBP)	(DDP port 2) on	net-
  work 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	net-
  work 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 dis-
  tinct	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 request-
  ing 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

  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	con-
  nection 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


  By default, all output lines are preceded by a timestamp.  The timestamp is
  the current clock time in the	following form:


  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	copy-
  all 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 pack-
  ets are encapsulated Ethernet	packets.  This is true for IP, ARP, and	DEC-
  net 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.


   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 expres-
       sions in	single quotation marks (` ') to	prevent	the shell from pro-
       cessing 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	fol-
       lowing 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] &&amp; 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] >&gt;	576'

   9.  To print	IP broadcast or	multicast packets that were not	sent via Eth-
       ernet broadcast or multicast:
	    tcpdump 'ether[0] &&amp;	1 = 0 and ip[16] >&gt;= 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


  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.