*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->Tru64 Unix man pages -> tcpdump (8)              



NAME    [Toc]    [Back]

       tcpdump - Dump traffic on a network

SYNOPSIS    [Toc]    [Back]

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

OPTIONS    [Toc]    [Back]

       Exits after receiving count packets.  Dumps  the  compiled
       packet-matching  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 nic.ddn.mil.  Does not run the
       packet-matching code optimizer.  This is  useful  only  if
       you  suspect  a  bug  in  the optimizer.  Does not put the
       interface into promiscuous mode.  Note the interface might
       be  in  promiscuous mode for some other reason; therefore,
       -p cannot be  used  as  an  abbreviation  for  ether  host
       {localhost}  or  broadcast.  Quick (quiet) output.  Prints
       less protocol information so  output  lines  are  shorter.
       Reads  packets  from  file  (which was created with the -w
       option).  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
              protocol information.  Prints absolute, rather than
              relative,  TCP  sequence numbers.  Does not print a
              timestamp on each dump line.  Prints an unformatted
              timestamp  on each dump line.  Prints slightly more
              verbose output.  For example, the time to live  and
              type  of  service  information  in  an IP packet is
              printed. If -m is also specified, Sun  RPC  packets
              sent  using  TCP  are  decoded twice: first as RPC,
              then  as  TCP.   Normally  the  TCP   decoding   is
              suppressed.   Prints even more 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.  Specifies a particular transfer direction
              to   or  from  id.  The  following  directions  are
              allowed: src, dst, src or dst, and src and dst. For

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

              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  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).  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 protocol argument can be a
              number  or a name like ip, ipv6, arp, or rarp. Note
              these identifiers are also  keywords  and  must  be
              escaped  via  backslash  (\).  (In the case of FDDI
              (for example,  fddi  protocol  arp),  the  protocol
              identification  comes  from  the 802.2 Logical Link
              Control (LLC) header, which is usually  layered  on
              top   of  the  FDDI  header.  The  tcpdump  utility
              assumes, when filtering on the protocol identifier,
              that  all  FDDI  packets include an LLC header, and
              that the LLC header is in so-called  SNAP  format.)
              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 keyword
              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 for:

              ether proto p

              Where p is one of the above  protocols.   Abbreviations

              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 :

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

              For example, `ether[0] & 1 != 0' catches all multicast
  traffic.  The  expression  `ip[0] & 0xf != 5'
              catches all IP packets with options. The expression
              `ip[2:2]  &  0x1fff  = 0' catches only unfragmented
              datagrams and frag zero  of  fragmented  datagrams.
              This check is implicitly applied to the tcp and udp
              index operations. For instance, tcp[0] always means
              the  first  byte of the TCP header, and never means
              the first byte of an intervening fragment.

       Primitives may be combined using: A parenthesized group of
       primitives  and  operators (parentheses are special to the
       Shell and must be escaped).  Negation (!  or not) Concatenation
 (and) Alternation (or)

       Negation  has highest precedence. Alternation and concatenation
 have equal precedence and associate left to  right.
       Note  that  explicit  and  tokens  (not juxtaposition) are
       required for concatenation.

       If an identifier is given  without  a  keyword,  the  most
       recent  keyword is assumed. For example, the following two
       examples are equivalent:

       not host vs and ace

       not host vs and host ace

       However, the following example is not  equivalent  to  the
       previous two:

       not ( host vs or ace )

       Expression  arguments can be passed to tcpdump as either a
       single argument or as  multiple  arguments,  whichever  is
       more  convenient.   Generally,  if the expression contains
       shell metacharacters, it is easier to pass it as a single,
       quoted  argument. Multiple arguments are concatenated with
       spaces before being parsed.

DESCRIPTION    [Toc]    [Back]

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

OUTPUT FORMAT    [Toc]    [Back]

       The  output  of the tcpdump utility is protocol dependent.
       The following sections describe most of  the  formats  and
       provide examples.

   Link Level Headers    [Toc]    [Back]
       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 compression algorithm described in RFC 1144.

       On SLIP links, a direction indicator ("I" for inbound, "O"
       for outbound), packet type,  and  compression  information
       are printed.

       The packet type is printed first. The three types of packets
 are ip, utcp, and ctcp.  No further  link  information
       is printed for ip packets.

       For  TCP  packets,  the  connection  identifier is printed
       after the type.  If the packet is compressed, its  encoded
       header  is  printed. The special cases are printed as *S+n
       and *SA+n, where n is the amount  by  which  the  sequence
       number   (or   sequence  number  and  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
       compressed 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 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  pointto-point

       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    [Toc]    [Back]
       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 output only if appropriate.

       The following example shows  the  opening  portion  of  an
       rlogin session from host rtsg to host csam:

       rtsg.1023  >  csam.login: S 768512:768512(0) win 4096 <mss
       1024>  csam.login  >  rtsg.1023:  S  947648:947648(0)  ack
       768513 win 4096 <mss 1024> rtsg.1023 > csam.login: . ack 1
       win 4096 rtsg.1023 > csam.login: P 1:2(1) ack 1  win  4096
       csam.login  >  rtsg.1023:  .  ack  2  win 4096 rtsg.1023 >
       csam.login:  P  2:21(19)  ack  1  win  4096  csam.login  >
       rtsg.1023:   P   1:2(1)  ack  21  win  4077  csam.login  >
       rtsg.1023: P 2:3(1) ack 21 win 4077  urg  1  csam.login  >
       rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1

       The first line indicates that TCP port 1023 on system rtsg
       sent a packet to port login on host csam.  The S indicates
       that  the SYN flag was set. The packet sequence number was
       768512  and  it  contained  no  data.  (The  notation   is
       first:last(nbytes)  which  means sequence numbers first up
       to but not including last which is nbytes  bytes  of  user
       data.)  There  was  no  piggy-backed  ack,  the  available
       receive window was 4096 bytes and there was a max-segmentsize
 option requesting an mss of 1024 bytes.

       Host csam replies with a similar packet except it includes
       a piggy-backed ack for the SYN sent by  rtsg.   Host  rtsg
       then  sends  an  ack  reply  to  the SYN sent by csam. The
       period (.) means no flags were set. The  packet  contained
       no data so there is no data sequence number. Note that the
       ack sequence number is a small  integer  (1).   The  first
       time  tcpdump  sees  a  TCP  conversation,  it  prints the
       sequence number from the packet. On subsequent packets  of
       the  conversation,  the  difference  between  the  current
       packet's sequence number and this initial sequence  number
       is  printed.   This  means that sequence numbers after the
       first can be interpreted as relative byte positions in the
       conversation's  data stream (with the first data byte each
       direction being 1).  The -S option overrides this feature,
       causing the original sequence numbers to be output.

       The sixth line indicates that host rtsg sends host csam 19
       bytes of data (bytes 2 through 20 in the rtsg to csam side
       of  the conversation). The PUSH flag is set in the packet.
       The seventh line indicates that  host  csam  has  received
       data  sent  by  host rtsg up to but not including byte 21.
       Most of this data is  apparently  sitting  in  the  socket
       buffer  because  the  receive  window   on host csam is 19
       bytes smaller.  Host csam also sends one byte of  data  to
       host rtsg in this packet.  The eighth and ninth lines show
       that host csam sends two bytes of urgent, pushed  data  to

   UDP Packets    [Toc]    [Back]
       The  UDP  format  is  illustrated  by  the  following rwho

       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    [Toc]    [Back]
       The  following  description  assumes  familiarity with the
       Domain Service protocol described in RFC 1035.

       Name server requests are formatted as follows:

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

       For example:

       h2opolo.1538 > helios.domain: 3+  A?  ucbvax.berkeley.edu.

       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    [Toc]    [Back]
       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 printed.

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

       Note that name server requests and responses  tend  to  be
       large,  and  the  default value of snaplen, 96 bytes,  may
       not capture enough of the packet to  print.   Use  the  -s
       option  to  increase  the snaplen if you need to seriously
       investigate name server traffic.

   TFTP Packets    [Toc]    [Back]
       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    [Toc]    [Back]
       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
       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.mountv1:
 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 generation number.)  Host
       wrl replies ok with the contents of the link.

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

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

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

       Note that RPC requests are very  large  and  much  of  the
       detail  is not printed. Property list information may also
       be obtained using tcpdump. For example:

       alpha1.zk3.dec.com.da31fba5 > alpha2.zk3.dec.com.proplistv3:
            276 call proproc3_get OSF/1 fh 8,18434/1.4 mask:-1 11

       alpha2.zk3.dec.com.da31fba5 > alpha1.zk3.dec.com.proplistv3:
            296 reply proproc3_get status OK 368 bytes 11 entries

       For property list calls, you can request  the  mask  value
       (see  the setproplist(3) reference page) and the number of
       property list entries. Property list  replies  return  the
       status,  the  number of bytes in the property list and the
       number of entries in property list.

       Note that NFS requests are very  large  and  much  of  the
       detail  is  not  printed  unless  the  value of snaplen is
       increased.  Try using -s 192 to watch RPC traffic.

       RPC reply packets do not explicitly identify the RPC operation.
  Instead,  tcpdump  keeps track of recent requests,
       and matches them to the replies using the transaction  ID.
       If  a  reply  does  not  closely  follow the corresponding
       request, it might not be parsable.

       NFS and Sun are registered trademarks of Sun Microsystems,

   KIP AppleTalk (DDP in UDP)    [Toc]    [Back]
       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
       jssmag.149.235 > icsd-net.2

       (If the /etc/atalk.names file does not exist or  does  not
       contain  an  entry for some AppleTalk host or network number,
 addresses are printed in numeric form.)

       In the first example, the name binding protocol (NBP) (DDP
       port  2)  on  network  144.1 node 209 sends to whatever is
       listening on port 220 of network icsd node 112. The second
       line  is  the same except the full name of the source node
       is known (office).  The third line sends from port 235  on
       network  jssmag  node 149 to broadcast on the icsd-net NBP
       port. (Note that the broadcast address (255) is  indicated
       by a network name with no host number.  For this reason it
       is a good idea to keep node names and network  names  distinct
 in /etc/atalk.names).

       NBP  and ATP (AppleTalk transaction protocol) packets have
       their contents interpreted.  Other protocols dump the protocol
  name  (or  number  if no name is registered for the
       protocol) and packet size.

       NBP packets are formatted as shown in the following  examples:

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

       The first line shows a name lookup request for  laserwriters
 sent by network host icsd 112 and broadcast on network
       jssmag.  The NBP ID for the lookup is 190. The second line
       shows  a  reply  to this request (it has the same ID) from
       host jssmag.209  indicating  that  it  has  a  laserwriter
       resource  named  RM1140 registered on port 250.  The third
       line shows another reply to the  same  request  indicating
       host  techpit  has  laserwriter techpit registered on port

       ATP packet formatting is  demonstrated  by  the  following

       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: atpresp
 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:  atpresp
 12266:3 (512) 0xae040000 helios.132 > jssmag.209.165:
       atp-resp  12266:5  (512)   0xae040000   jssmag.209.165   >
       helios.132:  atp-rel  12266<0-7> 0xae030001 jssmag.209.133
       > helios.132: atp-req* 12267<0-7> 0xae030002

       Host jssmag.209 initiates transaction ID 12266  with  host
       helios  by  requesting up to eight packets (0-7).  The hex
       number at the end of the line is the value of the userdata
       field in the request.

       Host  helios  responds  with  eight 512-byte packets.  The
       :digit following  the  transaction  ID  gives  the  packet
       sequence  number  in  the  transaction  and  the number in
       parenthesis is the amount of data in the packet, excluding
       the  ATP  header.   The asterisk (*) on packet 7 indicates
       that the EOM bit was set.

       Host jssmag.209 then requests that  packets  3  and  5  be
       retransmitted.  Host  helios resends them, then jssmag.209
       releases the transaction.  Finally,  jssmag.209  initiates
       the  next  request.  The asterisk (*) on the request indicates
 that exactly once (XO) was not set.

       AppleTalk is a registered  trademark  of  Apple  Computer,

   IP Fragmentation    [Toc]    [Back]
       Fragmented Internet datagrams are printed as follows:

       (frag id:size@offset+) (frag id:size@offset)

       The  first  line  indicates there are more fragments.  The
       second indicates this is the last fragment.

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

       The fragment information is output for each fragment.  The
       first  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

       Note  the  following:  Addresses in the second line do not
       include port numbers.  This is because  the  TCP  protocol
       information  is  in  the first fragment and we do not know
       what the port or sequence numbers are when  we  print  the
       later  fragments.   TCP  sequence information in the first
       line is printed as if there were 308 bytes of  user  data;
       however,  there  are  512 bytes (308 in the first fragment
       and 204 in the second).  If you are looking for  holes  in
       the  sequence space or trying to match up acknowledgements
       with packets, this can be misleading.

              A packet with the IP  `do  not  fragment'  flag  is
              marked with a trailing (DF).

   Timestamps    [Toc]    [Back]
       By  default, all output lines are preceded by a timestamp.
       The timestamp is the current clock time in  the  following


       It  is  as  accurate  as the kernel's clock. The timestamp
       reflects the time the kernel first  saw  the  packet.   No
       attempt is made to account for the time difference between
       when the Ethernet interface removed the  packet  from  the
       wire  and  when  the kernel serviced the new packet interrupt.

RESTRICTIONS    [Toc]    [Back]

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

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

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

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

EXAMPLES    [Toc]    [Back]

       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  ftpdata)'
  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'
              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

SEE ALSO    [Toc]    [Back]

       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.

[ Back ]
 Similar pages
Name OS Title
netsnoop IRIX capture and decode network traffic
nifftmt Tru64 Traffic monitoring for the Network Interface Failure Finder (NIFF)
iftcntl Tru64 View and modify network interface traffic control settings
rdump HP-UX incremental file system dump, local or across network
dump HP-UX incremental file system dump, local or across network
vxdump HP-UX incremental VxFS file system dump, local or across network
rvxdump HP-UX incremental VxFS file system dump, local or across network
atc OpenBSD air traffic controller game
atc NetBSD air traffic controller game
mailstats HP-UX print mail traffic statistics
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service