The utilities above are great aids in resolving network faults. They all troubleshoot faulty connections between networks and computers, and in determining what applications are running over a network.

It has to be pointed out that packets contain more than just network-related information like the source and destination addresses; they also are the very envelopes which contain e-mail messages, instant-messaging conversations, database logins and the like. Using a tool like tcpdump will often show sensitive data and legal or workplace privacy constraints must be respected. Also note that tcpdump can only report on packets that flow through your computer's network segment; you can't listen in on remote networks. There's a big section on this in the tcpdump FAQ.

Every packet holds header data, content and a checksum. The checksum helps ensure the packet was received intact. There's no end of useful purposes. You may find an application - be it a web browser, custom software, a telnet session or whatever - cannot connect to a remote computer. ping and traceroute will show if there's any connectivity problems.

tcpdump however will show exactly what's going on at every stage of the interaction between the two machines giving far more finely-grained and low-level understanding. For example, you may find that the remote computer is reachable but is not actually being sent any connection attempts; digging further, you discover the source computer is attempting to use DNS to lookup the remote IP address but is not getting a response and hence the problem is DNS-related and nothing to do with the actual protocol being used to connect the machines.

By default, tcpdump lists the hostnames participating in the conversation. This is helpful but as it involves a DNS lookup each time, it can degrade performance. Use the -n flag to prohibit this behaviour and just list IP addresses instead.

For fast (and relatively clean) output, tcpdump also just lists the first 68 bytes of information in each packet. This shows most all the header data but may not be enough if you're looking for something specific. In that case, use the -s flag followed by a number to instruct tcpdump to display more. As the MTU of an Ethernet segment is 1,500 bytes, a common use is -s 1500.

Even so, the data is presented in a fairly raw format, requiring expertise to understand its contents. Use the -v (verbose) flag to have tcpdump annotate its own output, explaining the protocols being used and the direction the traffic is flowing. Use -vv for even more verbose information! By contrast, use -q to have tcpdump be fairly quiet and print minimal information per screen line.

No matter how you structure the output, it'll most likely fly past too quickly to readily decipher anyhow. There's two options here. One is to use the -w flag followed by a filename to have tcpdump send its output to a disk file for later analysis. Use -r followed by the same filename to reload and display the saved data.

The second option is to filter the data so tcpdump only displays packets which match what you're seeking for. Some of the most useful filters, which all follow on the command-line, are:

src addr - source IP address must match addr
dest addr - destination IP address must match addr
host addr - either the source or destination IP addresses match addr
src port port - source port must match port. The port can be numeric or the well-known name of a port as listed in /etc/services
dest port port - destination port must match port
port port - either the source or destination port must match port
icmp - packet must be an ICMP packet
tcp - packet must be a TCP packet
UDP - packet must be a UDP packet

Some example commands are tcpdump -q host www.cisco.com to view quick information on all traffic to or from www.cisco.com, or tcpdump -xs 1500 port 80 to view the entire packet for all Web traffic.