tcpdump.man

This directory contains source code for tcpdump, a tool for network monitoring and data acquisition

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

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

              144.1.209.2 > icsd-net.112.220
              office.2 > icsd-net.112.220
              jssmag.149.235 > icsd-net.2
       (If  the /etc/atalk.names 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
       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 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
       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 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).

       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)

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

              ftp://ftp.ee.lbl.gov/tcpdump.tar.Z

BUGS
       Please send bug reports to [e-mail].

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