Packet Capture, part 2 - Page 3

In this segment from the O'Reilly book, Network Troubleshooting Tools, you will learn all abut how to use the tcpdump in relation to packet capturing.

 By O'Reilly Press
Page 3 of 10   |  Back to Page 1
Print Article

1.4.2. tcpdump Options

A number of command-line options are available with tcpdump. Roughly speaking, options can be separated into four broad categories -- commands that control the program operations (excluding filtering), commands that control how data is displayed, commands that control what data is displayed, and filtering commands. We will consider each category in turn. Controlling program behavior

This class of command-line options affects program behavior, including the way data is collected. We have already seen two examples of control commands, -r and -w. The -w option allows us to redirect output to a file for later analysis, which can be extremely helpful if you are not sure exactly how you want to analyze your data. You can subsequently play back capture data using the -r option. You can repeatedly apply different display options or filters to the data until you have found exactly the information you want. These options are extremely helpful in learning to use tcpdump and are essential for documentation and sharing.

If you know how many packets you want to capture or if you just have an upper limit on the number of packets, the -c option allows you to specify that number. The program will terminate automatically when that number is reached, eliminating the need to use a kill command or Ctrl-C. In the next example, tcpdump will terminate after 100 packets are collected:

bsd1# tcpdump -c100

While limiting packet capture can be useful in some circumstances, it is generally difficult to predict accurately how many packets need to be collected.

If you are running tcpdump on a host with more than one network interface, you can specify which interface you want to use with the -i option. Use the command ifconfig -a to discover what interfaces are available and what networks they correspond to if you aren't sure. For example, suppose you are using a computer with two class C interfaces, xl0 with an IP address of and xl1 with an IP address of Then, to capture traffic on the network, you would use the command:

bsd1# tcpdump -i xl1

Without an explicitly identified interface, tcpdump defaults to the lowest numbered interface.

The -p option says that the interface should not be put into promiscuous mode. This option would, in theory, limit capture to the normal traffic on the interface -- traffic to or from the host, multicast traffic, and broadcast traffic. In practice, the interface might be in promiscuous mode for some other reason. In this event, -p will not turn promiscuous mode off.

Finally, -s controls the amount of data captured. Normally, tcpdump defaults to some maximum byte count and will only capture up to that number of bytes from individual packets. The actual number of bytes depends on the pseudodevice driver used by the operating system. The default is selected to capture appropriate headers, but not to collect packet data unnecessarily. By limiting the number of bytes collected, privacy can be improved. Limiting the number of bytes collected also decreases processing and buffering requirements.

If you need to collect more data, the -s option can be used to specify the number of bytes to collect. If you are dropping packets and can get by with fewer bytes, -s can be used to decrease the number of bytes collected. The following command will collect the entire packet if its length is less than or equal to 200 bytes:

bsd1# tcpdump -s200

Longer packets will be truncated to 200 bytes.

If you are capturing files using the -w option, you should be aware that the number of bytes collected will be what is specified by the -s option at the time of capture. The -s option does not apply to files read back with the -r option. Whatever you captured is what you have. If it was too few bytes, then you will have to recapture the data.

This article was originally published on Nov 13, 2001
Get the Latest Scoop with Networking Update Newsletter