skip to content

In Wireshark, the capture filter field turns red when you type `tcp.port == 443`; what is wrong, and what should you type instead?

level: middleimportance: should knowfreq 24%

answer

  1. two languages, two fields
  2. dissector field versus libpcap primitive
  3. tshark: looks like a display filter
  4. add a protocol qualifier to port

basics

~20 s

That is display-filter syntax, and Wireshark's capture filter field accepts only libpcap filter expressions. The capture filter for HTTPS is tcp port 443; tcp.port == 443 belongs in the display filter toolbar or tshark -Y.

solid answer

~40 s

The capture filter field takes the **libpcap filter language**, not Wireshark's field syntax. `tcp.port == 443` is a display filter, so the field's syntax check turns it red; the capture filter is `tcp port 443`. tshark makes the mistake explicit: `tshark -i eth0 -f "tcp.port == 443"` stops with an invalid capture filter error and notes that the string looks like a valid display filter but is not a valid capture filter. The reverse also fails: `tcp port 443` in the display filter toolbar turns that bar red. On the command line, `-f` takes capture syntax and `-Y` display syntax, and tshark rejects `-f` when reading a file with `-r`. A green field only means the expression compiled: `port 443` is valid but matches UDP 443 too.

code

bash · 2 lines
bash
tshark -i eth0 -f "tcp port 443" -w https.pcapng
tshark -r https.pcapng -Y "tcp.port == 443 && tcp.flags.reset == 1"

go deeper

for a junior

Recall that the capture field takes libpcap expressions like tcp port 443 and the display bar takes field comparisons like tcp.port == 443.

for a middle

Explain which tshark flag takes which language, why tshark rejects -f with -r, and why some expressions such as tcp or arp work in both fields.

for a senior

Show that a green field is only a compile check: test what a capture filter really selects, and keep vetted expressions as saved capture filters for the team.

for a principal

Treat recurring filter mistakes as a tooling gap: shared saved filters and a reviewed capture runbook cost less than a capture that recorded the wrong traffic.

## Why the field turned red Wireshark's **capture filter** field and its **display filter** toolbar accept **different languages**, and the expression `tcp.port == 443` belongs to the second one. - **Capture filters** use the **libpcap filter language**: primitives such as `host`, `net` and `port`, optional qualifiers such as `tcp`, `udp`, `src` and `dst`, joined with `and`, `or` and `not`. The capture filter for TCP port 443 is `tcp port 443`. - **Display filters** use **Wireshark's field syntax**: a dissector field name such as `tcp.port`, a comparison operator such as `==`, and a value. `tcp.port == 443` is a perfectly good display filter. The capture filter field checks your expression as you type and colours its background: **green** when it compiles as a capture filter, **red** when it does not. `tcp.port` is not a libpcap primitive, so the field turns red and the capture cannot use it. The same mistake in reverse also fails: `tcp port 443` typed into the display filter toolbar turns that bar red, because `port` is not how display filters compare a field. ## How each tool reports the mix-up The command-line tools say it explicitly. Run `tshark -i eth0 -f "tcp.port == 443"` and tshark refuses the capture with an **invalid capture filter** error. Because the string does compile as a display filter, tshark adds that it "looks like a valid display filter; however, it isn't a valid capture filter", and reminds you that the two syntaxes are not the same. `dumpcap` run directly reports the string as an invalid capture filter for that interface. The flags keep the languages apart: | Flag | Takes | Used when | |---|---|---| | `dumpcap -f`, `tshark -f`, `wireshark -f` | a capture filter (libpcap syntax) | capturing live | | `tshark -Y` | a display filter (Wireshark syntax) | printing or writing dissected packets | | `tshark -R` | a read filter (display syntax) | the first pass of two-pass analysis with `-2` | tshark also refuses `-f` when you read a file with `-r`: "Only read filters, not capture filters, can be specified when reading a capture file." A saved file is filtered with display syntax only. ## Why people keep confusing them 1. **Some expressions are valid in both.** A bare protocol name such as `tcp`, `udp` or `arp` is both a libpcap primitive and a Wireshark display filter, so a beginner's first filters work in either field and suggest the languages are one. 2. **They look alike.** `tcp port 443` and `tcp.port == 443` differ by a dot and an operator. 3. **Muscle memory from tcpdump.** Someone who writes pcap expressions every day types them into the display bar out of habit. The fix is to remember which moment you are filtering at: before capture is libpcap syntax, after capture is field syntax. ## Green is not the same as right A green capture filter field means the expression **compiles**, not that it selects what you meant. - `port 443` is valid and green, but without a `tcp` or `udp` qualifier it matches **both** TCP and UDP port 443, so QUIC traffic on UDP 443 lands in the capture too. - `host 192.0.2.10` is valid, but it captures every protocol to and from that host, not just the service you care about. When the result matters, **Compile Selected BPFs** in the Capture Options dialog (or `dumpcap -d`) shows the code the expression compiled to; reading that code in depth belongs with the pcap-filter language itself. Wireshark 4.6 also changed one edge of the check: on Linux, capture filters that use BPF extensions such as `inbound`, `outbound` and `ifindex` are now **marked as unknown** instead of always being rejected, and can be used for capturing. ## Saved capture filters To stop retyping (and mistyping) long expressions, save them in **Capture > Capture Filters...** (also reachable as *Manage Capture Filters* from the capture filter bookmark menu). The dialog checks each expression with the same background colouring as the main fields. Saved filters live in the **`cfilters`** file in your personal configuration folder, one `"<filter name>" <filter string>` line each. From the command line, `wireshark -f` and `tshark -f` accept a saved name with the `predef:` prefix, for example `tshark -f "predef:MyPredefinedHostOnlyFilter"`.

  • What does tshark do if you pass `-f` while reading a saved file with `-r`?
    It refuses: "Only read filters, not capture filters, can be specified when reading a capture file." A saved file is filtered with display syntax, using `-Y` for ordinary single-pass filtering or `-R` together with `-2` for two-pass analysis.
  • How do you reuse a capture filter you saved in Wireshark from the command line?
    Capture > Capture Filters... saves named expressions to the `cfilters` file in your personal configuration folder. Both `wireshark -f` and `tshark -f` accept a saved name with the `predef:` prefix, for example `tshark -f "predef:MyPredefinedHostOnlyFilter"`.
  • The capture filter `port 443` turns green; why might the capture still hold traffic you did not want?
    Green only means the expression compiles. Without a `tcp` or `udp` qualifier, `port` matches both protocols, so UDP 443 traffic such as QUIC is captured too. Write `tcp port 443` when you mean TCP, and check a non-trivial filter with Compile Selected BPFs or `dumpcap -d`.

saying these in an interview costs you the question

  • The capture filter field accepts the same field names as the display filter toolbar.
  • Wireshark silently converts display-filter syntax in the capture field into a capture filter.
  • A green capture filter field proves it selects exactly the intended traffic.
  • tshark -f can be used to filter a saved file opened with -r.
  • Typing tcpdump syntax such as tcp port 443 into the display filter toolbar works.