Packet Capture, part 2 - Page 2
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.
Using multiple Telnet connections to a host or multiple windows in an X Window session allows you to record in one window while taking actions to generate traffic in another window. This approach can be very helpful in some circumstances.
An alternative is to use telnet to connect to the probe computer. The session could be logged with many of the versions of telnet that are available. Be aware, however, that the Telnet connection will generate considerable traffic that may become part of your log file unless you are using filtering. (Filtering, which is discussed later in this chapter, allows you to specify the type of traffic you want to examine.) The additional traffic may also overload the connection, resulting in lost packets.
bsd1# tcpdump -w outfile &  70260 bsd1# tcpdump: listening on xl0
The command starts tcpdump, prints a process number, and returns the user prompt along with a message that tcpdump has started. You can now enter commands to generate the traffic you are interested in. (You really have a prompt at this point; the message from tcpdump just obscures it.) Once you have generated the traffic of interest, you can terminate tcpdump by issuing a kill command using the process number reported when tcpdump was started. (You can use the ps command if you have forgotten the process number.)
bsd1# kill 70260 153 packets received by filter 0 packets dropped by kernel  Done tcpdump -w outfile
You can now analyze the capture file. (Running tcpdump as a detached process can also be useful when you are trying to capture traffic that might not show up for a while, e.g., RADIUS or DNS exchanges. You might want to use the nohup command to run it in the background.)
Yet another approach is to use the -w option to write the captured data directly to a file. This option has the advantage of collecting raw data in binary format. The data can then be replayed with tcpdump using the -r option. The binary format decreases the amount of storage needed, and different filters can be applied to the file without having to recapture the traffic. Using previously captured traffic is an excellent way of fine-tuning filters to be sure they work as you expect. Of course, you can selectively analyze data captured as text files in Unix by using the many tools Unix provides, but you can't use tcpdump filtering on text files. And you can always generate a text file from a tcpdump file for subsequent analysis with Unix tools by simply redirecting the output. To capture data you might type:
bsd1# tcpdump -w rawfile
The data could be converted to a text file with:
bsd1# tcpdump -r rawfile > textfile
This approach has several limitations. Because the data is being written directly to a file, you must know when to terminate recording without actually seeing the traffic. Also, if you limit what is captured with the original run, the data you exclude is lost. For these reasons, you will probably want to be very liberal in what you capture, offsetting some of the storage gains of the binary format. Clearly, each approach has its combination of advantages and disadvantages. If you use tcpdump very much, you will probably need each from time to time.