In Wireshark, how does a capture filter differ from a display filter, and when would you filter at capture time?
answer
- before the file versus after
- rejected means never written
- libpcap language versus dissector fields
- busy link, long run, permitted data
basics
~20 sA capture filter, written in libpcap's filter language, decides which packets are ever recorded; anything it rejects is gone for good. A display filter, written in Wireshark's field syntax, only hides packets already captured and can be changed freely.
solid answer
~50 sWireshark has two filter languages. A **capture filter** is a libpcap expression such as `tcp port 443`, set per interface in Capture Options, in the welcome screen's capture filter field, or with `dumpcap -f` / `tshark -f`; it is applied while capturing, so what it rejects is never written and cannot be recovered. A **display filter** such as `tcp.port == 443` is evaluated against the dissected fields of packets already captured; it only hides, and clearing it brings everything back. So by default I capture broadly and narrow with display filters, and I filter at capture time only when I must: a busy link where the host would drop packets or fill its disk, a capture that runs for days, or a rule that I may keep only certain traffic. Then I accept that a question I did not anticipate cannot be answered from that file.
go deeper
Recall the two moments: a capture filter acts before packets are saved, a display filter acts on what was saved. Know one example of each syntax for the same port.
Explain why the capture filter cannot see dissected fields and why a display filter never shrinks the file, and name where each is entered in the GUI and on the command line.
Show the judgement: capture broadly by default, and justify a capture filter by load, retention or policy, stating what the filter will make impossible to answer later.
Frame capture filtering as a trade between evidence and cost or compliance, and insist the team records what each standing capture excludes so absence is never misread.
## Two filter languages, two moments Wireshark has **two separate filtering languages**, and they act at different moments in a packet's life. - A **capture filter** is written in the **libpcap filter language** (the same pcap-filter expressions tcpdump uses), for example `tcp port 443` or `host 192.0.2.10`. It is compiled and handed to the capture library when the capture starts, and it decides, packet by packet, whether a packet is captured at all. Packets it rejects are never written to the capture file and never shown. - A **display filter** is written in **Wireshark's own field syntax**, for example `tcp.port == 443` or `ip.addr == 192.0.2.10`. It is evaluated against the **dissected fields** of packets that are already in the capture. Packets that do not match are only **hidden** from the packet list; clear the filter and they are all back. The practical consequence fits in one line: **a capture filter's mistake is permanent, a display filter's mistake costs you a keystroke.** ## What "lost for good" really means When a capture filter excludes something, there is no copy anywhere in Wireshark to recover it from. If you captured with `host 192.0.2.10` and later learn that the interesting conversation involved 192.0.2.20, that traffic is simply not in the file. No display filter, preference or re-dissection can bring it back, because display filters only see what was saved. The only remedies are outside the file: another capture point, flow records, server logs, or a broader capture next time. A display filter, by contrast, never changes the file. During a live capture, the file `dumpcap` writes still receives every packet that passed the capture filter, whatever display filter you have typed. If you want a smaller file afterwards, **File > Export Specified Packets** with *Displayed* selected writes only the packets that match the current display filter, and the original stays intact. There is also a difference in **what each filter can see**. A capture filter runs before Wireshark's dissectors, so it can test addresses, ports, protocol numbers and raw bytes at offsets, but it cannot test a dissected field such as an HTTP method. A display filter can test anything a dissector exposes, because it runs after dissection. | | Capture filter | Display filter | |---|---|---| | Language | libpcap filter expressions | Wireshark field syntax | | Applied | while capturing, before anything is written | to packets already captured | | A non-matching packet is | never captured | hidden, still in the file | | Change your mind later? | no | yes, at any time | | Example for HTTPS | `tcp port 443` | `tcp.port == 443` | | Where you enter it | Capture Options per interface, the welcome screen's capture filter field, `dumpcap -f`, `tshark -f` | the display filter toolbar, `tshark -Y` | ## When filtering at capture time is the right call The default habit of an experienced analyst is **capture broadly, narrow with display filters**, because nobody knows in advance which packets will explain a problem. A capture filter earns its place when one of these is true: 1. **The capture host cannot keep up.** On a busy link, recording everything can overrun the capture buffer and cause drops, or the disk cannot absorb the volume. Rejecting uninteresting packets early reduces the work, the drops and the file size. 2. **The capture runs for a long time.** A capture left running for days to catch an intermittent fault fills a disk quickly; filtering to the service involved makes the retention window long enough to catch the event. 3. **You are only allowed to keep certain traffic.** If policy or a data-protection rule says you may record only one application's traffic, a capture filter is how you make sure nothing else is ever written. Hiding other traffic with a display filter does not satisfy that rule, because the other traffic is still on disk. In each case you accept a trade: whatever the filter excludes cannot answer a question you did not anticipate. ## Where you set one in Wireshark In the GUI, a capture filter is set **per interface** in **Capture > Options** (the *Capture Filter* column of the interface table, or the *Capture filter for selected interfaces* field for several at once), or in the capture filter field on the welcome screen before you start. Frequently used expressions can be saved in **Capture > Capture Filters...** and picked from the filter bookmark menu. On the command line, `dumpcap -f` and `tshark -f` take the same expression; `tshark -Y` takes a display filter instead. ## A working habit - Start without a capture filter when the volume allows it. - Add one when load, retention or policy forces it, and write down what it excludes. - Do all exploratory narrowing with display filters, which are free to change.
- You captured with `host 192.0.2.10` and now need what 192.0.2.20 sent during the same window; what can you do with that file?Nothing: the capture filter rejected those packets, so they were never written, and a display filter only sees what the file contains. You need another source for that window, such as a capture taken elsewhere, flow records or server logs, and a broader capture filter next time.
- Does typing a display filter during a live Wireshark capture make the capture file smaller?No. `dumpcap` still writes every packet that passed the capture filter; the display filter only changes which packets the list shows. To keep a smaller file, use File > Export Specified Packets with *Displayed* selected after the capture, which writes the matching packets to a new file.
- Why can't a Wireshark capture filter select packets by a dissected field such as an HTTP request method?A capture filter runs in the capture library before any Wireshark dissector has looked at the packet, so it can test addresses, ports, protocol numbers and raw bytes at offsets, but not fields that only exist after dissection. Selecting on dissected fields is what display filters are for.
A capture filter is the mesh size of a fishing net, chosen before the catch: whatever slips through is back in the sea. A display filter is sorting the catch on deck: you can always re-sort, because everything you caught is still in the boat.
saying these in an interview costs you the question
- A display filter deletes the hidden packets from the capture file.
- Packets a capture filter rejected can be brought back later with a display filter.
- Capture and display filters share one syntax, so either field accepts tcp.port == 443.
- Always set a capture filter, because capturing everything is merely wasteful.
- A capture filter can match any field shown in the packet details pane.