Westwind Computing
 206-522-3530
 Sales Information
 Customer Feedback
Westwind Computing
[New to Westwind?]  [Customers]  [News & Information] 



Reference


WhatRoute packet monitor / unix tcpdump reference



tcpdump(8)							   tcpdump(8)



NAME

  tcpdump - Dump traffic on a network

SYNOPSIS

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

FLAGS

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

  -F  Uses file	as input for the filter	expression.  Any additional expres-
      sions on the command line	are ignored.

  -i  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 flag,	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  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  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 ade-
      quate 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 proto-
      col 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  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 hex.	The smaller
      of the entire packet or snaplen bytes is printed.

   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 fol-
      lowing qualifiers:

      type
	  Defines the object to	which the id name or number refers.  The fol-
	  lowing 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	fol-
	  lowing 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 proto-
	  cols 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 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.  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
	  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
	  True if the IP source	address	of the packet has a network number of
	  net.

      net net
	  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 expres-
	  sions: 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. Protocol can be a number or	one of the names icmp, udp,
	  nd, or tcp.  Note: the identifiers tcp, udp, and icmp	are also key-
	  words	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 key-
	  word is optional.

      ip broadcast
	  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 key-
	  word is optional. This is shorthand for `ether[0] & 1	!= 0'.

      ip multicast
	  True if the packet is	an IP multicast	packet.

      ether proto protocol
	  True if the packet is	of ether type protocol.	 The protocol argu-
	  ment 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 iden-
	  tifier, 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
	  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 acces-
	  sors.	 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 unfrag-
	  mented 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:

	o+
	A parenthesized	group of primitives and	operators (parentheses are
	special	to the Shell and must be escaped).

	o+
	Negation (! or not)

	o+
	Concatenation (and)

	o+
	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 argu-
      ment or as multiple arguments, whichever is more convenient.  Gen-
      erally, if the expression	contains shell metacharacters, it is easier
      to pass it as a single, quoted argument.	Multiple arguments are con-
      catenated	with spaces before being parsed.

DESCRIPTION

  The tcpdump utility prints out the headers of	packets	on a network inter-
  face that match the boolean expression.  Your	kernel must be configured
  with the packetfilter	option.	 (See packetfilter(7).)	After kernel confi-
  guration, any	user can invoke	tcpdump	once the superuser has enabled
  promiscuous-mode operation using pfconfig(8).

RESTRICTIONS

  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.

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 complex expressions,	you can	enclose	expressions
  in single quotation marks (` ') to prevent the shell from processing spe-
  cial characters.  For	example, the previous example could be entered as
  follows:


       tcpdump `host helios and	( hot or ace )'

  To print all IP packets between ace and any host except helios:

       tcpdump ip host ace and not helios

  To print all traffic between local hosts and hosts at	Berkeley:

       tcpdump net ucb-ether

  To print all FTP traffic through Internet gateway snup:

       tcpdump 'gateway	snup and (port ftp or 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 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 compres-
  sion 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	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	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 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	sin-
      gle 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 out-
      put 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 con-
  tained 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 flag overrides this feature, causing the origi-
  nal 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.

  A following anomalies	are checked and	may result in extra fields enclosed
  in square brackets:

    o+  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.

    o+  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	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:
  __________________________________________________________________________
  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 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) 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 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 setpro-
  plist(2) 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	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
  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	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
  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:

    o+  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.

    o+  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.

RELATED	INFORMATION

  Commands: nfswatch(8), pfstat(1), pfconfig(8), tcpslice(8)

  Files: packetfilter(7), bpf(7)

Home | Specials | Products | Education | About Us | Services | Training | Support | Reference | Events | How-to
   Copyright © 2000-2004 Westwind Computing