TCPDUMP(1)                                             TCPDUMP(1)

       tcpdump - dump traffic on a network

       tcpdump [ -adeflnNOpqStvxX ] [ -c count ] [ -F file ]
               [ -i interface ] [ -r file ] [ -s snaplen ]
               [ -T type ] [ -w file ] [ expression ]

       Tcpdump  prints  out  the  headers of packets on a network
       interface that match the boolean expression.

       Under SunOS with nit or bpf: To run tcpdump you must  have
       read  access to /dev/nit or /dev/bpf*.  Under Solaris with
       dlpi: You must have read  access  to  the  network  pseudo
       device, e.g.  /dev/le.  Under HP-UX with dlpi: You must be
       root or it must be installed setuid to root.   Under  IRIX
       with  snoop:  You  must  be  root  or it must be installed
       setuid to root.  Under Linux: You must be root or it  must
       be  installed  setuid  to  root.  Under Ultrix and Digital
       UNIX: Once the  super-user  has  enabled  promiscuous-mode
       operation  using  pfconfig(8),  any  user may run tcpdump.
       Under BSD: You must have read access to /dev/bpf*.

       -a     Attempt to convert network and broadcast  addresses
              to names.

       -c     Exit after receiving count packets.

       -d     Dump  the  compiled packet-matching code in a human
              readable form to standard output and stop.

       -dd    Dump packet-matching code as a C program  fragment.

       -ddd   Dump  packet-matching code as decimal numbers (pre-
              ceded with a count).

       -e     Print the link-level header on each dump line.

       -f     Print  `foreign'  internet  addresses   numerically
              rather  than  symbolically (this option is intended
              to get around serious  brain  damage  in  Sun's  yp
              server -- usually it hangs forever translating non-
              local internet numbers).

       -F     Use file as input for the  filter  expression.   An
              additional  expression given on the command line is

       -i     Listen  on  interface.   If  unspecified,   tcpdump
              searches  the  system interface list for the lowest
              numbered, configured up interface (excluding  loop-
              back).   Ties  are  broken by choosing the earliest

                           30 June 1997                         1

TCPDUMP(1)                                             TCPDUMP(1)


       -l     Make stdout line buffered.  Useful if you  want  to
              see the data while capturing it.  E.g.,
              ``tcpdump  -l  |  tee  dat''  or  ``tcpdump  -l   >
              dat  &  tail  -f  dat''.

       -n     Don't convert addresses (i.e., host addresses, port
              numbers, etc.) to names.

       -N     Don't  print  domain  name  qualification  of  host
              names.  E.g., if you give this  flag  then  tcpdump
              will print ``nic'' instead of ``''.

       -O     Do  not  run  the  packet-matching  code optimizer.
              This is useful only if you suspect  a  bug  in  the

       -p     Don't  put  the  interface  into  promiscuous mode.
              Note that the interface  might  be  in  promiscuous
              mode  for  some other reason; hence, `-p' cannot be
              used as an abbreviation for `ether host  {local-hw-
              addr} or ether broadcast'.

       -q     Quick  (quiet?) output.  Print less protocol infor-
              mation so output lines are shorter.

       -r     Read packets from file (which was created with  the
              -w  option).   Standard  input  is  used if file is

       -s     Snarf snaplen bytes of data from each packet rather
              than the default of 68 (with SunOS's NIT, the mini-
              mum is actually 96).  68 bytes is adequate for  IP,
              ICMP,  TCP and UDP but may truncate protocol infor-
              mation  from  name  server  and  NFS  packets  (see
              below).   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  that  taking  larger snapshots both increases
              the amount of time it takes to process packets and,
              effectively, decreases the amount of packet buffer-
              ing.  This may  cause  packets  to  be  lost.   You
              should  limit  snaplen  to the smallest number that
              will capture the protocol information you're inter-
              ested in.

       -T     Force packets selected by "expression" to be inter-
              preted the specified type.  Currently  known  types
              are  rpc  (Remote  Procedure  Call), rtp (Real-Time
              Applications protocol),  rtcp  (Real-Time  Applica-
              tions  control  protocol), vat (Visual Audio Tool),
              and wb (distributed White Board).

                           30 June 1997                         2

TCPDUMP(1)                                             TCPDUMP(1)

       -S     Print absolute, rather than relative, TCP  sequence

       -t     Don't print a timestamp on each dump line.

       -tt    Print an unformatted timestamp on each dump line.

       -v     (Slightly  more)  verbose output.  For example, the
              time to live and type of service information in  an
              IP  packet is printed.  Telnet options are printed.

       -vv    Even more verbose output.  For example,  additional
              fields are printed from NFS reply packets.

       -vvv   Even  more  verbose output.  For example, telnet SB
              ... SE options are printed in full.  With -X telnet
              options are printed in hex as well.

       -w     Write  the  raw packets to file rather than parsing
              and printing them out.  They can later  be  printed
              with  the  -r  option.   Standard output is used if
              file is ``-''.

       -x     Print each packet (minus its link level header)  in
              hex.   The  smaller of the entire packet or snaplen
              bytes will be printed.

       -X     When printing hex, print ascii too.  Thus if -x  is
              also set, the packet is printed in hex/ascii.  This
              is very handy for analysing new protocols.  Even if
              -x  is not also set, some parts of some packets may
              be printed in hex/ascii.

              selects  which  packets  will  be  dumped.   If  no
              expression is given, all packets on the net will be
              dumped.  Otherwise, only packets for which  expres-
              sion is `true' will be dumped.

              The  expression consists of one or more primitives.
              Primitives usually consist of an id (name  or  num-
              ber) preceded by one or more qualifiers.  There are
              three different kinds of qualifier:

              type   qualifiers say what kind  of  thing  the  id
                     name  or  number  refers to.  Possible types
                     are host, net and port.  E.g.,  `host  foo',
                     `net 128.3', `port 20'.  If there is no type
                     qualifier, host is assumed.

              dir    qualifiers  specify  a  particular  transfer
                     direction   to  and/or  from  id.   Possible
                     directions are src, dst, src or dst and  src
                     and  dst.  E.g., `src foo', `dst net 128.3',

                           30 June 1997                         3

