Wireshark Interview Questions: Filters, Protocol Dissection, and Encrypted Traffic

Wireshark interview questions often start with a filter and end with an evidence problem. You can display packets on port 443, but can you establish that they contain HTTP? You can see a retransmission annotation, but can you prove that the application server caused the delay? You can select a TLS conversation, but do you have permission and the secrets needed to decrypt it?

This guide uses an original packet ledger to separate capture filtering, display filtering, protocol dissection, and decryption. The goal is an answer that says what the trace supports and what you would collect next. It is not a packet capture from a real customer or a claim that the example commands were executed here. Related networking practice is available in Software Engineering Fundamentals.

Capture filters and display filters solve different problems

A capture filter controls which traffic is recorded by the capture tool. A display filter selects from packets already recorded. Their grammars differ. The Wireshark capture-filter reference documents examples using capture syntax; the display-filter manual describes Wireshark's field-based expressions.

For example, tcp port 443 is a capture-filter expression. tcp.port == 443 is a display-filter expression. Both concern TCP traffic with a source or destination port of 443, but you cannot paste one indiscriminately into the other's interface and expect it to work.

The irreversibility is more important than the syntax. If a narrow capture filter excluded the DNS lookup or UDP traffic, clearing a display filter cannot restore those missing packets. You need a broader capture or another source that already recorded them. Preserve the original capture and apply display filters non-destructively while investigating.

At capture time, balance relevance, storage, performance, and privacy. “Capture everything” may be prohibited or operationally expensive. “Only port 443” may omit the very evidence needed to understand a connection failure. State the authorized scope and the suspected protocol path before choosing the filter.

Work a packet ledger before memorizing expressions

The following ledger is an invented teaching fixture, not a decoded PCAP. It records enough fields to reason about selection. Stream identifiers are illustrative and local to this hypothetical file.

#	Recorded evidence and interpretation
1	UDP 53000 → 53; DNS query. Name lookup is present.
2	UDP 53 → 53000; DNS response. A response was observed.
3	TCP 51000 → 443; SYN, stream 2. A TCP connection attempt began.
4	TCP 443 → 51000; SYN/ACK, stream 2. The peer responded to the handshake.
5	TCP 51000 → 443; TLS ClientHello, stream 2. TLS negotiation was observed.
6	TCP 443 → 51000; TLS application data, stream 2. Encrypted application traffic was observed.
7	TCP 52000 → 80; HTTP request, stream 3. Cleartext HTTP was decoded.
8	TCP 53000 → 8443; Data, stream 4. Payload classification needs investigation.
9	UDP 54000 → 443; QUIC. Port 443 is not exclusively TCP.

On this ledger, a TCP-port-443 selection retains frames 3–6. It excludes the DNS exchange, the cleartext HTTP request on port 80, the traffic on 8443, and the UDP/QUIC packet. Saying “I captured HTTPS” is therefore less precise than saying “I retained TCP traffic involving port 443.”

A display filter dns would select decoded DNS packets in a complete file. It would return nothing from a file that recorded only frames 3–6. That empty display is not evidence that no DNS query occurred; it is consistent with the capture having excluded it.

A display filter http targets fields recognized by the HTTP dissector. It does not mean “every application transaction that was conceptually HTTP before encryption.” Without suitable decryption and dissection, encrypted application traffic may not expose those fields at all.

Use this distinction to answer the interviewer: first state the retained frames, then state the missing context, then propose the next collection. That is a falsifiable explanation rather than a list of familiar filter strings.

Why is traffic on port 8443 shown only as data?

Possible explanations include an unrecognized application, a nonstandard port, a truncated capture, incomplete reassembly, encryption, or bytes that genuinely do not match the expected protocol. Port numbers are hints, not a proof of payload semantics.

Inspect the packet bytes and the surrounding conversation before forcing an interpretation. The Wireshark User's Guide covers protocol analysis and the Decode As mechanism. Decode As can direct a dissector to interpret traffic differently; it does not change recorded bytes, reconstruct absent packets, or supply TLS secrets.

In the ledger, frame 8 might be TLS on an alternate port. Trying the appropriate dissection can test that hypothesis. If it still fails, inspect whether the capture includes enough handshake or application bytes, whether the protocol assumption is correct, and whether a dissector preference affects parsing. Do not keep trying random protocols until one produces an attractive tree.

Record any Decode As override in your handoff. Another analyst opening the same file without that setting may see a different interpretation. The evidence is the capture plus relevant settings, not only a screenshot of the decoded panel.

Also distinguish display labels from server behavior. A packet marked “Data” can carry meaningful application content that Wireshark has not identified. It does not establish that the application sent arbitrary garbage.

A TCP packet is not an application message

TCP exposes a byte stream. An application request may span several segments, and one segment may contain parts of multiple messages. A parser that assumes one packet equals one request will fail even when the network is healthy.

Follow the relevant stream and inspect reassembled data where authorized and available. The ledger's tcp.stream == 2 would isolate its selected TCP conversation. The number 2 is assigned within that capture; it is not a stable identifier to copy blindly into another file or a merged trace.

