A dumpcap capture must run for days on two busy interfaces and keep only one service's traffic; how do you set the capture filter, and what do you give up?
answer
- filter before it is written
- order of -f and -i
- default filter versus per-interface
- what host-and-port leaves out
basics
~20 sGive dumpcap one quoted -f before the first -i so it becomes the default for both interfaces, check it with -d, and accept that excluded traffic, such as ICMP errors or DNS lookups about that service, is gone for good.
solid answer
~40 sI use a capture filter, because rejected packets are never written: that keeps disk and capture load sustainable and keeps out traffic I may not hold. On `dumpcap`, a quoted `-f` before the first `-i` is the **default** for every interface; an `-f` after an `-i` applies only to that last interface, so `-i eth0 -i eth1 -f "..."` leaves `eth0` unfiltered. I check the expression with `dumpcap -d`, confirm the first file holds the service's traffic, and watch the drop count. The cost is that anything excluded is gone: `host 192.0.2.10 and tcp port 5432` drops ICMP errors about the connection, DNS lookups and ARP. A live `tshark -w` capture refuses a `-Y` display filter anyway. dumpcap's pcapng records the filter per interface, and I note its blind spots in the incident record.
code
bash · 2 linesdumpcap -f "host 192.0.2.10 and tcp port 5432" -i eth0 -i eth1 -d
dumpcap -f "host 192.0.2.10 and tcp port 5432" -i eth0 -i eth1 -b filesize:1000000 -b files:48 -w /var/tmp/orders-db.pcapnggo deeper
Recall that a capture filter stops packets being saved at all, and that dumpcap takes it with -f as one quoted argument.
Explain how -f before the first -i becomes the default while -f after an -i binds to that interface, and how -d checks the compiled filter.
Name what a host-and-port filter silently drops, verify the first file and drop counts before walking away, and record the filter's blind spots with the evidence.
Weigh evidence completeness against disk, load and data-retention rules, and set a standing rule that every long capture documents what it deliberately excludes.
## The situation You need evidence of an intermittent fault in one service, so the capture has to run unattended for days on two busy interfaces of the same host. Recording everything would fill the disk and may overrun the capture buffer, and you may only keep that service's traffic. This is the case where a **capture filter** is the right tool: packets it rejects are never written, and where the filter runs in the kernel they are not even copied to `dumpcap`, which saves CPU, disk and buffer space and keeps out traffic you are not allowed to hold. The ring buffer that bounds disk use (`-b filesize:` and `-b files:`) is a capture-setup topic; the decisions here are where the filter goes and what it costs. ## Placing `-f` on a dumpcap command line `dumpcap -f` takes the whole expression as **one argument**, so quote it. Its position relative to `-i` matters: - **Before the first `-i`**, `-f` sets the **default** capture filter, used by every interface that has no filter of its own. - **After an `-i`**, `-f` sets the filter for **the interface named by the last `-i` before it** only. So `dumpcap -f "host 192.0.2.10 and tcp port 5432" -i eth0 -i eth1 ...` filters both interfaces, while `dumpcap -i eth0 -i eth1 -f "..."` filters only `eth1` and records **everything** on `eth0`. That second form is the classic way a days-long capture fills its disk overnight. To give each interface its own filter, repeat `-f` after each `-i`. Before leaving the capture alone, check what will be kept: 1. Run the same command with `-d`, which prints the compiled filter code and exits, to confirm the expression compiles for each interface's link type. 2. Let it run for a minute and open the first file to confirm the service's traffic is there and the rest is not. 3. Watch dumpcap's dropped-packet report; a filter lowers the load but does not make drops impossible. ## What you give up A capture filter decides, before anything is analysed, which questions the file can answer. Everything it excludes is **gone for good**. A filter such as `host 192.0.2.10 and tcp port 5432` keeps the client and server segments of that service, including handshakes, retransmissions and resets, but drops: | Excluded traffic | Why you might later want it | |---|---| | ICMP messages about the connection (for example, unreachable or packet-too-big errors) | they explain resets, stalls and path-MTU problems; they are ICMP, not TCP | | DNS lookups the service's host makes, for example for a dependency | they show slow or failed name resolution behind a stall | | ARP or neighbour discovery on the segment | address-resolution failures look like silent loss | | Other services on the same host | the fault may start in a dependency | Decide which of these you can live without; widen the filter (for example with `or icmp`) where the cost is small. Two further limits are worth knowing: - **Capture filters apply only to real interfaces.** dumpcap's code does not apply a capture filter to a pipe source, so a filter set on a stream arriving through a pipe filters nothing; filter where the packets are first captured instead. - **A filter cannot fix packets that never reached the host.** If the mirror or link feeding the capture is oversubscribed, the gap is upstream of `dumpcap`, and the fix belongs to whoever delivers the packets. ## Why not a display filter instead A display filter would let you change your mind later, but it cannot limit what a live capture saves. tshark states this outright: started with `-w` and a `-Y` display filter on a live interface, it exits with "Display filters aren't supported when capturing and saving the captured packets." Display filtering would also require dissecting every packet as it arrives, which is the work you were trying to avoid on a busy host. For a saved live capture, the capture filter is the packet-selection control. ## Leaving a record `dumpcap` writes pcapng by default and stores the capture filter string in each interface's **interface description block**, so the file itself records what was excluded; Statistics > Capture File Properties shows the interface details when you open it. A pcap file has no place for this, which is one more reason to keep the default format. Still note the filter, its reason and its blind spots in the incident record: the next analyst needs to know that "no ICMP in the capture" means "not captured", not "not sent".
- A colleague's command reads `dumpcap -i eth0 -i eth1 -f "tcp port 5432" -w db.pcapng`; which interface is filtered?Only `eth1`. An `-f` after an `-i` sets the filter for the interface named by the last `-i` before it, and since no default filter was given before the first `-i`, `eth0` records everything. Move `-f` before the first `-i`, or repeat it after each `-i`.
- Why not run `tshark -w` with a `-Y` display filter, so the selection could use dissected fields?tshark refuses that combination on a live capture: "Display filters aren't supported when capturing and saving the captured packets." Even where display filtering is possible, it needs every packet dissected first, which is the load a capture filter avoids on a busy host.
- How will an analyst opening the file next month know what the capture excluded?dumpcap writes pcapng by default and stores the capture filter string in each interface description block, so the file carries it and Statistics > Capture File Properties shows the interface details. A pcap file has no place for it, so also record the filter and its blind spots in the incident notes.
saying these in an interview costs you the question
- An -f placed after the last -i applies to every interface on the dumpcap command line.
- Filtering on the service's host and port keeps everything needed to debug its connections.
- tshark can save a live capture through a -Y display filter to keep the file small.
- With a capture filter in place, dumpcap's dropped-packet count no longer needs watching.
- A capture filter set on a pipe source filters packets just like one on a real interface.