Limit Size

Table of Contents

Quicklinks: Packetlife: Long Captures

Saving space is as simple as learning your -abcs!

Running Out of Space

When capturing, *shark will save packets to a file. If you specify a file to save to with -w, then it will be that one. Otherwise, a temporary file is created and located somewhere.

If you are taking a long continuous capture, then space will eventually become a concern for this capture file. There are four ways to limit the size of your capture.

Each option is linked to the appropriate section on tshark’s manpage:

• -a condition:NUM: Stop capture after duration:NUM (seconds), files:NUM, filesize:NUM (kB), or packets:NUM. files condition requires -w.
• -b condition:NUM: Rotate to a new file after duration:NUM (seconds), interval:NUM (seconds), files:NUM, filesize:NUM (kB), or packets:NUM. Requires -w.
• -c NUM: Stop of after N packets. -c NUM <=> -a duration:NUM.
• -s NUM: Chop each packet at NUM bytes (SnapLen). 0 is read as the max, 262144. If used before -i, can be per interface.

For -a and -b, the colon is required as part of the condition. Multiple -a and -b options can be present.

Example: Using a Ringbuffer and Autostop Condition

Go big or go home! In this example, we’re using all of the -a and -b options that don’t interfere with each other.

[-a] This capture will stop after one of

• 100s
• after 10 files are created with a -b option
• after the total capture size is > 10MB
• after capturing 10000 packets

[-b] This capture rotates

• after 100s
• overwrites 1st after writing to 1000th file
• the file reaches 1024KB in size
• after writing 20 packets.

In this example, I used a speedtest website to generate a bunch of fake traffic.

We’re using the unix utility time in order to see whether the duration stop condition was hit.

bash-5.0$ time dumpcap -a duration:100 \
                       -a files:10 \
                       -a filesize:10000 \
                       -a packets:10000 \
                       -b duration:100 \
                       -b files:1000 \
                       -b filesize:1024 \
                       -b packets:20 \
                       -w file.pcap \
Capturing on 'Wi-Fi: en0'
File: file_00001_20190806045012.pcap
Packets: 19 File: file_00002_20190806045015.pcap
Packets: 36 File: file_00003_20190806045016.pcap
Packets: 48 File: file_00004_20190806045019.pcap
Packets: 48 File: file_00005_20190806045019.pcap
Packets: 91 File: file_00006_20190806045020.pcap
Packets: 117 File: file_00007_20190806045022.pcap
Packets: 139 File: file_00008_20190806045025.pcap
Packets: 151 File: file_00009_20190806045026.pcap
Packets: 168 File: file_00010_20190806045027.pcap
Packets captured: 200
Packets received/dropped on interface 'Wi-Fi: en0':
 ↪ 200/3 (pcap:0/dumpcap:0/flushed:3/ps_ifdrop:0) (98.5%)

real	0m15.384s
user	0m0.030s
sys	0m0.057s

As we can see, the autostop condition we hit was not time, but number of files. We can verify this by listing the 10 files in this directory.

bash-5.0$ ls
file_00001_20190806045012.pcap	file_00006_20190806045020.pcap
file_00002_20190806045015.pcap	file_00007_20190806045022.pcap
file_00003_20190806045016.pcap	file_00008_20190806045025.pcap
file_00004_20190806045019.pcap	file_00009_20190806045026.pcap
file_00005_20190806045019.pcap	file_00010_20190806045027.pcap

The last file should have completely filled up to the max of 20 packets, triggering capture stop. And we see exactly that.

bash-5.0$ tshark -r file_00010_20190806045027.pcap | wc -l
20

Example: Using a Snaplen

Also known as Packet Slicing, taking a snaplen saves space by chopping off excess bytes. Let’s say that we want to capture only up to the end of the UDP header in IPv6 packets in an ethernet network with no vlans. Because we can use a capture filter for ipv6 and udp, we will (-f “ip6 and udp”).

• Ether header: 14B
• IPv6 header: 40B
• UDP header: 8B

14B + 40B + 8B = 62B

Snaplen of 62B -> -s 62. To verify that we’re chopping at the right length, let’s print all values in the UDP header (ports, length, and checksum) as well. Our final command would look something like this:

bash$  tshark -f 'ip6 and udp' -s 62 -c 1 -w ipv6_udp.pcapng -T fields \
              -e udp.srcport -e udp.dstport -e udp.length -e udp.checksum
Capturing on 'Wi-Fi: en0'
47579   10001	156 0x0000e5cb
1 packet captured

The ports, length, and checksum were all printed so we got all of the UDP fields we care about.

Eyeballing it, this looks like a very respectable 62 bytes.

bash-5.0$ tshark -r ipv6_udp.pcapng -x
0000  33 33 00 00 00 01 f0 9f c2 33 28 e3 86 dd 60 00   33.......3(...`.
0010  00 00 00 9c 11 01 fe 80 00 00 00 00 00 00 f2 9f   ................
0020  c2 ff fe 33 28 e3 ff 02 00 00 00 00 00 00 00 00   ...3(...........
0030  00 00 00 00 00 01 b9 db 27 11 00 9c e5 cb         ........'.....

Given that we have the UDP length, we can also verify that we captured exactly 8 bytes of UDP header. The UDP length includes 8B for header, so UDP payload is 156-8=148. The total packet length should thus with snaplen 62+148 = 210. The filter for the length at capture is “frame.len” whereas “frame.cap_len” should document the captured length.

tshark -r ipv6_udp.pcapng -T fields -e frame.len -e frame.cap_len
210	62

Sure enough, we see the expected values. Packet used in example.

Running Out of Bandwidth

For both tshark, dumpcap, and tcpdump, you can limit the external DNS lookups that are automatically performed to add context to text output.

• **-n**: Disable all name resolutions

Running Out of Time

Tshark can limit the capture’s size before it started! --time-travel will start working whenever it will have been implemented. In the meantime, start your capture with the correct flags.

Further Reading

• Packetlife, Long Captures
• GE, How to use Wireshark for long duration captures