@ Additional Network TCP/IP Information


There are several other packet headers that don't quite follow the previous description:

DNS Name Server Requests and Responses

Port #53 is a DNS name server , there is no flag in these headers. An ID # is in the flag field. (see later tcpdump man pages) There are quite a few of these headers. E.G.

10:35:41.552679 2.0.256.256.53 > 10.0.256.256.53: 33259 [b2&3=0x30] (32)

33259 is the ID #

IP Fragmentation

For various reasons this can happen to a packet. In this case there are no port numbers, and tcp flags. (see later man pages).

"Bytes missing"

There are several of these lines in the data sets. A problem in capturing the data caused this and these headers should be ignored.

Some Related Portions of the TCPDUMP Man Pages

       src > dst: flags data-seqno ack window urgent options

  The fields represent the following:

  src 
      The destination IP addresses and ports.

  dst 
      The destination IP addresses and ports.

  flags
      The sum combination of S (SYN), F (FIN), P (PUSH) or R (RST) or a single period (.) for no flags.

  data-seqno
      The portion of sequence space covered by the data in this packet (see the following example).

  ack 
      The sequence number of the next data expected from the other direction on this connection.

  window
      The number of bytes of receive buffer space available from the other direction on this connection.

  urg 
      Indicates there is urgent data in the packet.

  options
      The TCP options enclosed in angle brackets. For example,
           
      The src, dst, and flags fields are always present.  The other fields
      depend on the contents of the packet's TCP protocol header and are out-
      put only if appropriate.

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

      rtsg.1023 > csam.login: S 768512:768512(0) win 4096 
      csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 

      rtsg.1023 > csam.login: . ack 1 win 4096
      rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
      csam.login > rtsg.1023: . ack 2 win 4096
      rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
      csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
      csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
      csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1

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

  Host csam replies with a similar packet except it includes a piggy-backed
  ack for the SYN sent by rtsg.  Host rtsg then sends an ack reply to the SYN
  sent by csam.  The period (.) means no flags were set.  The packet 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
  packets of the conversation, the difference between the current packet's
  sequence number and this initial sequence number is printed.  This means
  that sequence numbers after the first can be interpreted as relative byte
  positions in the conversation's data stream (with the first data byte each
  direction being 1).  The -S flag overrides this feature, causing the origi-
  nal sequence numbers to be output.

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

  UDP Packets

  The UDP format is illustrated by the following rwho packet:

       actinide.who > broadcast.who: udp 84

  This line of output indicates that port who on host actinide sent a UDP
  datagram to port who on host broadcast, the Internet broadcast address.
  The packet contained 84 bytes of user data.

  Some UDP services are recognized (from the source or destination port num-
  ber) and the higher level protocol information printed.  In particular,
  Domain Name service requests (RFC 1034 and RFC 1035) and Sun RPC calls (RFC
  1050) to NFS.

 UDP Name Server Requests

  The following description assumes familiarity with the Domain Service pro-
  tocol described in RFC-1035.

  Name server requests are formatted as follows:

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

  For example:

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

  Host h2opolo queried the domain server on host helios for an address record
  (qtype=A) associated with the name ucbvax.berkeley.edu. The query ID was 3.
  The plus sign (+) indicates the recursion desired flag was set.  The query
  length was 37 bytes, not including the UDP and IP protocol headers.  The
  query operation was the normal one, Query, so the op field was omitted.  If
  the op field had been anything else, it would have been printed between the
  3 and the plus sign (+).  Similarly, the qclass was the normal one, C_IN,
  and omitted.  Any other qclass would have been printed immediately after
  the A.

  A following anomalies are checked and may result in extra fields enclosed
  in square brackets:

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

    o  If any of the response bits are set (AA, RA or rcode) or any of the
       `must be zero' bits are set in bytes and 3, [b2&3=x] is printed, where
       x is the hex value of header bytes 2 and 3.

  UDP Name Server Responses

  Name server responses are formatted as follows:

       src > dst:  id op rcode flags a/n/au type class data (len)

  For example:

       helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
       helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)

  In the first example, host helios responds to query ID 3 from host h2opolo
  with 3 answer records, 3 name server records, and 7 authority records.  The
  first answer record is type A (address) and its data is Internet address
  128.32.137.3.  The total size of the response is 273 bytes, excluding UDP
  and IP headers.  The op (Query) and response code (NoError) are omitted, as
  is the class (C_IN) of the A record.
      
  In the second example, host helios responds to query 2 with a response code
  of nonexistent domain (NXDomain) with no answers, one name server and no
  authority records.  The asterisk (*) indicates that the authoritative
  answer bit is set.  Since there are no answers, no type, class or data are
  printed.
  Note that name server requests and responses tend to be large, and the
  default value of snaplen, 96 bytes,  may not capture enough of the packet
  to print.  Use the -s flag to increase the snaplen if you need to seriously
  investigate name server traffic.

  NFS Requests and Replies

  NFS requests and replies are printed as follows:
      
      src.xid > dst.nfs: len op args
      src.nfs > dst.xid: reply stat len op results

  For example:

      sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.731657119
      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 host wrl
  (the number following the src host is a transaction ID, not the source
  port).  The request was 112 bytes, excluding the UDP and IP headers.  The
  operation was a readlink (read symbolic link) on file handle (fh)
  21,24/10.731657119.  (In some cases, the file handle can be interpreted as
  a major and minor device number pair, followed by the inode number and gen-
  eration number.)  Host wrl replies ok with the contents of the link.

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

  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

  (The -v flag also prints the IP header TTL, ID, and fragmentation fields,
  that have been omitted from this example.)  In the first line, host sushi
  asks host wrl to read 8192 bytes from file 21,11/12.195, at byte offset
  24576.  Host Wrl replies ok; the packet shown on the second line is the
  first fragment of the reply, and therefore is only 1472 bytes long.  (The
  other bytes will follow in subsequent fragments, but these fragments do not
  have NFS or UDP headers and so might not be printed, depending on the fil-
  ter expression used.)  Because the -v flag is given, some of the file
  attributes (that 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 is not printed
  unless the value of 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 corre-
  sponding request, it might not be parsable.

  NFS and Sun are registered trademarks of Sun Microsystems, Inc.



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

 IP Fragmentation

  Fragmented Internet datagrams are printed as follows:
      
      (frag id:size@offset+)
      (frag id:size@offset)

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

  The following list explains the fields:

  id  
      The fragment ID

  size
      The fragment size (in bytes) excluding the IP header

  offset
      The fragment's offset (in bytes) in the original datagram
  The fragment information is output for each fragment.  The first fragment
  contains the higher level protocol header and the fragment information is
  printed after the protocol information.  Fragments after the first contain
  no higher level protocol header and the fragment information is printed
  after the source and destination addresses.  The following example shows
  part of an FTP session from arizona.edu to lbl-rtsg.arpa over a CSNET
  connection that does not appear to handle 576 byte datagrams:

      arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096
      (frag 595a:328@0+)
      arizona > rtsg: (frag 595a:204@328)
      rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560

  Note the following:

    o  Addresses in the second line do not include port numbers.  This is
       because the TCP protocol information is in the first fragment and we
       do not know what the port or sequence numbers are when we print the
       later fragments.

  Timestamps

  By default, all output lines are preceded by a timestamp.  The timestamp is
  the current clock time in the following form:
      
      hh:mm:ss.frac

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



Copyright ©1996-2001 by the Institute for Visualization and Perception Research. All rights reserved.

Please, send comments and/or questions to Dr. Georges Grinstein.
Last update: April 4, 2001