tcpdump man page on DigitalUNIX

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
DigitalUNIX logo
[printable version]

tcpdump(8)							    tcpdump(8)

       tcpdump - Dump traffic on a network

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

       Exits after receiving count packets.  Dumps the compiled	 packet-match‐
       ing  code to standard output and stop.  Prints the link-level header on
       each dump line.	Prints “foreign” internet addresses numerically rather
       than  symbolically.  Uses file as input for the filter expression.  Any
       additional expressions on the command line  are	ignored.   Listens  on
       interface.   If unspecified, tcpdump searches the system interface list
       for the lowest numbered, configured up interface (excluding  loopback).
       Ties  are  broken  by  choosing	the earliest match.  Makes stdout line
       buffered.  This is useful if you want to see the data  while  capturing
       it.   Enables  multiline output from some protocols.  This affects most
       Sun RPC decoding, as those protocols are often difficult to display  on
       a single line.  Does not convert addresses (for example, host addresses
       and port numbers) to names.  Does not print domain  name	 qualification
       of  host	 names.	 For  example,	with the -N option, tcpdump prints nic
       instead of	Does not run the  packet-matching  code	 opti‐
       mizer.	This  is  useful  only	if you suspect a bug in the optimizer.
       Does not put the interface into promiscuous mode.  Note	the  interface
       might  be in promiscuous mode for some other reason; therefore, -p can‐
       not be used as an abbreviation for ether host {localhost} or broadcast.
       Quick (quiet) output.  Prints less protocol information so output lines
       are shorter.  Reads packets from file (which was created	 with  the  -w
       option).	  Standard  input  is  used if a hyphen (-) is used to specify
       file.  Displays snaplen bytes of data from each packet rather than  the
       default	of  68 (with NIT, the minimum is 96).  The default of 68 bytes
       is adequate for IP, ICMP, TCP,  and  UDP,  but  may  truncate  protocol
       information  from  name server and NFS packets (discussed later in this
       reference page).	 Packets truncated because of a limited	 snapshot  are
       indicated in the output with “[|proto]”, where proto is the name of the
       protocol level at which the truncation has occurred.


	      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 pro‐
	      tocol information.  Prints absolute, rather than	relative,  TCP
	      sequence numbers.	 Does not print a timestamp on each dump line.
	      Prints an unformatted  timestamp	on  each  dump	line.	Prints
	      slightly more verbose output.  For example, the time to live and
	      type of service information in an IP packet is printed. If -m is
	      also  specified,	Sun  RPC  packets  sent	 using TCP are decoded
	      twice: first as RPC, then as TCP.	 Normally the TCP decoding  is
	      suppressed.   Prints  even  more	verbose	 output.  For example,
	      additional fields are printed from NFS  reply  packets.	Writes
	      the  raw	packets to file rather than parsing and printing them.
	      They can later be printed with the -r option. Standard output is
	      used  if	a  hyphen  (-)	is  used to specify file.  Prints each
	      packet (minus its link level header) in hexadecimal format.  The
	      smaller  of  the	entire	packet	or  snaplen  bytes is printed.
	      Prints packets in both hexadecimal and ASCII  formats.   Selects
	      the  packets to dump.  If no expression is given, all packets on
	      the network are  dumped.	 Otherwise,  only  packets  for	 which
	      expression is “true” are dumped.

	      The  expression  consists	 of one or more primitives. Primitives
	      usually consist of an id (name or number)	 preceded  by  one  or
	      more  of	the  following qualifiers: Defines the object to which
	      the id name or number refers. The following types	 are  allowed:
	      host, net, and port. For example:

	      host foo net 128.3 port 20

	      If  no type qualifier is specified, host is the default.	Speci‐
	      fies a particular transfer direction to or from id. The  follow‐
	      ing  directions  are  allowed: src, dst, src or dst, and src and
	      dst. For example:

	      src foo dst net 128.3 src or dst port 20 src and dst port 123

	      If no dir qualifier is specified, src or	dst  is	 the  default.
	      Restricts	 the  match  to	 a particular protocol.	 The following
	      protocols are allowed: ether, fddi, ip, ipv6, icmpv6, arp, rarp,
	      decnet, lat, moprc, mopdl, tcp, and udp. For example:

	      ether src foo arp net 128.3 tcp port 21

	      If  no  proto  qualifier	is specified, all protocols consistent
	      with the type are assumed.  For example, src foo	means  (ip  or
	      arp  or  rarp)  src foo (except the latter is not legal syntax),
	      net bar means (ip or arp or rarp) net bar, port 53 means (tcp or
	      udp) port 53.

	      The  fddi argument is an alias for ether; the parser treats them
	      identically as meaning “the data link level used on  the	speci‐
	      fied  network  interface.”   FDDI	 headers contain Ethernet-like
	      source and destination addresses, and  often  contain  Ethernet-
	      like  packet  types, so you can filter on these FDDI fields just
	      as with the analogous Ethernet fields.  FDDI headers  also  con‐
	      tain other fields, but you cannot name them explicitly in a fil‐
	      ter expression.

       In addition to the above, there are some special	 “primitive”  keywords
       that  do not follow the pattern: gateway, broadcast, less, greater, and
       arithmetic expressions.	All of these are described later in this  ref‐
       erence page.

       More  complex  filter  expressions are built up by using the words and,
       or, and not to combine primitives.  For example:

       host foo and not port ftp and not port ftp-data

       To save typing, identical qualifier lists can be omitted.  For example,
       the following two lines are treated the same:

       tcp dst port ftp or ftp-data or domain tcp dst port ftp or tcp dst port
       ftp-data or tcp dst port domain

       Allowable primitives are: True if  the  IP  destination	field  of  the
       packet  is host, which may be either an address or a name.  True if the
       IP source field of the packet is host.  True if either the IP source or
       destination  of	the packet is host. The following keywords can precede
       any of these host expressions: ip, arp, or rarp. For example, the  fol‐
       lowing examples are equivalent:

	      ip host host ether proto ip and host host

	      If  host	is  a name with multiple IP addresses, each address is
	      checked for a match.  True if the Ethernet  destination  address
	      is  ehost.  The ehost may be either a name from /etc/ethers or a
	      number (see ethers(3) for numeric format).  True if the Ethernet
	      source  address is ehost.	 True if either the Ethernet source or
	      destination address is ehost.  True if the packet used host as a
	      gateway.	 That  is,  the Ethernet source or destination address
	      was host but neither the IP source nor the  IP  destination  was
	      host.   The  host	 argument  must be a name and must be found in
	      both /etc/hosts and /etc/ethers.

	      The following expression is equivalent:

	      ether host ehost and not host host

	      You can use either names or numbers for host and	ehost.	 [IPv4
	      networks only]  True if the IP destination address of the packet
	      has a network number of net, which may be either an address or a
	      name.   [IPv4  networks  only]  True if the IP source address of
	      the packet has a network number of net.	[IPv4  networks	 only]
	      True  if	either	the  IP	 source	 or destination address of the
	      packet has a network number of  net.   True  if  the  packet  is
	      IP/TCP  or  IP/UDP and has a destination port value of port. The
	      port can be a number or a name used in /etc/services (see tcp(7)
	      and  udp(7)). If a name is used, both the port number and proto‐
	      col are checked.	If a number or ambiguous name  is  used,  only
	      the  port	 number is checked.  (For example, dst port 513 prints
	      both TCP login service traffic and UDP who service traffic,  and
	      port  domain  prints  both  TCP/DOMAIN  and UDP/DOMAIN traffic).
	      True if the packet has a source port value  of  port.   True  if
	      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

	      tcp src port port True if the packet has a length less  than  or
	      equal to length. The following example is equivalent:

	      len  <=  length  True if the packet has a length greater than or
	      equal to length. The following example is equivalent:

	      len >= length.  True if the packet is an IP packet  (see	ip(7))
	      of  protocol  type protocol. The protocol can be a number or one
	      of the names ipv6, icmp, icmpv6, udp, nd, or tcp.


	      The identifiers tcp, udp, and icmp are also keywords and must be
	      escaped  via backslash (\), which is \\ in the C-shell.  True if
	      the packet is an Ethernet broadcast packet.  The	ether  keyword
	      is  optional.  [IPv4 networks only]  True if the packet is an IP
	      broadcast packet.	 It checks for both the	 all-zeroes  and  all-
	      ones  broadcast conventions, and looks up the local subnet mask.
	      True if the packet is an Ethernet multicast packet.   The	 ether
	      keyword  is optional. This is shorthand for `ether[0] & 1 != 0'.
	      [IPv4 networks only]  True if the packet is  an  IPv4  multicast
	      packet.	True if the packet is of ether type protocol. The pro‐
	      tocol 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  lay‐
	      ered  on	top  of	 the FDDI header. The tcpdump utility assumes,
	      when filtering on the protocol identifier, that all FDDI packets
	      include  an  LLC header, and that the LLC header is in so-called
	      SNAP format.)  True  if  the  packet  is	an  IEEE  802.1Q  VLAN
	      (tagged)	packet.	  If  vlan-id  is specified, only packets from
	      that particular VLAN will	 match.	 Every	part  of  the  tcpdump
	      expression  that	is  evaluated  before  the  first vlan keyword
	      catches either tagged or untagged packets.  Every	 part  of  the
	      tcpdump  expression  that is evaluated after the first vlan key‐
	      word catches only tagged packets.

	      For example, the expression arp catches both tagged ARP  packets
	      and  untagged  ARP  packets.  The	 expression  arp  or vlan 1001
	      catches tagged ARP packets, untagged ARP packets, and VLAN  1001
	      packets.	However,  the expression vlan 1001 or arp catches only
	      VLAN 1001 packets and tagged ARP packets.	 True  if  the	DECnet
	      source  address  is  host,  which	 may be an address of the form
	      “10.123”, or a DECnet host name.	(DECnet host name  support  is
	      only  available  on  systems that are configured to run DECnet.)
	      True if the DECnet destination address is host.  True if	either
	      the DECnet source or destination address is host.	 Abbreviations

	      ether proto p

	      Where p is one of the above protocols.  Abbreviations for:

	      ether proto p

	      Where p is one of the above protocols.


	      The tcpdump utility does not currently know how to  parse	 these
	      protocols.  Abbreviations for:

	      ip proto p

	      Where  p	is  one	 of the protocols listed earlier.  True if the
	      relation holds, where relop is >, <, >=, <=, =, or !=, and  expr
	      is  an  arithmetic  expression  composed	of  integer  constants
	      (expressed in standard C syntax), the  normal  binary  operators
	      [+,  -,  *, /, &, |], a length operator, and special packet data
	      accessors. To access data inside the packet, use	the  following
	      syntax: proto [expr : size]

	      The  proto  variable  is one of ether, fddi, ip, arp, rarp, tcp,
	      udp, or icmp, and indicates the protocol	layer  for  the	 index
	      operation.   The byte offset, relative to the indicated protocol
	      layer, is given by expr. The size variable is optional and indi‐
	      cates  the  number  of bytes in the field of interest; it can be
	      either one, two, or four, and defaults to one. The length opera‐
	      tor,  indicated  by  the	keyword	 len,  gives the length of the

	      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 opera‐
	      tions.  For  instance, tcp[0] always means the first byte of the
	      TCP header, and never means the first  byte  of  an  intervening

       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	 argu‐
       ment  or	 as  multiple arguments, whichever is more convenient.	Gener‐
       ally, if the expression contains shell metacharacters, it is easier  to
       pass  it	 as a single, quoted argument. Multiple arguments are concate‐
       nated with spaces before being parsed.

       The tcpdump utility prints out the headers  of  packets	on  a  network
       interface  that match the boolean expression.  Decoding of tftp options
       complies with RFC 1782 (see the tftpd(8) and tftp(1) reference  pages).
       Your kernel must be configured with the packetfilter option. (See pack‐
       etfilter(7).) After kernel configuration, any user can  invoke  tcpdump
       once  the superuser has enabled promiscuous-mode operation using pfcon‐

       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

       On FDDI networks, the -e option causes the tcpdump utility to print the
       frame control field, the source	and  destination  addresses,  and  the
       packet  length.	(The frame control field governs the interpretation of
       the rest of the packet.	Normal packets (such as	 those	containing  IP
       datagrams)  are	async  packets, with a priority value between 0 and 7;
       for example, async4.  Such packets are assumed to contain an 802.2 Log‐
       ical  Link Control (LLC) packet; the LLC header is printed if it is not
       an ISO datagram or a so-called SNAP packet.


       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 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 acknowledgment) has changed. If
       it  is  not a special case, zero or more changes are printed.  A change
       is indicated by U (urgent pointer), W (window), A  (acknowledgment),  S
       (sequence  number),  and I (packet ID), followed by a delta (+n or -n),
       or a new value (=n). Finally, the amount of data in the packet and com‐
       pressed header length are printed.

       The  following example shows an outbound compressed TCP packet, with an
       implicit connection identifier; the value  of  the  acknowledgment  has
       changed	by 6, the sequence number by 49, and the packet ID by 6; there
       are 3 bytes of data and 6 bytes of compressed header:

       O ctcp * A+6 S+49 I+6 3 (6)

   ARP/RARP Packets
       ARP and RARP output shows the type of request and its  arguments.   The
       format  is  intended  to	 be self explanatory. The following example is
       taken from the start of an rlogin from host rtsg to host csam:

       arp who-has csam tell rtsg arp reply csam is-at CSAM

       The first line indicates that host rtsg sent an ARP packet  asking  for
       the Ethernet address of Internet host csam.  Host csam replies with its
       Ethernet address (in this example, Ethernet addresses are uppercase and
       Internet addresses in lowercase).

       This would look less redundant if we had done tcpdump -n:

       arp  who-has tell arp reply is-at

       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 destina‐
       tion  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: The destination IP addresses and
       ports.  The destination IP addresses and ports.	The sum combination of
       S  (SYN),  F  (FIN), P (PUSH) or R (RST) or a single period (.)	for no
       flags.  The portion of sequence space  covered  by  the	data  in  this
       packet  (see  the  following example).  The sequence number of the next
       data expected from the other direction on this connection.  The	number
       of  bytes of receive buffer space available from the other direction on
       this connection.	 Indicates there is urgent data in  the	 packet.   The
       TCP options enclosed in angle brackets. For example,

	      <mss 1024>

       The  src,  dst,	and  flags fields are always present. The other fields
       depend on the contents of the packet's TCP protocol header and are 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

       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 particu‐
       lar, Domain Name service requests (RFC 1034 and RFC 1035) and  Sun  RPC
       calls (RFC 1050) to NFS.

   UDP Name Server Requests
       The  following  description assumes familiarity with the Domain Service
       protocol described in RFC 1035.

       Name server requests are formatted as follows:

       src > dst: id op? flags qtype qclass name (len)

       For example:

       h2opolo.1538 > helios.domain: 3+ A? (37)

       Host h2opolo queried the domain server on host helios  for  an  address
       record  (qtype=A)  associated  with  the	 name 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 authori‐
       tative  answer  bit is set.  Since there are no answers, no type, class
       or data are printed.

       Other flag characters that might appear are the minus sign (-)  (recur‐
       sion  available,	 RA, not set) and vertical bar (|) (truncated message,
       TC, set).  If the `question' section doesn't contain exactly one entry,
       [nq] is printed.

       Note  that name server requests and responses tend to be large, and the
       default value of snaplen, 96 bytes,  may	 not  capture  enough  of  the
       packet to print.	 Use the -s 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 num‐
					bers 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
       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

       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 con‐
       tents of the link.

       In the third line, host sushi asks host wrl to look up the name xcolors
       in  directory  file 9,74/4096.6878.  Note that the data printed depends
       on the operation type.  The format is intended to be  self  explanatory
       if read in conjunction with a protocol specification rpcgen file.

       If the -v (verbose) option is given, additional information is printed.

       If the -v option is given more than once, more details may be printed.

       Note  that  RPC	requests  are very large and much of the detail is not
       printed. Property list information may also be obtained using  tcpdump.
       For example: > \
	    276 call proproc3_get OSF/1 fh 8,18434/1.4 mask:-1 11 entries > \
	    296 reply proproc3_get status OK 368 bytes 11 entries

       For  property  list calls, you can request the mask value (see the set‐
       proplist(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 fol‐
       low 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:

       For example:  >  icsd-net.112.220	 office.2  >   icsd-net.112.220	  jss‐
       mag.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  con‐
       tents  interpreted.   Other protocols dump the protocol name (or number
       if no name is registered for the protocol) and packet size.

       NBP packets are formatted as shown in the following examples:

       icsd-net.112.220	 >  jssmag.2:  nbp-lkup	 190:  "=:LaserWriter@*"  jss‐
       mag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
       techpit.2 > icsd-net.112.220:  nbp-reply	 190:  "techpit:LaserWriter@*"

       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	laser‐
       writer  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  >  jss‐
       mag.209.165:  atp-resp  12266:1	(512)  0xae040000  helios.132  >  jss‐
       mag.209.165:  atp-resp  12266:2	(512)  0xae040000  helios.132  >  jss‐
       mag.209.165:  atp-resp  12266:3	(512)  0xae040000  helios.132  >  jss‐
       mag.209.165:  atp-resp  12266:4	(512)  0xae040000  helios.132  >  jss‐
       mag.209.165:  atp-resp  12266:5	(512)  0xae040000  helios.132  >  jss‐
       mag.209.165:  atp-resp  12266:6	(512)  0xae040000  helios.132  >  jss‐
       mag.209.165:   atp-resp*12266:7	 (512)	 0xae040000  jssmag.209.165  >
       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>

       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 indi‐
       cates this is the last fragment.

       The following list explains the fields: The fragment  ID	 The  fragment
       size  (in  bytes)  excluding  the  IP  header The fragment's offset (in
       bytes) in the original datagram

       The fragment information is output for each fragment.  The first	 frag‐
       ment  contains the higher level protocol header and the fragment infor‐
       mation is printed after the protocol information.  Fragments after  the
       first contain no higher level protocol header and the fragment informa‐
       tion is printed after the source and destination addresses. The follow‐
       ing  example  shows  part  of  an  FTP session from to lbl- 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  >  ari‐
       zona.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).

       By  default,  all  output lines are preceded by a timestamp.  The time‐
       stamp 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 inter‐

       To watch either outbound or inbound traffic, you need to	 have  enabled
       copyall mode using the pfconfig command.	 For example, pfconfig +c ln0.

       Name server inverse queries are not dumped correctly: The (empty) ques‐
       tion section is printed rather than real query in the answer section.

       A packet trace that crosses a  daylight	saving	time  change  produces
       skewed time stamps (the time change is ignored).

       Filter  expressions  that  manipulate FDDI headers assume that all FDDI
       packets are encapsulated Ethernet packets.  This is true for  IP,  ARP,
       and  DECnet  Phase  IV, but is not true for protocols such as ISO CLNS.
       Therefore, the filter may inadvertently accept certain packets that  do
       not properly match the filter expression.

       To  print  all  packets	arriving at or departing from sundown: tcpdump
       host sundown To print traffic between helios and	 either	 hot  or  ace:
       tcpdump host helios and \( hot or ace \)

	      Note  that  to  ease typing complex expressions, you can enclose
	      expressions in single quotation marks (` ') to prevent the shell
	      from  processing	special characters.  For example, the previous
	      example could be entered as follows: tcpdump `host helios and  (
	      hot  or  ace )' To print all IP packets between ace and any host
	      except helios: tcpdump ip host ace and not helios To  print  all
	      traffic  between	local hosts and hosts at Berkeley: tcpdump net
	      ucb-ether To print all  FTP  traffic  through  Internet  gateway
	      snup: tcpdump 'gateway snup and (port ftp or 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 pack‐
	      ets (the SYN and FIN packets)  of	 each  TCP  conversation  that
	      involves	a nonlocal host: tcpdump 'tcp[13] & 3 != 0 and not src
	      and dst net localnet' To print IP packets longer than 576	 bytes
	      sent  through  gateway snup: tcpdump 'gateway snup and ip[2:2] >
	      576' To print IP broadcast or multicast packets  that  were  not
	      sent  via Ethernet broadcast or multicast: tcpdump 'ether[0] & 1
	      = 0 and ip[16] >= 224' To print all ICMP packets	that  are  not
	      echo  requests  or  replies (that is, not ping packets): tcpdump
	      'icmp[0] != 8 and icmp[0] != 0'  To  print  all  RIPv6  packets,
	      enter:  tcpdump  -i  ln0	-s 1500 -envv ipv6 and udp port 521 To
	      print all IPv6 packets arriving at or departing from a host with
	      the  Ethernet address a:b:c:d:e:f, enter: tcpdump -i ln0 -s 1500
	      -envv ipv6 and ether host a:b:c:d:e:f

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

       Files: bpf(7), packetfilter(7)

       RFC 1782, TFTP Option Extension, Harkin A., Malkin, G.

       RFC 2080, RIPng for IPv6, Malkin, G., Minnear, R.


List of man pages available for DigitalUNIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net