Using tcpdump to save captures for analysis in Wireshark

Wireshark is a great network protocol analyser which runs on Linux, Windows and OSX. You can capture data from within Wireshark, but often you need to run captures on remote machines without a graphical desktop and without the ability to install any extra software such as “tshark”. Many, if not most *nix sytems ship with the tcpdump as standard and this can capture data for later analysis in Wireshark.

In its simplest form the command to get TCP dump to capture sufficient data for useful analysis in Wireshark is:

tcpdump -i INTERFACE -s 65535 -w FILENAME


Obviously replacing the INTERFACE and FILEAME placeholders with the network interface you wish to capture from, and the path/filename you wish to capture to.

Auto Rotating Capture Files

Sometimes when capturing data for analysis you dont know quite when an anomaly that requires attention will occur. In these situation leaving the GUI Wireshark capturing for days or weeks is not an option, and even capturing to a single file with tcpdump is unworkable due to the volumes of data involved. Thankfully tcpdump allows you to automatically rotate your capture files and name them by date. When you finally experience some network problem that needs analysis you can just pull the required file of a manageable size from the remote machine and open it in Wireshark.

The following command will rotate the capture file after a certain number of seconds. Maybe 3600 for hour-long capture files or 43200 for 12 hour length captures.

tcpdump -i INTERFACE -G NUM_SECONDS -w 'trace_%Y%m%d-%H%M%S.pcap'

In some situations you may experience unexpectedly large data throughput which could make your hourly capture files so large as to be unmanageable. The -C option lets you set a maximum file-size for each capture file (in millions of bytes, not megabytes!) and adds an incremental number to each file and starts a new file. So to write hour long capture files but limit any individual file to ~650mb:

tcpdump -i eth0 -G 3600 -C 680 -w 'trace_%Y%m%d-%H%M%S.pcap'

Finally, you might need to leave some traces running for weeks or months to catch a very intermittent network fault in your capture files. You could easily fill available disk space up at these lengths of time, so the -W option lets you specify the maximum number of files being captured before rotating and deleting the first capture file, a so very much like a ringbuffer style capture. The example below allows a max filesize of about 65mb and loops every 10 files.:

tcpdump -i eth0 -C 68 -W 10 -w 'ringbuffer-trace.pcap'

A sample of the directory output for this trace which has been running for a while. Notice the times for the .pcap0 and .pcap1 files in this 10 file buffer are newer than the rest as tcpdump had rotated at the 10th file. Also notice the size of .pcap1 is only 9.6mb, this is the file tcpdump is currently writing to up to the 65M limit.

-rw-r--r-- 1 root root  65M 2011-10-16 11:59 ringbuffer-trace.pcap0
-rw-r--r-- 1 root root 9.6M 2011-10-16 12:01 ringbuffer-trace.pcap1
-rw-r--r-- 1 root root  65M 2011-10-16 11:57 ringbuffer-trace.pcap2
-rw-r--r-- 1 root root  65M 2011-10-16 11:57 ringbuffer-trace.pcap3
-rw-r--r-- 1 root root  65M 2011-10-16 11:57 ringbuffer-trace.pcap4
-rw-r--r-- 1 root root  65M 2011-10-16 11:58 ringbuffer-trace.pcap5
-rw-r--r-- 1 root root  65M 2011-10-16 11:58 ringbuffer-trace.pcap6
-rw-r--r-- 1 root root  65M 2011-10-16 11:58 ringbuffer-trace.pcap7
-rw-r--r-- 1 root root  65M 2011-10-16 11:58 ringbuffer-trace.pcap8
-rw-r--r-- 1 root root  65M 2011-10-16 11:58 ringbuffer-trace.pcap9