If the packet capture is being performed directly on a network server this additional I/O load can adversely affect the operation of the server.Ī solution is required, therefore, that supports file rotation and on-the-fly compression such that uncompressed data is never written to disk.

Every packet ends up being written to disk in uncompressed form, and then later the post-processor has to read back the contents of that file, compress the data, and output a new file, most likely at the same time as yet more uncompressed data is being saved to the next file. The disadvantage of using a post-processor, though, is that it further dramatically increases the disk I/O load. If you are performing continuous packet capture then file rotation is essential, so this method is impractical.

The pipe method however is incompatible with tcpdump’s (and dnscap’s) automatic file rotation feature - there’s no way to close the current file and restart the compression when a new file is opened. The other is to just have the files written out in their normal format, and then use a post-processing script to find (completed) pcap files and compress them. The simplest is to have the capture application write its output to “stdout”, and then pipe that output into the “stdin” of a compression program, e.g.: tcpdump -w - | ( gzip -c > & ) There are two commonly implemented ways of compressing pcap files. For DNS traffic this can typically result in an 80% reduction in file size. The storage requirements often lead to the use of file compression algorithms such as gzip to reduce the amount of disk space needed. One of the major challenges with logging network traffic is that it is very disk I/O intensive.

Tcpdump wireshark pcap format