skip to content

Wireshark

Wireshark decodes captured traffic layer by layer, filters it by protocol field and rebuilds whole conversations from packets. Interviewers probe it as the answer to what actually crossed the wire.

on this pageshow

explore

questions

page 1 of 2

In Wireshark, how does a capture filter differ from a display filter, and when would you filter at capture time?

level: juniorimportance: must knowfreq 48%

answer

  1. before the file versus after
  2. rejected means never written
  3. libpcap language versus dissector fields
  4. busy link, long run, permitted data

basics

~20 s

A 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 s

Wireshark 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

for a junior

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.

for a middle

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.

for a senior

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.

for a principal

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.
open as a page

In Wireshark, how do you choose the capture interface, and why does traffic to a service on 127.0.0.1 never appear on the Ethernet adapter?

level: juniorimportance: must knowfreq 32%

basics

~20 s

Capture on the interface the flow really crosses; the welcome screen's activity sparklines and dumpcap -D show which interfaces are live. Traffic to 127.0.0.1 is delivered inside the operating system and never reaches the Ethernet adapter, so capture it on the loopback interface.

open as a page

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?

level: juniorimportance: must knowfreq 42%

basics

~20 s

A 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.

open as a page

In Wireshark, what does the Expert Information dialog show, how are its severity levels ranked, and how far should you trust it?

level: juniorimportance: must knowfreq 27%

basics

~20 s

Expert Information lists anomalies that dissectors flagged, ranked Chat, Note, Warn, Error from lowest to highest (packet comments sit below Chat) and grouped by kind, such as Sequence or Malformed. It shows where to look; it never diagnoses.

open as a page

In Wireshark, what does Follow TCP Stream show that the packet list cannot, and what does it do to your display filter?

level: juniorimportance: must knowfreq 38%

basics

~20 s

Follow TCP Stream rebuilds one connection's payload as the applications exchanged it, both directions in sequence order with retransmitted bytes shown once, and applies the display filter tcp.stream eq N, which Back removes and Close keeps.

open as a page

In Wireshark, why does a captured HTTPS session show only TLS Application Data records, and what must you supply to read the HTTP inside?

level: juniorimportance: must knowfreq 30%

basics

~20 s

TLS encrypts every record after the handshake, so Wireshark sees only ciphertext. It decrypts only with key material: a key log of session secrets written by the client through SSLKEYLOGFILE, or the server's RSA private key for static-RSA sessions.

open as a page

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%

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.

open as a page

In Wireshark 4.6, how do you use the Statistics menu to find the slow flow in an hour-long capture of a sluggish internal application?

level: middleimportance: must knowfreq 31%

basics

~20 s

Work top-down in Wireshark 4.6: Protocol Hierarchy for what the file holds, Conversations and Endpoints for who talked, an I/O Graph for when it went wrong, then TCP Stream Graphs and Service Response Time on the one flow.

open as a page

In Wireshark 4.6, a service on TCP 8443 shows as TCP carrying Data; how is a payload dissector picked, and how do you fix it?

level: middleimportance: must knowfreq 30%

basics

~20 s

Wireshark offers the TCP payload to the dissector the tcp.port table maps to that port, then to heuristic dissectors; if none claims it, the bytes fall to Data. Analyze > Decode As maps port 8443 to the right dissector.

open as a page

In Wireshark, how do you carve an executable a host downloaded over plain HTTP out of a capture, and when will Export Objects miss it?

level: middleimportance: must knowfreq 30%

basics

~20 s

File > Export Objects > HTTP lists each HTTP body Wireshark reassembled; Save writes the bytes out for hashing. Bodies inside undecrypted TLS never appear, and bodies with missing segments or an encoding Wireshark cannot decompress come out truncated or absent.

open as a page

How do you get an SSLKEYLOGFILE key log from a test client and make Wireshark decrypt your HTTPS capture with it?

level: middleimportance: must knowfreq 22%

basics

~10 s