TCPDUMP(1)                                             TCPDUMP(1)

                     `src or dst port ftp-data'.  If there is  no
                     dir  qualifier,  src or dst is assumed.  For
                     `null' link layers (i.e. point to point pro-
                     tocols  such  as  slip) the inbound and out-
                     bound qualifiers can be used  to  specify  a
                     desired direction.

              proto  qualifiers  restrict the match to a particu-
                     lar protocol.  Possible protos  are:  ether,
                     fddi,  ip,  arp,  rarp,  decnet, lat, moprc,
                     mopdl, sca, tcp and udp.  E.g.,  `ether  src
                     foo',  `arp  net  128.3', `tcp port 21'.  If
                     there is no proto qualifier,  all  protocols
                     consistent with the type are assumed.  E.g.,
                     `src foo' means `(ip or  arp  or  rarp)  src
                     foo'  (except  the  latter is not legal syn-
                     tax), `net bar' means `(ip or arp  or  rarp)
                     net  bar'  and `port 53' means `(tcp or udp)
                     port 53'.

              [`fddi' is  actually  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 Ether-
              net   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 don't follow the pattern:
              gateway,  broadcast,  less,  greater and arithmetic
              expressions.  All of these are described below.

              More complex filter expressions  are  built  up  by
              using  the  words and, or and not to combine primi-
              tives.  E.g., `host foo and not port  ftp  and  not
              port  ftp-data'.   To save typing, identical quali-
              fier lists can be omitted.  E.g., `tcp dst port ftp
              or  ftp-data or domain' is exactly the same as `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

                           30 June 1997                         4