Capture loss and truncated packet lengths can limit reassembly. Before blaming an application parser, check whether the necessary bytes were recorded, whether only one direction is visible, and whether the capture began midway through the conversation. A network tap, host capture, and load-balancer capture may show different portions of the same path.

Out-of-order observations need care too. They can reflect network behavior, capture location, buffering, or the limitations of merged timestamps. Compare sequence and acknowledgment information and document where the trace was taken. Do not turn a single annotation into a complete root-cause story.

For performance analysis, distinguish connection establishment, TLS negotiation, request transfer, server processing, and response transfer. A long gap between packets may be informative, but the trace alone may not identify which internal server component was waiting. Correlate with application telemetry rather than inventing an explanation.

What can you see in encrypted traffic?

Without decryption, a trace can often establish endpoints, transport ports, packet sizes, timing, and parts of negotiation. Some handshake metadata may be visible, depending on protocol version and privacy features. Do not guarantee that a hostname is always exposed: encrypted ClientHello mechanisms and different capture conditions can change what is available.

The HTTP path, request body, or response content is not generally readable merely because TCP port 443 is visible. Frame 6 in the ledger supports “encrypted application data was observed,” not “the user requested /checkout and received a 500 response.” Those application-level conclusions need additional evidence.

The Wireshark TLS documentation describes session-secret-based decryption and its prerequisites. For an authorized debugging session, a supported client can produce a key log that Wireshark uses with the matching capture. The secrets must correspond to those sessions; an unrelated key log is not a universal decoder.

Do not promise that a server's private key decrypts modern TLS traffic. Forward-secret key exchanges and TLS 1.3 make that assumption wrong in common configurations. Explain the negotiated protocol and available secrets rather than treating possession of a certificate or key as sufficient.

A failed decryption attempt has several hypotheses: mismatched secrets, incomplete captured bytes, configuration errors, unsupported circumstances, or a wrong protocol assumption. Test these systematically. “Wireshark cannot decrypt it” is an observation about the current setup, not proof that authorized decryption is impossible.

Treat secrets and decrypted payloads as sensitive. Do not upload real customer captures or key logs to public forums. A PCAPNG can also carry sensitive metadata or embedded secrets. Use scoped access, retention rules, sanitized examples, and a secure transfer route when collaboration is necessary.

Read filter expressions precisely

Begin with a narrow predicate whose meaning you can say aloud. ip.addr == 192.0.2.10 concerns an IPv4 address field, while tcp.port == 443 concerns TCP ports. Documentation-reserved addresses in examples are not real targets. Combine predicates only after checking what each selects in the actual capture.

Be careful with fields that can occur more than once in a packet. Equality and inequality do not always behave like comparing a single scalar variable. The display-filter manual explains field comparisons and operators; consult the installed version rather than guessing how a negated expression handles absent or repeated fields.

For a “not this host” question, say whether you mean neither endpoint is that host, not merely that one address field differs. Validate your expression against packets going both to and from the host. For IPv6 traffic, an IPv4-only filter can miss the conversation altogether.

Use named fields rather than searching arbitrary bytes when the protocol is decoded. But if the required field is absent because dissection or decryption has not succeeded, changing the comparison value will not solve the upstream problem. This is another reason to separate collection, interpretation, and selection.

Use TShark to make an investigation repeatable

The TShark manual distinguishes capture filtering from display filtering and documents field output. For a previously recorded, authorized capture, a documentation-grounded command might be:

tshark -r sample.pcapng -Y 'tcp.port == 443' \
  -T fields -e frame.number -e frame.time_relative \
  -e ip.src -e ip.dst -e tcp.stream

Here -r reads a file and -Y applies a display filter. This is not a command that captures new traffic, and it does not decrypt TLS by itself. IPv6-only packets may have empty ip.src and ip.dst fields; include IPv6 fields when your investigation requires them.

Before automating, check the command against a small known capture and record tool version, preferences, overrides, and field names. An empty export can mean no matches, a field mismatch, or missing capture evidence. Preserve the command's errors instead of silently treating every failure as zero packets.

The ledger selection in this article can be checked offline as simple set logic. That does not replace running Wireshark or TShark against a PCAP to test real dissection, reassembly, or filter parsing. Keep that execution boundary visible in an interview submission.

Practice evidence-first networking answers

For each, name the observation, the inference, and the missing evidence separately.

Question	Capture question to add
Explain TLS Handshakes and HTTPS Traffic Inspection	Which handshake fields and secrets are actually available?
Design a packet reassembler API	What happens when segments are missing or reordered?
Implement a Simplified DNS Resolver	Did the capture retain the lookup and response?
Trace a Web Page Load Through the Browser	Which stages are visible at this capture location?
Does a Successful Ping Mean Port 443 Is Reachable? Diagnosing Server Connectivity	Does the evidence establish ICMP, TCP, TLS, or application success?

Continue with Software Engineering Fundamentals. A strong answer is not “use Wireshark.” It is a scoped collection, a precise filter, a justified interpretation, and a clear limit on what the capture can prove.

Sources and Further Reading

• Wireshark User's Guide
• Wireshark display-filter manual
• Wireshark capture filters
• Wireshark TLS decryption
• TShark manual

Documentation checked October 4, 2026. The packet ledger is synthetic; no real PCAP, decryption result, or customer traffic is presented.