Set SSLKEYLOGFILE before the client starts, reproduce the request while capturing, then point Wireshark's TLS preference (Pre)-Master-Secret log filename, tls.keylog_file, at the file; tshark takes the same setting as -o tls.keylog_file:path.

open as a page

What does a [Malformed Packet] entry in Wireshark's packet list mean, and how do you work out what caused it?

level: juniorimportance: should knowfreq 18%

basics

~20 s

A dissector tried to read past the data it was given and threw, so Wireshark stopped decoding that protocol. The cause can be the wrong dissector, an unreassembled message, genuinely broken bytes, or a dissector bug.

open as a page

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%

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.

open as a page

Why should Wireshark never run as root, and how do you let a non-root analyst capture packets on a Linux host?

level: middleimportance: should knowfreq 12%

basics

~20 s

Wireshark's dissectors are a huge body of code parsing attacker-shaped input, so the project keeps every privileged call in dumpcap. Grant capture rights to dumpcap only: the wireshark group on Debian-family packages, or setcap cap_net_raw,cap_net_admin=ep on dumpcap, restricted to a group.

open as a page

Why does a Wireshark capture on a laptop's Wi-Fi interface miss the frames of a failing association, and what do monitor mode and radiotap add?

level: middleimportance: should knowfreq 15%

basics

~20 s

An associated Wi-Fi adapter hands the host only data frames for its own network, so promiscuous mode adds little. Monitor mode passes every 802.11 frame it hears, management and control included, with a radiotap pseudo-header of signal, channel and rate.

open as a page

In a Wireshark display filter, when do you use `contains` rather than `matches`, and why is `http.response.code contains "50"` rejected?

level: middleimportance: should knowfreq 17%

basics

~20 s

contains looks for a literal string or byte sequence and is case-sensitive; matches applies a case-insensitive Perl-compatible regular expression. contains is refused on http.response.code because it cannot be used on atomic fields such as numbers; compare the number instead.

open as a page

How does Wireshark 4.6 decide to label a TCP segment Retransmission, Fast Retransmission, Spurious Retransmission or Out-Of-Order, and what do those labels depend on?

level: middleimportance: should knowfreq 21%

basics

~20 s

Wireshark 4.6 compares each segment with the sequence state it saw: resent bytes are a Retransmission, Fast after two duplicate ACKs, Spurious if already ACKed, Out-Of-Order if new and within the initial RTT. All are guesses from the capture point.

open as a page

In a Wireshark capture of a slow download, which side do the TCP ZeroWindow and TCP Window Full flags each point at?

level: middleimportance: should knowfreq 17%

basics

~20 s

TCP ZeroWindow marks the receiver's packet saying its buffer is full; TCP Window Full marks the sender's segment that reached the edge of the receiver's advertised window. Both point at the receiving side, not the network.

open as a page

What is a heuristic dissector in Wireshark 4.6, and why might one miss traffic it should recognise or claim traffic it should not?

level: middleimportance: should knowfreq 14%

basics

~20 s

A heuristic dissector recognises its protocol from the payload's first bytes rather than a port. It misses when it is disabled, a registered port is tried first, or its signature was never captured; it misclaims when unrelated bytes happen to fit.

open as a page

In Wireshark 4.6, what do the TCP preferences 'Allow subdissector to reassemble TCP streams' and 'Reassemble out-of-order segments' each change in the packet list?

level: middleimportance: should knowfreq 21%

basics

~20 s

'Allow subdissector to reassemble TCP streams', on by default, lets HTTP or TLS decode a message spanning segments on its last segment; 'Reassemble out-of-order segments', off by default and dependent on it, also buffers early-arriving segments into that message.

open as a page

What does Wireshark's tcp.stream field number, and why can one client and server port pair end up with two different stream indexes?

level: middleimportance: should knowfreq 17%

basics

~20 s