TCPDUMP(1)                                             TCPDUMP(1)


              host host
                     True if either the IP source or  destination
                     of  the  packet  is  host.  Any of the above
                     host expressions can be prepended  with  the
                     keywords, ip, arp, or rarp as in:
                          ip host host
                     which is equivalent to:
                          ether proto ip and host host
                     If   host   is   a  name  with  multiple  IP
                     addresses, each address will be 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(3N) for
                     numeric format).

              ether src ehost
                     True  if  the  ethernet  source  address  is

              ether host ehost
                     True if either the ethernet source or desti-
                     nation address is ehost.

              gateway host
                     True if the packet used host as  a  gateway.
                     I.e.,  the  ethernet  source  or destination
                     address was host but neither the  IP  source
                     nor  the IP destination was host.  Host must
                     be  a  name  and  must  be  found  in   both
                     /etc/hosts  and /etc/ethers.  (An equivalent
                     expression is
                          ether host ehost and not host host
                     which can be used with either names or  num-
                     bers for host / ehost.)

              dst net net
                     True  if  the  IP destination address of the
                     packet has a network number of net. Net  may
                     be  either  a  name  from /etc/networks or a
                     network   number   (see   networks(4)    for

              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

                           30 June 1997                         5

TCPDUMP(1)                                             TCPDUMP(1)

                     of net.

              net net mask mask
                     True if the IP address matches net with  the
                     specific netmask.  May be qualified with src
                     or dst.

              net net/len
                     True if the IP address matches net a netmask
                     len bits wide.  May be qualified with src or

              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(4P) and udp(4P)).  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  (e.g.,  dst port 513 will print
                     both tcp/login traffic and udp/who  traffic,
                     and  port  domain will print 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.   Any  of  the
                     above port expressions can be prepended with
                     the keywords, tcp or udp, as in:
                          tcp src port port
                     which matches only tcp packets whose  source
                     port is port.

              less length
                     True if the packet has a length less than or
                     equal to length.  This is equivalent to:
                          len <= length.

              greater length
                     True if the packet has a length greater than
                     or equal to length.  This is equivalent to:
                          len >= length.

              ip proto protocol
                     True  if  the  packet  is  an ip packet (see
                     ip(4P)) of protocol type protocol.  Protocol
                     can  be  a  number or one of the names icmp,
                     igrp, udp, nd, or tcp.  Note that the  iden-
                     tifiers tcp, udp, and icmp are also keywords

                           30 June 1997                         6

TCPDUMP(1)                                             TCPDUMP(1)

                     and must be escaped via backslash (\), which
                     is \\ in the C-shell.

              ether broadcast
                     True  if the packet is an ethernet broadcast
                     packet.  The ether keyword is optional.

              ip broadcast
                     True  if  the  packet  is  an  IP  broadcast
                     packet.   It  checks for both the all-zeroes
                     and  all-ones  broadcast  conventions,   and
                     looks up the local subnet mask.

              ether multicast
                     True  if the packet is an ethernet multicast
                     packet.   The  ether  keyword  is  optional.
                     This is shorthand for `ether[0] & 1 != 0'.

              ip multicast
                     True  if  the  packet  is  an  IP  multicast

              ether proto protocol
                     True if the packet is of ether  type  proto-
                     col.   Protocol  can  be  a number or a name
                     like ip, arp, or rarp.  Note  these  identi-
                     fiers  are also keywords and must be escaped
                     via backslash (\).  [In  the  case  of  FDDI
                     (e.g.,  `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.   Tcpdump
                     assumes,  when  filtering  on  the  protocol
                     identifier, that all FDDI packets include an
                     LLC  header,  and  that the LLC header is in
                     so-called SNAP format.]

              decnet src host
                     True if the DECNET source address  is  host,
                     which   may   be  an  address  of  the  form
                     ``10.123'', or a DECNET host name.   [DECNET
                     host  name  support  is  only  available  on
                     Ultrix systems that are  configured  to  run

              decnet dst host
                     True  if  the  DECNET destination address is

              decnet host host
                     True if either the DECNET source or destina-
                     tion address is host.

                           30 June 1997                         7

TCPDUMP(1)                                             TCPDUMP(1)

              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
                     that tcpdump does not currently know how  to
                     parse these protocols.

              tcp, udp, icmp
                     Abbreviations for:
                          ip proto p
                     where p is one of the above protocols.

              expr relop expr
                     True  if  the relation holds, where relop is
                     one of >, <, >=, <=, =, !=, 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 ]
                     Proto is one of ether, fddi, ip, arp,  rarp,
                     tcp,  udp, or icmp, and indicates the proto-
                     col layer for the index operation.  The byte
                     offset,  relative  to the indicated protocol
                     layer, is given by expr.  Size  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[6: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

                           30 June 1997                         8

TCPDUMP(1)                                             TCPDUMP(1)

                     Shell and must be escaped).

                     Negation (`!' or `not').

                     Concatenation (`&&' or `and').

                     Alternation (`||' or `or').

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

              If  an  identifier  is given without a keyword, the
              most recent keyword is assumed.  For example,
                   not host vs and ace
              is short for
                   not host vs and host ace
              which should not be confused with
                   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.

       To print all packets arriving at or  departing  from  sun-
              tcpdump host sundown

       To print traffic between helios and either hot or ace:
              tcpdump host helios and \( hot or ace \)

       To  print  all  IP packets between ace and any host except
              tcpdump ip host ace and not helios

       To print all traffic between  local  hosts  and  hosts  at
              tcpdump net ucb-ether

       To  print  all  ftp traffic through internet gateway snup:
       (note that the expression is quoted to prevent  the  shell
       from (mis-)interpreting the parentheses):
              tcpdump 'gateway snup and (port ftp or ftp-data)'

       To  print  traffic  neither  sourced from nor destined for
       local hosts (if you gateway to one other net,  this  stuff
       should never make it onto your local net).
              tcpdump ip and not net localnet

                           30 June 1997                         9

TCPDUMP(1)                                             TCPDUMP(1)

       To  print the start and end packets (the SYN and FIN pack-
       ets) of each TCP conversation that  involves  a  non-local
              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/replies (i.e., not ping packets):
              tcpdump 'icmp[0] != 8 and icmp[0] != 0"

       The output of tcpdump is protocol dependent.  The  follow-
       ing  gives a brief description and examples of most of the

       Link Level Headers

       If the '-e' option is given,  the  link  level  header  is
       printed  out.   On  ethernets,  the source and destination
       addresses, protocol, and packet length are printed.

       On FDDI networks, the  '-e' option causes tcpdump 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 data-
       grams)  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.

       (N.B.:  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 informa-
       tion are printed out.  The packet type is  printed  first.
       The  three  types are ip, utcp, and ctcp.  No further link
       information is printed for ip packets.  For  TCP  packets,
       the  connection  identifier is printed following the type.
       If the packet is compressed, its encoded header is printed
       out.  The special cases are printed out as *S+n and *SA+n,
       where n is the amount by which  the  sequence  number  (or
       sequence number and ack) has changed.  If it is not a spe-
       cial case, zero or more changes are printed.  A change  is
       indicated  by  U  (urgent pointer), W (window), A (ack), S

                           30 June 1997                        10

TCPDUMP(1)                                             TCPDUMP(1)

       (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

       For  example,  the  following  line shows an outbound com-
       pressed TCP packet, with an  implicit  connection  identi-
       fier; the ack 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/rarp  output  shows  the type of request and its argu-
       ments.  The format is intended  to  be  self  explanatory.
       Here is a short sample 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 says that rtsg sent an  arp  packet  asking
       for  the  ethernet  address  of  internet host csam.  Csam
       replies with its ethernet address (in this example, ether-
       net  addresses are in caps and internet addresses in lower

       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 we had done tcpdump -e, the fact that the first  packet
       is  broadcast  and  the  second is point-to-point would be
              RTSG Broadcast 0806  64: arp who-has csam tell rtsg
              CSAM RTSG 0806  64: arp reply csam is-at CSAM
       For the first packet this says the ethernet source address
       is   RTSG,  the  destination  is  the  ethernet  broadcast
       address,  the  type  field  contained   hex   0806   (type
       ETHER_ARP) and the total length was 64 bytes.

       TCP Packets

       (N.B.:The  following  description assumes familiarity with
       the TCP protocol described in RFC-793.   If  you  are  not
       familiar  with  the protocol, neither this description nor
       tcpdump will be of much use to you.)

       The general format of a tcp protocol line is:
              src > dst: flags data-seqno ack window urgent options
       Src and dst are the source and  destination  IP  addresses
       and  ports.   Flags  are  some  combination  of S (SYN), F
       (FIN), P (PUSH) or R (RST) or a  single  `.'  (no  flags).
       Data-seqno describes the portion of sequence space covered
       by the data in this packet (see example  below).   Ack  is

                           30 June 1997                        11

TCPDUMP(1)                                             TCPDUMP(1)

       sequence number of the next data expected the other direc-
       tion on this connection.  Window is the number of bytes of
       receive buffer space available the other direction on this
       connection.  Urg indicates there is `urgent' data  in  the
       packet.   Options are tcp options enclosed in angle brack-
       ets (e.g., <mss 1024>).

       Src, dst and flags are always present.  The  other  fields
       depend on the contents of the packet's tcp protocol header
       and are output only if appropriate.

       Here is the opening portion of an rlogin 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  says  that  tcp port 1023 on rtsg sent a
       packet to port login on 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.

       Csam  replies  with  a similar packet except it includes a
       piggy-backed ack for rtsg's SYN.  Rtsg  then  acks  csam's
       SYN.   The  `.'  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 pack-
       ets of the conversation, the difference between  the  cur-
       rent  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').  `-S' will override this fea-
       ture, causing the original sequence numbers to be  output.

       On the 6th line, rtsg sends csam 19 bytes of data (bytes 2
       through 20 in the rtsg -> csam side of the  conversation).
       The PUSH flag is set in the packet.  On the 7th line, csam
       says it's received data sent by rtsg up to but not includ-
       ing  byte  21.  Most of this data is apparently sitting in
       the socket buffer since csam's receive window  has  gotten
       19  bytes  smaller.   Csam  also sends one byte of data to

                           30 June 1997                        12

TCPDUMP(1)                                             TCPDUMP(1)

       rtsg in this packet.  On the 8th and 9th lines, csam sends
       two bytes of urgent, pushed data to rtsg.

       If  the snapshot was small enough that tcpdump didn't cap-
       ture the full TCP header, it interprets  as  much  of  the
       header  as  it can and then reports ``[|tcp]'' to indicate
       the remainder could not be  interpreted.   If  the  header
       contains  a  bogus option (one with a length that's either
       too small or  beyond  the  end  of  the  header),  tcpdump
       reports  it  as  ``[bad  opt]'' and does not interpret any
       further options (since it's impossible to tell where  they
       start).   If  the header length indicates options are pre-
       sent but the IP datagram length is not long enough for the
       options to actually be there, tcpdump reports it as ``[bad
       hdr length]''.

       UDP Packets

       UDP format is illustrated by this rwho packet:
              actinide.who > broadcast.who: udp 84
       This says that port who on host actinide sent a udp  data-
       gram 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  des-
       tination port number) and the higher level protocol infor-
       mation  printed.   In  particular,  Domain  Name   service
       requests  (RFC-1034/1035)  and Sun RPC calls (RFC-1050) to

       UDP Name Server Requests

       (N.B.:The following description assumes  familiarity  with
       the Domain Service protocol described in RFC-1035.  If you
       are not familiar with the protocol, the following descrip-
       tion will appear to be written in greek.)

       Name server requests are formatted as
              src > dst: id op? flags qtype qclass name (len)
              h2opolo.1538 > helios.domain: 3+ A? (37)
       Host  h2opolo  asked  the  domain  server on helios for an
       address record (qtype=A) associated  with  the  name  ucb-   The  query  id was `3'.  The `+' indi-
       cates 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 had been anything
       else, it would have been printed between the `3'  and  the
       `+'.   Similarly, the qclass was the normal one, C_IN, and
       omitted.  Any other qclass would have been printed immedi-
       ately after the `A'.

       A few anomalies are checked and may result in extra fields
       enclosed in square  brackets:   If  a  query  contains  an

                           30 June 1997                        13

TCPDUMP(1)                                             TCPDUMP(1)

       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 two and three,
       `[b2&3=x]' is printed, where x is the hex value of  header
       bytes two and three.

       UDP Name Server Responses

       Name server responses are formatted as
              src > dst:  id op rcode flags a/n/au type class data (len)
              helios.domain > h2opolo.1538: 3 3/3/7 A (273)
              helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)
       In  the  first example, helios responds to query id 3 from
       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 was 273 bytes, excluding
       UDP and IP headers.  The  op  (Query)  and  response  code
       (NoError)  were  omitted, as was the class (C_IN) of the A

       In the second example, helios responds to query 2  with  a
       response  code  of  non-existent domain (NXDomain) with no
       answers, one name server and no  authority  records.   The
       `*'  indicates  that the authoritative answer bit was set.
       Since there were no answers, no type, class or  data  were

       Other flag characters that might appear are `-' (recursion
       available, RA, not set) and `|'  (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 snaplen of 68 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.  `-s 128' has worked well for me.

       NFS Requests and Replies

       Sun NFS (Network File System)  requests  and  replies  are
       printed as:
              src.xid > dst.nfs: len op args
              src.nfs > dst.xid: reply stat len op results

              sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165
              wrl.nfs > sushi.6709: reply ok 40 readlink "../var"
              sushi.201b > wrl.nfs:
                   144 lookup fh 9,74/4096.6878 "xcolors"
              wrl.nfs > sushi.201b:

                           30 June 1997                        14

TCPDUMP(1)                                             TCPDUMP(1)

                   reply ok 128 lookup fh 9,74/4134.3150

       In  the first line, host sushi sends a transaction with id
       6709 to wrl (note that 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 han-
       dle (fh) 21,24/10.731657119.  (If one is lucky, as in this
       case,  the file handle can be interpreted as a major,minor
       device number pair, followed by the inode number and  gen-
       eration  number.)   Wrl  replies `ok' with the contents of
       the link.

       In the third line, sushi  asks  wrl  to  lookup  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 an NFS protocol spec.

       If the -v (verbose) flag is given, additional  information
       is printed.  For example:

              sushi.1372a > wrl.nfs:
                   148 read fh 21,11/12.195 8192 bytes @ 24576
              wrl.nfs > sushi.1372a:
                   reply ok 1472 read REG 100664 ids 417/0 sz 29388

       (-v  also  prints the IP header TTL, ID, and fragmentation
       fields, which have been omitted from  this  example.)   In
       the  first  line,  sushi  asks wrl to read 8192 bytes from
       file 21,11/12.195, at  byte  offset  24576.   Wrl  replies
       `ok';  the  packet  shown  on the second line is the first
       fragment of the reply, and hence is only 1472  bytes  long
       (the  other bytes will follow in subsequent fragments, but
       these fragments do not have NFS or even UDP headers and so
       might  not  be printed, depending on the filter expression
       used).  Because the -v flag is given,  some  of  the  file
       attributes  (which  are  returned  in addition to the file
       data) are printed: the file  type  (``REG'',  for  regular
       file),  the file mode (in octal), the uid and gid, and the
       file size.

       If the -v flag is given more than once, even more  details
       are printed.

       Note  that  NFS  requests  are  very large and much of the
       detail won't be printed unless snaplen is increased.   Try
       using `-s 192' to watch NFS traffic.

       NFS reply packets do not explicitly identify the RPC oper-
       ation.   Instead,  tcpdump  keeps  track   of   ``recent''
       requests, and matches them to the replies using the trans-
       action ID.  If a reply does not closely follow the  corre-
       sponding request, it might not be parsable.

                           30 June 1997                        15

TCPDUMP(1)                                             TCPDUMP(1)

       KIP Appletalk (DDP in UDP)

       Appletalk  DDP  packets  encapsulated in UDP datagrams are
       de-encapsulated and dumped as DDP packets (i.e.,  all  the
       UDP   header   information   is   discarded).    The  file
       /etc/atalk.names is used to translate  appletalk  net  and
       node numbers to names.  Lines in this file have the form
              number    name

              1.254          ether
              16.1      icsd-net
              1.254.110 ace
       The  first two lines give the names of appletalk networks.
       The third line gives the name of a particular host (a host
       is distinguished from a net by the 3rd octet in the number
       - a net number must have two octets and a host number must
       have  three  octets.)  The number and name should be sepa-
       rated   by   whitespace    (blanks    or    tabs).     The
       /etc/atalk.names  file  may contain blank lines or comment
       lines (lines starting with a `#').

       Appletalk addresses are printed in the form

     > icsd-net.112.220
              office.2 > icsd-net.112.220
              jssmag.149.235 > icsd-net.2
       (If the /etc/atalk.names doesn't exist or doesn't  contain
       an entry for some appletalk host/net number, addresses are
       printed in numeric form.)  In the first example, NBP  (DDP
       port  2)  on  net 144.1 node 209 is sending to whatever is
       listening on port 220 of net icsd node  112.   The  second
       line  is  the same except the full name of the source node
       is known (`office').  The third line is a send  from  port
       235  on  net  jssmag node 149 to broadcast on the icsd-net
       NBP port (note that the broadcast address (255)  is  indi-
       cated  by a net name with no host number - for this reason
       it's a good idea to keep node names and net names distinct
       in /etc/atalk.names).

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

       NBP packets are formatted like 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 is a name lookup request  for  laserwriters
       sent  by  net  icsd  host 112 and broadcast on net jssmag.
       The nbp id for the lookup is 190.  The second line shows a
       reply for this request (note that it has the same id) from
       host jssmag.209 saying that it has a laserwriter  resource

                           30 June 1997                        16

TCPDUMP(1)                                             TCPDUMP(1)

       named  "RM1140" registered on port 250.  The third line is
       another reply to the same request saying host techpit  has
       laserwriter "techpit" registered on port 186.

       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: 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
       Jssmag.209 initiates transaction id 12266 with host helios
       by requesting up to 8 packets (the `<0-7>').  The hex num-
       ber at the end of the line is the value of the  `userdata'
       field in the request.

       Helios  responds  with  8  512-byte packets.  The `:digit'
       following the transaction id  gives  the  packet  sequence
       number  in the transaction and the number in parens is the
       amount of data in the packet, excluding  the  atp  header.
       The `*' on packet 7 indicates that the EOM bit was set.

       Jssmag.209 then requests that packets 3 & 5 be retransmit-
       ted.  Helios resends them  then  jssmag.209  releases  the
       transaction.    Finally,  jssmag.209  initiates  the  next
       request.   The  `*'  on  the  request  indicates  that  XO
       (`exactly once') was not set.

       IP Fragmentation

       Fragmented Internet datagrams are printed as
              (frag id:size@offset+)
              (frag id:size@offset)
       (The  first  form indicates there are more fragments.  The
       second indicates this is the last fragment.)

       Id is the fragment id.  Size  is  the  fragment  size  (in
       bytes) excluding the IP header.  Offset is this 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 frag info is  printed  after  the  protocol  info.
       Fragments after the first contain no higher level protocol

                           30 June 1997                        17

TCPDUMP(1)                                             TCPDUMP(1)

       header and the frag info is printed after the  source  and
       destination  addresses.   For  example, here is part of an
       ftp from to over a CSNET connec-
       tion that doesn't 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
       There  are  a  couple  of  things  to  note  here:  First,
       addresses in the 2nd  line  don't  include  port  numbers.
       This is because the TCP protocol information is all in the
       first fragment and we  have  no  idea  what  the  port  or
       sequence  numbers  are  when we print the later fragments.
       Second, the tcp sequence information in the first line  is
       printed  as  if there were 308 bytes of user data when, in
       fact, there are 512 bytes (308 in the first frag  and  204
       in  the  second).   If  you  are  looking for holes in the
       sequence space or trying to match up  acks  with  packets,
       this can fool you.

       A  packet with the IP don't fragment flag is marked with a
       trailing (DF).


       By default, all output lines are preceded by a  timestamp.
       The timestamp is the current clock time in the form
       and  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 lag between when
       the ethernet interface removed the packet  from  the  wire
       and when the kernel serviced the `new packet' interrupt.

       traffic(1C), nit(4P), bpf(4), pcap(3)

       Van  Jacobson,  Craig Leres and Steven McCanne, all of the
       Lawrence Berkeley National Laboratory, University of Cali-
       fornia, Berkeley, CA.

       The current version is available via anonymous ftp:


       Please send bug reports to

       NIT  doesn't  let you watch your own outbound traffic, BPF
       will.  We recommend that you use the latter.

       Some attempt should be made to reassemble IP fragments or,
       at  least to compute the right length for the higher level

                           30 June 1997                        18

TCPDUMP(1)                                             TCPDUMP(1)

       Name server inverse queries are not dumped correctly:  The
       (empty) question section is printed rather than real query
       in the answer section.  Some believe that inverse  queries
       are  themselves a bug and prefer to fix the program gener-
       ating them rather than tcpdump.

       Apple Ethertalk DDP packets could be dumped as  easily  as
       KIP  DDP  packets but aren't.  Even if we were inclined to
       do anything to promote the use of Ethertalk  (we  aren't),
       LBL doesn't allow Ethertalk on any of its networks so we'd
       would have no way of testing this code.

       A packet trace that crosses a daylight savings time change
       will give skewed time stamps (the time change is ignored).

       Filters 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 fil-
       ter may inadvertently accept certain packets that  do  not
       properly match the filter expression.

                           30 June 1997                        19

You can also request any man page by name and (optionally) by section:


Use the DEFAULT collection to view manual pages for third-party software.

©1994 Man-cgi 1.15, Panagiotis Christias
©1996-2019 Modified for NetBSD by Kimmo Suominen