Software Porting & Archive Centre For HP-UX



 TCPDUMP(1)                                                       TCPDUMP(1)
                                30 June 1997



 NAME
      tcpdump - dump traffic on a network

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

 DESCRIPTION
      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*.

 OPTIONS
      -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  (preceded  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 ignored.

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

      -l   Make stdout line buffered.  Useful if you want to  see  the  data
           while capturing it.  E.g.,



                                    - 1 -       Formatted:  October 24, 1999






 TCPDUMP(1)                                                       TCPDUMP(1)
                                30 June 1997



           ``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
           ``nic.ddn.mil''.

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

      -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 information 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 minimum is actually 96).  68
           bytes is adequate for IP, ICMP, TCP  and  UDP  but  may  truncate
           protocol  information  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 protocol 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 buffering.  This may cause packets to be lost.
           You should limit snaplen to the smallest number that will capture
           the protocol information you're interested in.

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

      -S   Print absolute, rather than relative, TCP sequence numbers.

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



                                    - 2 -       Formatted:  October 24, 1999






 TCPDUMP(1)                                                       TCPDUMP(1)
                                30 June 1997



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

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

       expression
           selects which packets will be dumped.  If no expression is given,
           all  packets  on the net will be dumped.  Otherwise, only packets
           for which expression is `true' will be  dumped.   The  expression
           consists of one or more primitives. Primitives usually consist of
           an id (name or number) 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', `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
                protocols  such as slip) the inbound and outbound qualifiers
                can be used to specify a desired direction.

           proto
                qualifiers restrict the  match  to  a  particular  protocol.
                Possible  protos  are:  ether,  fddi, ip, arp, rarp, decnet,
                lat, sca, moprc, mopdl, 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  syntax),  `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 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 don't follow the pattern:
                gateway,   broadcast,   less,   greater    and    arithmetic



                                    - 3 -       Formatted:  October 24, 1999






 TCPDUMP(1)                                                       TCPDUMP(1)
                                30 June 1997



                expressions.   All  of  these  are  described  below.   More
                complex filter expressions are built up by using  the  words
                and,  or and not to combine primitives.  E.g., `host foo and
                not port ftp  and  not  port  ftp-data'.   To  save  typing,
                identical  qualifier  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 host.

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

           ether host ehost
                True if either the ethernet source or destination address is
                ehost.

           gateway host
                True if the packet  used  host  as  a  gateway.   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 numbers  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



                                    - 4 -       Formatted:  October 24, 1999






 TCPDUMP(1)                                                       TCPDUMP(1)
                                30 June 1997



                /etc/networks or  a  network  number  (see  networks(4)  for
                details).

           src net net
                True if the IP source address of the packet  has  a  network
                number of net.

           net net
                True if either the IP source or destination address  of  the
                packet has a network number of net.

           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.

           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



                                    - 5 -       Formatted:  October 24, 1999






 TCPDUMP(1)                                                       TCPDUMP(1)
                                30 June 1997



                type protocol.  Protocol can be a number or one of the names
                icmp, igrp, udp, nd, or tcp.  Note that the identifiers tcp,
                udp,  and  icmp  are  also  keywords and must be escaped via
                backslash (\), which is \\ in the C-shell.

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

           ip broadcast
                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 packet.

           ether proto protocol
                True if the packet is of ether type protocol.  Protocol  can
                be  a  number  or  a name like ip, arp, or rarp.  Note these
                identifiers are  also  keywords  and  must  be  escaped  via
                backslash  (\).   [In the case of FDDI (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.]

           decnet dst host
                True if the DECNET destination address is host.

           decnet host host
                True if either the DECNET source or destination  address  is
                host.

           ip, arp, rarp, decnet
                Abbreviations for:
                     ether proto p
                where p is one of the above protocols.



                                    - 6 -       Formatted:  October 24, 1999






 TCPDUMP(1)                                                       TCPDUMP(1)
                                30 June 1997



           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  protocol  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 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,



                                    - 7 -       Formatted:  October 24, 1999






 TCPDUMP(1)                                                       TCPDUMP(1)
                                30 June 1997



                     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.

 EXAMPLES
      To print all packets arriving at or departing from sundown:
           tcpdump host sundown
      To print traffic between helios and either hot or ace:
           tcpdump host helios and \( hot or ace \)
      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: (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
      To print the start and end packets (the SYN and FIN packets)  of  each
      TCP conversation that involves a non-local 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/replies  (i.e.,
      not ping packets):
           tcpdump 'icmp[0] != 8 and icmp[0] != 0"

 OUTPUT FORMAT
      The output of tcpdump is protocol dependent.  The  following  gives  a
      brief description and examples of most of the formats.


      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



                                    - 8 -       Formatted:  October 24, 1999






 TCPDUMP(1)                                                       TCPDUMP(1)
                                30 June 1997



      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.  (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 information 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 special case, zero or  more  changes  are  printed.   A
      change  is  indicated  by  U  (urgent pointer), W (window), A (ack), 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.  For example, the following line
      shows  an  outbound compressed TCP packet, with an implicit connection
      identifier; 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
      arguments.   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, ethernet addresses are in caps  and
      internet  addresses in lower case).  This would look less redundant if
      we had done tcpdump -n:
           arp who-has 128.3.254.6 tell 128.3.254.68
           arp reply 128.3.254.6 is-at 02:07:01:00:01:c4
      If we had done tcpdump -e, the fact that the first packet is broadcast
      and the second is point-to-point would be visible:

           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.





                                    - 9 -       Formatted:  October 24, 1999






 TCPDUMP(1)                                                       TCPDUMP(1)
                                30 June 1997



      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
      sequence number of the next data expected the other direction 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 brackets (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  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').  `-S' will override this feature, 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
      including byte 21.  Most of this data is  apparently  sitting  in  the



                                   - 10 -       Formatted:  October 24, 1999






 TCPDUMP(1)                                                       TCPDUMP(1)
                                30 June 1997



      socket buffer since csam's receive window has gotten 19 bytes smaller.
      Csam also sends one byte of data to 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 capture 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 present 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 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/1035) and Sun RPC calls (RFC-1050) to NFS.

      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  description
      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? ucbvax.berkeley.edu. (37)

      Host h2opolo asked the domain server on helios for an  address  record
      (qtype=A)  associated with the name ucbvax.berkeley.edu.  The query id
      was `3'.  The `+' 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 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 immediately after the `A'.  A few 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 two and
      three, `[b2&3=x]' is printed, where x is the hex value of header bytes
      two and three.




                                   - 11 -       Formatted:  October 24, 1999






 TCPDUMP(1)                                                       TCPDUMP(1)
                                30 June 1997



      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 128.32.137.3 (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  128.32.137.3.   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 record.  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
      printed.  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:
                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
      handle (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 generation 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



                                   - 12 -       Formatted:  October 24, 1999






 TCPDUMP(1)                                                       TCPDUMP(1)
                                30 June 1997



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


      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  separated   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
           net.host.port

           144.1.209.2 > icsd-net.112.220
           office.2 > icsd-net.112.220



                                   - 13 -       Formatted:  October 24, 1999






 TCPDUMP(1)                                                       TCPDUMP(1)
                                30 June 1997



           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 indicated 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 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 example:
           jssmag.209.165 > helios.132: atp-req  12266<0-7> 0xae030001
           helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
           helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
           helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
           helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
           helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000
           helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
           helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
           helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
           jssmag.209.165 > helios.132: atp-req  12266<3,5> 0xae030001
           helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
           helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
           jssmag.209.165 > helios.132: atp-rel  12266<0-7> 0xae030001
           jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002

      Jssmag.209  initiates  transaction  id  12266  with  host  helios   by
      requesting  up  to 8 packets (the `<0-7>').  The hex number 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



                                   - 14 -       Formatted:  October 24, 1999






 TCPDUMP(1)                                                       TCPDUMP(1)
                                30 June 1997



      the atp header.  The `*' on packet 7 indicates that the  EOM  bit  was
      set.   Jssmag.209  then  requests that packets 3 & 5 be retransmitted.
      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  header  and  the  frag  info is printed after the source and
      destination addresses.  For example, here  is  part  of  an  ftp  from
      arizona.edu  to  lbl-rtsg.arpa  over  a  CSNET connection 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).

      Timestamps By default, all output lines are preceded by  a  timestamp.
      The timestamp is the current clock time in the form
           hh:mm:ss.frac
      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.

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





                                   - 15 -       Formatted:  October 24, 1999






 TCPDUMP(1)                                                       TCPDUMP(1)
                                30 June 1997



 AUTHORS
      Van Jacobson, Craig Leres and Steven  McCanne,  all  of  the  Lawrence
      Berkeley  National Laboratory, University of California, Berkeley, CA.
      The current version is available via anonymous ftp:
           ftp://ftp.ee.lbl.gov/tcpdump.tar.Z

 BUGS
      Please send bug reports to tcpdump@ee.lbl.gov.  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
      protocol.  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 generating 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  filter  may  inadvertently  accept  certain  packets  that do not
      properly match the filter expression.




























                                   - 16 -       Formatted:  October 24, 1999



Software Porting & Archive Centre For HP-UX