skip to content

How would you run dumpcap for a two-day hunt for intermittent latency on a branch link so the capture never fills the disk?

level: middleimportance: must knowfreq 24%

answer

  1. many files instead of one
  2. the oldest file goes first
  3. -b takes one criterion each
  4. kB, not MB
  5. always give -w

basics

~20 s

Run dumpcap headless with -w and a ring buffer, for example -b filesize:500000 -b files:96: it switches files every 500 MB and deletes the oldest once 96 exist, capping disk use at about 48 GB while the latest traffic stays on disk.

solid answer

~40 s

Use dumpcap rather than the GUI, write to a permanent file with `-w`, and add a ring buffer: `-b filesize:500000 -b files:96` switches to a new file every 500,000 kB (500 MB) and, once 96 files exist, deletes the oldest each time, so disk use is capped near 48 GB. Each `-b` takes one criterion; `duration:` or `interval:` switch on time instead, and `files:` needs at least one switch criterion. Size it from the peak captured rate: the cap divided by that rate is how far back the evidence reaches, so someone must copy out the files around the stall before the ring overwrites them. Leaving out `-w` is the classic mistake: dumpcap complains, turns the ring buffer off and writes one temporary file in $TMPDIR that can grow until the disk fills.

code

bash · 3 lines
bash
dumpcap -i eth1 -B 64 \
  -b filesize:500000 -b files:96 \
  -w /srv/capture/branch-wan.pcapng

go deeper

for a junior

Recall that long captures should be split into several files, that a ring buffer keeps only the newest ones, and that dumpcap, not the GUI, runs long captures.

for a middle

Explain the -b criteria and their units, why files: needs a switch criterion, what happens without -w, and how file boundaries cut connection context.

for a senior

Show how you size a ring from the peak captured rate, protect the evidence window before it is overwritten, and keep the capture from fighting itself over CPU and disk.

for a principal

Frame long-running capture as a standing capability: retention windows per site, who may collect the files, and how capture data containing user traffic is stored and deleted.

## Why a long capture needs a ring buffer A two-day capture on a busy branch link can produce hundreds of gigabytes. As a single file it grows until the disk is full, and a file of several hundred megabytes is already slow to open. dumpcap's **multiple-files mode** (`-b`) splits the capture into a series of files; adding `files:` turns that series into a **ring buffer** that removes the oldest file whenever it needs a new one. Disk use is then bounded, and the most recent traffic is always on disk — exactly what an intermittent fault needs, because you only know which minutes matter after the stall has happened. ## The -b criteria | Criterion | Effect | Notes | |---|---|---| | `filesize:N` | next file when this one reaches N kB | kB means 1000 bytes; limit 2 TB | | `duration:N` | next file after N seconds | fractions such as 0.5 allowed | | `interval:N` | next file when the clock is a multiple of N seconds | 3600 switches on the hour; not combinable with `duration:` | | `packets:N` | next file after N packets | | | `files:N` | keep N files, then delete the oldest | must be below 100000; needs a switch criterion | | `printname:F` | print each closed file's name to F | `stdout`, `-` or `stderr` | Each `-b` takes **exactly one** criterion, so repeat the option to combine them. The same `-b` syntax works in tshark, and the Capture Options **Output** tab offers it in the GUI as "Create a new file automatically" plus "Use a ring buffer with". Do not confuse `-b` with `-a`, the **autostop** option. `-a duration:N`, `-a filesize:N`, `-a files:N` and `-a packets:N` *stop* the capture when reached; `-b` only decides when to move to the next file. A hunt for an intermittent fault usually wants `-b` alone, with a person or a script stopping the capture once the event has been caught. `-b printname:stdout` helps that script: it prints each file's name as soon as the file is closed, so a collector can copy finished files off the host without guessing which one is still being written. ## A worked command ```bash dumpcap -i eth1 -B 64 -b filesize:500000 -b files:96 -w /srv/capture/branch-wan.pcapng ``` - 96 files of 500,000 kB cap the ring near **48 GB**. - `-B 64` asks for a 64 MiB kernel capture buffer instead of the 2 MiB default (the system may cap it), which helps the capture survive bursts. - dumpcap names each file from the `-w` prefix plus a five-digit sequence number and a creation timestamp, so the files sort and can be matched to the time of the stall. ## Sizing the window 1. Estimate the **peak** captured data rate on the interface, not the link's average. 2. Divide the disk budget by that rate. At 2 MB/s, 48 GB lasts about 6.7 hours; keeping a full two days at that rate needs roughly 346 GB. 3. If it does not fit, keep less per packet (a headers-only snapshot length with `-s`), keep fewer packets (a capture filter, a separate subject), or add disk. 4. Agree who copies out the files covering an event, and how fast, before the ring overwrites them. ## Traps that defeat the ring buffer - **No `-w`.** dumpcap prints "Ring buffer requested, but capture isn't being saved to a permanent file.", switches the ring buffer off and carries on into a single temporary file in `$TMPDIR` (typically `/tmp`) — the full-disk failure you were trying to prevent. - **`files:` with nothing to trigger a switch.** dumpcap complains that no maximum file size, duration, interval or packet count was specified. - **`duration:` and `interval:` together** are refused. - **File boundaries cut context.** A TCP handshake in one file and the stall in the next lose their connection when opened separately. Open them as a set (**File > File Set**) or join the neighbours with mergecap, which merges chronologically by default. - **The GUI is the wrong tool for days.** Wireshark keeps state for every loaded packet, and its own guide warns that if it runs out of memory it will crash. Run dumpcap headless and open the interesting files afterwards. - **Compression costs CPU.** Since Wireshark 4.6 live captures can be compressed while writing (tshark's `--compress`, or an output name ending in a compression extension); before 4.6 compression happened only at file rotation. On a busy link, that CPU may be better spent on not dropping packets.

  • The stall happened at 03:12; how do you pull out just that period from the ring?
    Copy the files whose names carry timestamps around 03:12 out of the ring first, so they cannot be overwritten. `capinfos -a -e` shows each file's earliest and latest packet time; `mergecap -w stall.pcapng` with the two or three neighbouring files joins them chronologically, so a connection that started in one file is analysed with its handshake. In the GUI, **File > File Set > List Files** steps through the set.
  • Can the ring buffer files be compressed while the capture runs?
    Since Wireshark 4.6, yes: live captures can be compressed while writing, and tshark's `--compress` option (or an output name with a compression extension) applies to live capture. Before 4.6, multi-file captures were compressed only at rotation time. Compression trades CPU for disk, so on a saturated link measure drop counts before and after enabling it.
  • Why combine -b filesize: with -b duration: instead of using one of them?
    Each criterion caps something different. `filesize:` bounds disk use per file whatever the traffic does; `duration:` keeps quiet periods from leaving one file open for hours, so each file maps to a predictable time slice. With both, dumpcap switches at whichever limit comes first. Only `duration:` and `interval:` cannot be combined.

A dumpcap ring buffer works like a car's dashcam: it records continuously onto a fixed amount of storage and records over the oldest footage first, so after an incident you must pull the clip before it is recorded over.

saying these in an interview costs you the question

  • -b files:N on its own is enough to make a ring buffer.
  • The -b filesize value is in megabytes.
  • Without -w, dumpcap rotates the ring inside its temporary directory.
  • A ring buffer keeps the first files and stops capturing when it is full.
  • Leaving the Wireshark GUI capturing for two days is fine with enough disk.