Technical Q&A QA1176

Getting a Packet Trace

Q: I'm trying to debug a network problem. How do I take a packet trace?

A: There are a variety of tools to do this. They are listed below.

FrameSeer

FrameSeer is a shareware packet analyzer that wraps tcpdump in a very nice GUI.

CPA

Cocoa Packet Analyzer is a free native Mac OS X implementation of a network protocol analyzer and packet sniffer.

IPNetMonitorX

IPNetMonitorX is a commercial network troubleshooting toolkit for debugging Internet service problems and optimizing performance.

Wireshark

Wireshark is an open source packet analyzer that has been ported to Mac OS X. Wireshark does require X11.

tcpdump

This command line tool is included with all versions of Mac OS X, and is also available on many other Unix platforms. To get started, try the following command.

sudo tcpdump -i en0 -s 0 -w DumpFile.dmp

Each element of the command line is explained below.

• The sudo command causes tcpdump to run with privileges, which is necessary in order to capture network traffic.

• The -i en0 option tells tcpdump to capture packets on the first Ethernet interface. By default, tcpdump will use the first non-loopback interface it can find (usually en0). For a list of interfaces, type ifconfig -a. Mac OS X 10.1 and later provide packet capture support on PPP, so you can also specify a PPP interface here (for example, -i ppp0).

  Note: The AirPort interface is typically en1. You can get a list of network interface user-visible names and their corresponding BSD-style names by running networksetup -listallhardwareports.

• The -s 0 option requests the full packet rather than just the first 68 bytes.

• The -w DumpFile.dmp parameter tells tcpdump to dump the packets to a file called DumpFile.dmp.

In response to this command, tcpdump will begin to capture packets and put them in the DumpFile.dmp file. When you want to stop capturing, interrupt tcpdump by typing ^C. You can then display the contents of the packets as text using the following command.

tcpdump -s 0 -n -e -x -vvv -r DumpFile.dmp

New elements of the command line are explained below.

• The -n option means that addresses are not converted to domain names, which speeds things up considerably.

• The -e option causes tcpdump to display the link-level header for each packet.

• The -x option causes the contents of the packet to also be displayed in hex.

• The -vvv option makes tcpdump's output as verbose as possible.

• By specifying -r DumpFile.dmp option you tell tcpdump to read packets from the file DumpFile.dmp rather than from a network interface. Note that you don't need privileges to do this, so running tcpdump using sudo is not required.

You can also combine these steps, as shown below, but if you do this you don't get a high-fidelity record of the packets that you captured.

sudo tcpdump -i en0 -s 0 -n -e -x -vvv

You can learn about tcpdump from the online manual and from the book TCP/IP Illustrated, Volume 1: The Protocols, W. Richard Stevens, Addison-Wesley, 1994, ISBN 0-201-63346-9. That book is also an excellent introduction to TCP/IP protocols in general.

Miscellaneous Notes

Loopback issues

You should consult the documentation that comes with your tool for accurate and up-to-date information about its limitations. Some of the tools have problems with packets being transferred to or from the trace machine (the machine running the tool). It is recommended that your trace machine be separate from the machines whose network traffic you're tracing.

On Mac OS X, tcpdump and Wireshark by default, will display bad TCP checksums that will be reported as bad because of TCP checksum offloading - packets sent by the machine running the tracing application are "captured" before being handed to the network adapter, so they don't have the TCP checksum set correctly. These are not fatal problems, as there are ways to turn off the TCP checksum checking in the most recent versions of tcpdump and Wireshark.

Switches and hubs

If you use a separate trace machine, you have to make sure that the trace machine can see the packets of interest. There are two ways to do this:

Connect all of the machines via a hub (rather than a switch) -- These days it is hard to find real hubs. Most 10/100 hubs are actually switches in disguise. However, it is possible to find a 10/100 hub that only switches between the different speed segments (SMC-EZ58xxDS range).

Enable port mirroring -- On most advanced switches it is possible to configure the switch so that all traffic is mirrored to a specific port. To learn more about this, consult the documentation for your switch.

Capture hints from the Wireshark wiki

The Wireshark wiki has some really useful information about how to setup your packet tracing environment.

The Capture Setup Document contains good background information for setting up your network for monitoring.

The Hub Reference Document contains information on various types of hubs. It also mentions switches that appear to be hubs.

The Switch Reference Document contains information on various analysis features found on different models of switches. This document contains information on various analysis features, such as port mirroring, found on different models of switches, including links to on-line documentation for those switches.

Submitting a trace to DTS

If you send a packet trace to DTS, please include the following:

• The name and version of the tool you used to capture the packet trace.

• The system type and OS version of the trace machine.

• If you've used tcpdump, Wireshark, FrameSeer, or Cocoa Packet Analyzer to capture your packet trace, you can send us the packet trace file in its native format. Otherwise, please include a copy of the packet trace in both its native format and, if that native format isn't text, a text export of the trace as well. That way we're guaranteed to be able to read your packet trace.

• For each relevant machine shown in the trace, please describe the following:

  • The machine's role in the network conversation.

  • The system type and OS version.

  • The machine's IP address.

  • The machine's hardware address (also known as the Ethernet address or MAC address).

Document Revision History

Posted: 2008-06-03