In Wireshark, how does a display filter such as `http.response.code >= 500` reach into dissected fields, and what does a bare field name test?
answer
- names the dissectors register
- status bar shows the name
- typed values, quoted strings
- bare name means present
- Boolean flags are always present
basics
~20 sA Wireshark display filter compares typed fields the dissectors registered: http.response.code >= 500 is a numeric test. A bare field name only tests that the field exists, so tcp.flags.syn alone matches nearly every TCP packet.
solid answer
~40 sEvery dissector registers named, typed fields, and a display filter is an expression over them evaluated per packet: `http.response.code >= 500` compares an unsigned integer, `http.request.method == "POST"` a quoted string, `ip.addr == 192.0.2.0/24` an IPv4 address against a CIDR block. I get the exact name by clicking the line in Packet Details, where the status bar shows it, or with Apply as Filter. A bare name such as `http` or `tcp.analysis.retransmission` is an existence test, and that bites on Boolean flag fields: `tcp.flags.syn` is present in every TCP header whether the bit is 0 or 1, so I write `tcp.flags.syn == 1`. I combine tests with `and`, `or`, `not` and parentheses; in Wireshark 4.6 `and` binds tighter than `or`. A green bar means it compiled, not that it means what I intended.
code
bash · 3 linestshark -r web-tier.pcapng -Y 'http.response.code >= 500' \
-T fields -e frame.number -e ip.src -e http.response.code \
-e http.request_in -e http.timego deeper
Recall that a display filter compares named fields, that strings need quotes, and that a bare field name only checks the field exists. Know how to read a field name from the status bar.
Explain field types and why the operator must suit them, the implicit existence test inside every comparison, and why Boolean flag fields need an explicit == 1.
Show how you would cut a large capture down with a chain of filters, and say when a filter cannot match because the dissector never produced the field.
Discuss how saved filters, filter buttons and shared profiles let a team investigate the same way, and what a shared filter that silently mis-groups and/or costs an incident.
## What a display filter evaluates Wireshark **dissects** every packet into a protocol tree. Each dissector registers the fields it can add, and every field has a **filter name** (such as `http.response.code`) and a **type** (unsigned integer, string, IPv4 address, Boolean, time offset and so on). A **display filter** is an expression over those fields, evaluated once per packet: packets for which it is true stay in the packet list, the rest are hidden, not deleted. The same engine runs `tshark -Y`, coloring rules and the filters inside statistics dialogs, so one language serves all of them. The consequence is that a display filter can only see what a dissector put into the tree. If a field never appears in Packet Details for a packet, no filter on that field will ever match it. ## Finding the exact field name The text in a column header or a tree label is a description, not the filter name. Ways to get the real name: - Click the line in **Packet Details**: the status bar shows the filter name in parentheses. - Right-click it and choose **Apply as Filter** or **Prepare as Filter**, which writes the expression for you. - Open **Analyze > Display Filter Expression**, which lists fields by protocol with their types. - Browse **View > Internals > Supported Protocols**, or run `tshark -G fields` on the command line. ## Values, types and operators Comparison operators come in C-like and English forms that can be mixed: `==`/`eq`, `!=`/`ne`, `>`/`gt`, `<`/`lt`, `>=`/`ge`, `<=`/`le`. The value must suit the field's type: | Field | Type | Example | |---|---|---| | `http.response.code` | unsigned integer | `http.response.code >= 500` | | `http.request.method` | character string | `http.request.method == "POST"` | | `ip.addr` | IPv4 address | `ip.addr == 192.0.2.0/24` | | `http.time` | time offset | `http.time > 2` | | `tcp.flags.syn` | Boolean | `tcp.flags.syn == 1` | Strings go in **double quotes**; writing them unquoted is deprecated. Integers may be decimal, hex (`0x1f4`), octal or binary (`0b...`). Because `http.response.code` is a number, `>= 500` is a numeric comparison, which is why it is the clean way to find every 5xx response. ## Existence tests and the Boolean trap A bare protocol or field name is an **existence test**: `http` keeps packets the HTTP dissector handled, `http.response` keeps responses, and `tcp.analysis.retransmission` keeps packets on which TCP sequence analysis set that flag. Filtering on an analysis flag is just syntax; what the flag means is the Expert Info material. Every comparison also carries an **implicit existence test**: `http.response.code >= 500` is false on any packet that has no such field. The trap is the Boolean flag fields. `tcp.flags.syn` is added to every TCP packet, with the value 0 or 1, so the bare name matches almost all TCP traffic. To keep only segments with the bit set, compare it: `tcp.flags.syn == 1`. ## Combining tests Logical operators, from highest to lowest precedence, are `not`/`!`, `and`/`&&`, `xor`/`^^` and `or`/`||`. Since Wireshark 4.0, `and` binds tighter than `or`, so `a or b and c` reads as `a or (b and c)`; filters written for 3.x without parentheses can change meaning. Write the grouping explicitly: ``` (http.response.code >= 500 or http.time > 2) and ip.dst == 198.51.100.20 ``` The filter bar turns **green** when the expression compiles and **red** when it does not. Green proves syntax only: a filter can compile and still select something other than what you meant. ## When a correct-looking filter matches nothing A filter that compiles but shows an empty list usually means the field was never produced, or that the filter asks for something no single packet holds: - The traffic is on a port the HTTP dissector is not tied to, so the packets appear as plain TCP and carry no `http.*` fields; pointing the dissector at the port is a dissector setting, not a filter change. - The traffic is HTTPS and no key material was loaded, so only TLS records exist. - The filter asks one packet for fields that live on two: `http.request.method == "POST" and http.response.code >= 500` usually matches nothing, because requests and responses are separate packets. The status bar can also show a warning for a filter that compiles but may have unexpected results; read it before trusting the packet list. ## Working a large capture of a failing web tier On a 200,000-packet capture, a few filters replace scrolling: 1. `http.response` to see every response the dissector found. 2. `http.response.code >= 500` to keep the failures. 3. `http.time > 2` to find slow answers, since `http.time` is the time since the matching request. 4. Read `http.request_in` on a failing response to jump to the request frame that caused it. 5. Save the filters you reuse as saved filters or filter buttons so the next incident starts from them.
- How do you show only packets from five minutes before the selected packet onwards?Use a field reference: `frame.time_relative >= ${frame.time_relative} - 300`. Wireshark 4.6 reads `${frame.time_relative}` (or `$frame.time_relative`) from the packet selected when the filter is applied, so the filter is anchored to that packet. If the selected packet lacks the referenced field, the comparison is false. Field references have been part of the filter syntax since 4.0.
- How do you apply the same display filter to a saved capture with tshark?Pass it with `-Y`, quoted for the shell: `tshark -r web-tier.pcapng -Y 'http.response.code >= 500'`. `-R` is the read filter and only makes sense with two-pass analysis (`-2`); for ordinary single-pass filtering the manual says to use `-Y`. Running a display filter during a live tshark capture costs CPU and makes dropped packets more likely.
saying these in an interview costs you the question
- A bare tcp.flags.syn shows only the segments that have SYN set.
- The column header text, such as Status Code, is the field name to type.
- Unquoted strings like http.request.method == POST are the supported form.
- A green filter bar proves the filter selects what you intended.
- In Wireshark 4.6, a or b and c is read as (a or b) and c.