MultiNet Tech Tip: Interpreting TCPDUMP Output

 

This document explains how to use the MultiNet TCPDUMP utility to troubleshoot sporadic connectivity problems by showing you how to run the TCPDUMP utility and how to interpret resulting output.

Using and Interpreting TCPDUMP

Here are some hints to help you interpret TCPDUMP output. Using the TCPDUMP utility can show you what happens during the TCP/IP conversation. (Be aware the data you collect may consume lots of disk space.)

Issue the TCPDUMP command. For example:

$ multinet tcpdump/hexadecimal/snapshot SIZE=1600

You see the following packet:

  > 14:10:32.52 client.1083 > server.telnet: P 1:2(1) ack 2 win 4096 ...

               4500 0029 4637 0000 1b06 cb12 8087 7d07 E..)F7........}.
               8087 1070 043b 0017 2ab6 92e2 34b2 b724 ...p.;..*...4..$
               5018 1000 ff83 0000 6492 583f 3608      P.......d.X?6.

First there is a header interpreting some of the packet:

  14:10:32.52 client.1083 > server.telnet: P 1:2(1) ack 2 win 4096 ...

It contains the following information:

  • a timestamp (14:10:32.52)
  • source host and port (client and 1083)
  • >
  • destination host and port (server and telnet = 23)
  • :
  • flag indicator, as follows:
    • S - SYNch up for conversation
    • P - PuSH the octets, don't wait for a full packet
    • . - no flags set
    • F - FINish the conversation
    • R - ReSET the coversation
  • :()
    • beginning postion in octet stream
    • ending position in octet stream
    • number of octets in the segment
  • ack number - packet includes acknowledment for this number of octets
  • win number - source is willing to accept up to this number of octets
  • TCP/IP options

Next there is a hexadecimal dump of the packet, with octet values on the left and the ASCII equivalents on the right, modulo printability. The second four bits (5) tells you where the data octets begin.

            4500 0029 4637 0000 1b06 cb12 8087 7d07 E..)F7........}.
            8087 1070 043b 0017 2ab6 92e2 34b2 b724 ...p.;..*...4..$
            5018 1000 ff83 0000 6492 583f 3608      P.......d.X?6.

It displays the entire contents of the packet, including the TCP/IP header. Where the actual data begins, examine the first octet of the packet. The second four bits of that octet (5, here) tells you how many longwords are occupied by the header. So, you can see the date in the example begins 40 octets into the packet.

Applying these generalities to the example packet, you can then say the following:

  • At 2:10:32.52 P.M., the client immediately sent one octet (the second in its octet stream)
  • from port 1083
  • to the TELNET port (23) on the server.
  • At the same time the client acknowledged two octets received from the server
  • and stated an ability to accept up to 4,096 octets in incoming packets.
  • There are no TCP/IP options.
  • The size of the TCP/IP header is five longwords.
           4500 0029 4637 0000 1b06 cb12 8087 7d07 E..)F7........}.
           8087 1070 043b 0017 2ab6 92e2 34b2 b724 ...p.;..*...4..$
           5018 1000 ff83 0000 6492 583f 3608      P.......d.X?6.
                                           ^
    
  • The data octets start at the 6 in 6492 where the caret (^) is pointing, above.
  • There is only one data octet (d = %X64).
  • The rest of the data displayed results from garbage left in the buffer from previous packets.