tcp.stream numbers each TCP conversation in a file from 0, in order of first appearance. A new SYN reusing the same addresses and ports, with a new initial sequence number or after a FIN or RST, gets a new index.

open as a page

When can Wireshark 4.6's RSA keys list decrypt a captured TLS 1.2 session, and how does it match the key to the session?

level: middleimportance: should knowfreq 13%

basics

~20 s

Only when the session used static-RSA key exchange and its full handshake is in the capture. Wireshark 4.6 picks the key by matching it to the public key in the captured server Certificate; the list's IP address column is unused.

open as a page

A long dumpcap capture ends with a 'Packets received/dropped on interface' line showing drops; where were the packets lost, and what do you change?

level: seniorimportance: should knowfreq 15%

basics

~20 s

The bracketed counters say where: pcap means the operating system's capture buffer overflowed (raise -B, cut -s, use a faster disk), dumpcap means dumpcap failed to write or queue packets, flushed means packets arriving after stop, and ps_ifdrop counts the interface or driver.

open as a page

To hide a noisy health checker at 192.0.2.10 in Wireshark 4.6, what does `ip.addr != 192.0.2.10` match, and when are `!==` or `===` right instead?

level: seniorimportance: should knowfreq 22%

basics

~20 s

Since Wireshark 3.6, != means all-not-equal: ip.addr != 192.0.2.10 keeps IPv4 packets where neither address is that host, and hides frames with no ip.addr at all. !== (any not equal) and === (all equal) arrived in 4.0.

open as a page

A Wireshark capture of a slow transfer shows TCP Previous segment not captured and TCP ACKed unseen segment entries; how do you tell capture loss from real network loss?

level: seniorimportance: should knowfreq 14%

basics

~20 s

Ask whether the receiver got the missing bytes. A gap followed by duplicate ACKs and a retransmission is real loss; a gap the receiver simply ACKs past, flagged ACKed unseen segment and never resent, is loss at the capture point only.

open as a page

In Wireshark, how do you prove from a capture taken next to the client whether a downloaded file that arrives corrupted was already wrong on the wire?

level: seniorimportance: should knowfreq 12%

basics

~20 s

Prove the capture holds the whole stream (no missing-bytes marker in Follow TCP Stream, contiguity count 1), then hash the exported object against the server and client copies; the pair that matches places the change before or after the capture point.

open as a page

Wireshark 4.6 has your key log configured, yet some HTTPS sessions in the capture still show only Application Data; how do you find out why?

level: seniorimportance: should knowfreq 12%

basics

~20 s

Turn on the TLS debug file and read why each session failed. The usual causes: the ClientHello is not in the capture, the key log came from another process or run, the client never read SSLKEYLOGFILE, or the browser used QUIC.

open as a page

How do Wireshark coloring rules use display filters, and why can a `udp` rule above a `dns` rule stop DNS packets getting the DNS color?

level: juniorimportance: nice to knowfreq 9%

basics

~20 s

Each Wireshark coloring rule is a name, a display filter and colors; a row takes the colors of the first rule whose filter matches. DNS usually rides on UDP, so a udp rule above a dns rule claims those packets.

open as a page

Why does Wireshark write captures as pcapng by default, and what can you lose by saving a capture as pcap instead?

level: middleimportance: nice to knowfreq 11%

basics

~20 s

pcapng describes each interface separately and can carry comments, name resolution and capture statistics, so one file can hold several interfaces. pcap has one global header with a single link-layer type, so mixed-interface captures cannot be saved as pcap and metadata is dropped.

open as a page

In Wireshark 4.6, why does `tcp.port in {443, 4430..4434}` match fewer packets than `tcp.port == 443 || (tcp.port >= 4430 && tcp.port <= 4434)`?

level: middleimportance: nice to knowfreq 11%

basics

~20 s

The in operator tests each tcp.port value against the whole set, ranges included. The spelled-out filter tests >= and <= separately, and a packet from port 56789 to port 80 satisfies each with a different port.

open as a page

showing 1–30 of 36