Wireshark Investigations: Seeing the Network

Wireshark Investigations: Seeing the Network

What you'll learn

• Choose between a capture filter and a display filter — and explain why professionals capture broad and display narrow
• Write display filters in Wireshark's mini-language: addresses, ports, protocols, and combinations
• Read a whole conversation at once with Protocol Hierarchy, Conversations and Follow TCP Stream
• Use Expert Information as a triage list instead of scrolling thousands of rows
• Extract evidence from a capture the way a professional writes up a finding — and handle captures ethically

This lesson builds on Chapters 10 and 13 of Dr. Tahseen Al-Doori's Network Essentials. Chapter 13 introduces the protocol analyzer as the deepest instrument in the management toolkit and points students at Wireshark by name — free then, free now, industry standard both then and now. What the book could only gesture at in print, you will do at the keyboard.

Two filters, two moments: capture vs display

Wireshark has two filtering systems, and confusing them is the classic beginner tangle — so here is the professional distinction up front.

A capture filter is applied while recording: packets it rejects are never written down, and no power on earth brings them back afterward. It is typed into the filter box on the welcome screen before you start, in a terse older syntax (host 192.168.1.23, port 53, not arp) shared with the command-line tool tcpdump.

A display filter is applied while viewing: the full capture stays on disk, and the filter merely hides rows from your eyes. Change it, clear it, contradict yourself — every packet is still there. It is typed into the green bar above the packet list at any time, in Wireshark's own richer field language.

The professional default follows from one asymmetry: you cannot analyze what you did not record. At investigation time you rarely know which packets will matter — the fault may live in a protocol you did not suspect. So: capture broad, display narrow. Record everything on the interface; carve the view down afterward with display filters, as many times as you like. Capture filters earn their place in one situation — genuinely high-volume, long-running captures (a busy server port, an overnight recording) where writing everything would drown the disk. On your laptop, in this course: capture filter box empty, always.

The display-filter mini-language

A display filter is a small expression about packet fields — the same "header as a database of fields" idea from Module 2, now queryable. The bar itself coaches you: it glows green when the expression is valid, red when malformed, and autocompletes field names as you type. The core vocabulary:

Expressions combine with && (and), || (or), ! (not), and parentheses: ip.addr == 192.168.1.23 && dns reads "this machine's DNS traffic." Two habits complete the craft. First, right-click any field in the packet details pane and choose Apply as Filter — Wireshark writes the expression for you, which is also how you learn field names. Second, when a filter shows nothing, clear it before doubting your capture: the packets may be there and your expression wrong (the classic slip: ip.addr = x with one equals sign — red bar — instead of ==).

One caveat from your own Module 2 capture applies forever: on a switched network your interface sees your own conversations plus broadcasts — not your neighbors' traffic. Filters reveal what was captured; they do not extend what was capturable.

Reading a conversation, not a packet

Beginners read captures one row at a time. Investigators start from the summaries.

Statistics → Protocol Hierarchy answers "what is in this capture?" in one table: percentages by protocol, nested by layer. A capture that is 40% ARP is telling you something is shouting; a capture with zero DNS while the user reports "web is broken" is telling you where the break is not.

Statistics → Conversations lists every pair of endpoints that talked — who, to whom, how many packets, how many bytes, how long. Sort by bytes and the bandwidth hog surfaces; sort by packets with a tiny byte count and you find the chatterer that says much and transfers nothing.

Follow → TCP Stream (right-click any TCP packet) is the analyst's favorite view: Wireshark reassembles the entire conversation into readable text, one side tinted red, the other blue — for unencrypted protocols, the actual request and response as the applications spoke them. It also quietly applies a filter (tcp.stream == N) isolating that one conversation in the packet list. Two notes: streams are numbered from 0 in capture order, and for TLS-encrypted conversations the stream view shows the handshake then ciphertext — proof of encryption doing its job, and a reminder of why the lab uses a deliberately plain-HTTP target.

Analyze → Expert Information is Wireshark's own triage list: it scans the capture and groups notable events by severity — retransmissions, resets, duplicate ACKs, malformed packets. It is a list of leads, not verdicts: a few retransmissions are life on a normal network; hundreds clustered on one conversation are a story. Open Expert Information first, scroll last.

From packets to evidence

An investigation ends in a finding someone else can trust — which is a documentation discipline (the theme returns in lesson 4):

• Record the frame numbers. "Frames 218–224 show the failed lookup" lets any colleague jump straight there.
• Record the filter that isolates the evidence — the filter is the reproducible experiment.
• State the absence as carefully as the presence. "No DNS response within the capture window" is evidence; write what is not there.
• Export the minimum. File → Export Specified Packets saves just the displayed/marked frames — the evidence excerpt, not your whole browsing history.

That last point opens the ethics note this tool demands. A packet capture is surveillance — of yourself at minimum, and on shared networks potentially of others. The professional rules are not optional: capture only on networks and machines you own or have explicit authorization to analyze; treat capture files as confidential documents (they contain addresses, names, sometimes credentials); share excerpts, not full captures; and delete what you no longer need. In many jurisdictions intercepting others' communications is a crime. In this course every capture is of your own machine's traffic, generated by you — keep that standard for life, and when in doubt, ask before you capture.

From the textbook to 2026

Chapter 13's advice — download the free analyzer from wireshark.org and learn it by playing — has aged perfectly; the program it recommended went on to become the undisputed standard, and the fundamentals taught here (filters, streams, hierarchy) have been stable for a decade. What moved: Wireshark now lives on major version 4.x with a refreshed interface, ships with the Npcap driver on Windows (your Module 2 install), and its display-filter language keeps growing new protocol fields as the Internet does. Encryption's rise is the deepest shift — in 2007 an analyzer read most application traffic in cleartext; today TLS wraps the web, so investigators lean harder on metadata (who, when, how much, handshake behavior) than on payload reading. The craft adapted; the instrument endures.

Watch: Learn Wireshark! Tutorial for BEGINNERS

Why this video earns its place. Chris Greer is a Wireshark University instructor and working packet-analysis consultant, and this tutorial — the opening lesson of his widely recommended beginner series — is the industry's default answer to "where do I start with Wireshark?" His stated mission is exactly this course's spirit: Wireshark feels hard, and it does not have to be. Watching a professional drive the interface — where his eyes go, what he ignores, how casually he filters — adds something prose cannot: the rhythm of an investigator at the keyboard. It runs about sixteen minutes.

As you watch, notice:

• How he sets up the capture before generating interesting traffic — the same order your lab recipes below follow.
• Where filtering enters his workflow, and which filter type he reaches for — connect it to this lesson's capture-broad, display-narrow rule.
• His interface orientation: the packet list, details and bytes panes you have used since Module 2, now navigated at professional speed.
• What he treats as ignorable noise in a fresh capture — beginners try to explain every packet; professionals triage.
• One caveat as you watch: the video predates today's Wireshark 4.x, so a few menus and defaults have shifted slightly on your screen — every concept transfers unchanged. And it is the first lesson of a series focused on setup and orientation: the deeper analysis moves (streams, Expert Information) are the sections you just read.

The video reinforces visually what you just learned — the lesson is complete without it.

Lab: Three Mini-Investigations

Three small cases, each staged by you: a recipe generates the traffic, then you investigate your own capture and extract the evidence. Do them in order — each uses one more analysis tool than the last. Expect the whole lab to take under an hour.

Objective. Run three authored investigations end to end: generate, capture, filter, analyze, and write a two-line finding with frame numbers for each.

Setup. Wireshark installed (Module 2 lab). A terminal beside it. Capture on your active interface with the capture-filter box empty each time; stop each capture before analyzing. Keep a findings file open — for each case record: filter used, key frame numbers, finding in one or two sentences.

Investigation 1 — The lookup that fails.

The case: a user reports a website "doesn't exist." Prove what the DNS server actually said.

1. Start a capture. In the display-filter bar type dns (green bar, Enter).
2. In the terminal: nslookup www.this-name-should-not-exist.invalid — the .invalid ending is a reserved name guaranteed by Internet standards never to resolve; the lookup will fail, by design.
3. For contrast: nslookup example.com. Stop the capture.
4. Find the failing exchange: query rows ("Standard query" for your .invalid name) and the response. Click the response; in the details pane expand the DNS section and find Reply code. Tighten the view with dns.flags.rcode != 0.

Expected findings. The failed response carries reply code 3 — No such name (NXDOMAIN): the server answered correctly that the name does not exist. The example.com response carries reply code 0 and an answer with an address. This is the professional distinction: "DNS is broken" (no response at all) versus "DNS works and says no" (rcode 3) are different diagnoses with different fixes.

Verify. Filter dns.flags.rcode == 3 shows at least one packet; your notes name its frame number and the responding server's address (compare with the resolver you identified in the last lesson's relay, step 9).

If it goes wrong. No DNS packets at all: wrong interface, or your system answered from cache — flush it (ipconfig /flushdns / resolvectl flush-caches) and rerun. You see the query but the response reports code 0 with an answer for a nonexistent name: some ISP resolvers "helpfully" hijack failures to an advertising page — you have just discovered and documented resolver misbehavior; note it as your finding (and this is exactly why .invalid plus rcode inspection beats trusting the browser). Browser-generated lookups missing: modern browsers often use encrypted DNS (DoH over port 443), invisible as classic port-53 traffic — the recipe uses nslookup precisely because it speaks classic DNS.

Investigation 2 — One complete conversation.

The case: capture a single HTTP connection whole — birth (handshake), life (request/response), death (close) — the Module 5 handshake, now investigated with professional tools.

1. Start a fresh capture. Display filter: tcp.port == 80.
2. In the terminal: curl http://example.com/ (curl ships with modern Windows and Linux; we use plain HTTP deliberately — a browser might upgrade to HTTPS and hide the payload).
3. Stop the capture. Identify in the Info column: the opener [SYN], the answer [SYN, ACK], the confirmation [ACK] — then the GET / request, the 200 OK response, and the closing [FIN, ACK] exchange.
4. Right-click any of these packets → Follow → TCP Stream: the whole conversation as text, request tinted one color, response the other.
5. Open Statistics → Protocol Hierarchy and find where HTTP nests under TCP under IP — your Module 2 envelope story, as a live table of this very capture.

Expected findings. Exactly one TCP stream (tcp.stream == 0 if it was your only port-80 conversation): three handshake packets, a readable GET and an HTTP/1.1 200 OK with HTML following, then FIN/ACK closure from both sides. Note the elapsed time from SYN to first response byte — your first latency measurement from packets rather than ping.

Verify. Your notes contain: the stream number, the three handshake frame numbers in order, and the response status line quoted from the stream view.

If it goes wrong. Nothing on port 80: your network may force HTTP through a proxy or block it — try filter tls and observe how an encrypted fetch (curl https://example.com/) differs: handshake visible, payload unreadable; document that as the finding instead (equally instructive). Multiple streams: other software chattered on port 80; use Follow on the one whose stream shows your GET.

Investigation 3 — The ARP chorus.

The case: create a miniature burst of ARP broadcasts — a controlled, tiny echo of the broadcast behavior you studied in Module 3 — and read it.

1. Note your own address and gateway (last lesson's relay, step 1). Pick two more addresses on your subnet near yours (say .13 and .14 if you are .12) — whether or not devices live there is part of the experiment.
2. Clear the neighbor cache so ARP must work fresh: Windows (administrator terminal): arp -d * · Linux: sudo ip neigh flush all.
3. Start a capture. Display filter: arp.
4. Ping the gateway, then each of your two chosen addresses (4 probes each). Stop the capture.

Expected findings. A chorus of broadcast frames reading Who has <address>? Tell <you> — destination ff:ff:ff:ff:ff:ff, heard by every machine on the LAN. The gateway's entry produces a prompt unicast reply (<address> is at <MAC>). An address where no device lives produces the most instructive pattern: the same who-has question repeated, again and again, with no answer — your machine politely re-asking an empty room. Back in the terminal, those failed pings reported Destination host unreachable from your own address — the last lesson's message table, now explained at frame level: ARP found nobody, so no frame could ever be addressed.

Verify. Your notes name: one who-has/reply pair with frame numbers (the gateway), and one repeated unanswered who-has (the empty address). Bonus check: arp -a / ip neigh now shows the gateway relearned — and nothing for the empty address.

If it goes wrong. No administrator rights for step 2: skip the flush — you will simply see fewer ARP requests (cached neighbors need no asking); pinging the two probably-empty addresses still produces the unanswered chorus. Both extra addresses answered: you guessed two live devices — pick two others further from the crowd (high numbers like .240 are usually quiet). On some Wi-Fi networks, client isolation prevents neighbor replies — the gateway exchange still demonstrates everything.

Expected result (whole lab). A findings file with three entries, each carrying filter, frame numbers, and a one-or-two-sentence conclusion — three complete investigations, from staging to evidence.

Reset/cleanup. Stop all captures. The ARP cache and DNS cache rebuild themselves. Apply the ethics rule from this lesson: these captures contain your machine's addresses and activity — keep them private, delete them when the module ends.

Check yourself

1. A colleague plans to diagnose an unknown intermittent fault by capturing overnight with the filter port 53 "to keep the file small." Name the risk, the rule it violates, and when their approach would be right.
2. Write display filters for: (a) all traffic to or from 10.0.0.7; (b) only DNS error responses; (c) the first packet of every TCP handshake in the capture.
3. In Follow TCP Stream, a conversation shows a readable handshake summary but the payload is unreadable binary after a Client Hello. What are you looking at, and is the capture broken?
4. Protocol Hierarchy shows a capture is 45% ARP by packets. Using Module 3's vocabulary, what condition might you suspect, and which single Wireshark view would you open next to find the loudest speaker?
5. During Investigation 1, a user's browser said "site not found," but your capture shows no DNS packets at all when they retry. Give two realistic explanations from this lesson.
6. Why does "no response present in the capture" count as evidence, and what must your write-up include to make that absence trustworthy?

Answers

1. Everything that is not DNS is discarded forever — and an unknown fault may live anywhere; this violates capture-broad, display-narrow. A capture filter is right when volume genuinely forbids recording everything (busy servers, very long captures) and the protocol of interest is already known.
2. (a) ip.addr == 10.0.0.7 · (b) dns.flags.rcode != 0 · (c) tcp.flags.syn == 1 && tcp.flags.ack == 0.
3. A TLS-encrypted conversation: the handshake negotiates keys in the clear, then everything after is ciphertext. The capture is perfect — encryption is simply doing its job; analysis proceeds on metadata (timing, sizes, endpoints).
4. Broadcast-heavy traffic suggests trouble in a broadcast domain — at the extreme, storm-like behavior from a loop or a misbehaving host. Open Statistics → Conversations and sort by packets to identify which machine is generating the flood.
5. The answer came from a local cache (browser or OS), so no query hit the wire; or the browser resolves via encrypted DNS (DoH), whose traffic rides TLS on port 443 and never appears as classic DNS.
6. Because a missing reply localizes the fault (the question was asked; nothing answered). To be trustworthy the write-up must show the query is present (frame number), state the filter used, and give the capture window — otherwise "absent" might just mean "not captured."

Key terms

• Capture filter — applied while recording; rejected packets are never stored (tcpdump syntax, set before starting).
• Display filter — applied while viewing; hides rows reversibly (Wireshark field language, green/red bar).
• Capture broad, display narrow — the professional default; you cannot analyze what you did not record.
• ip.addr / tcp.port / protocol-name filters — the core display vocabulary, combinable with &&, ||, !.
• Protocol Hierarchy — the capture's composition by protocol and layer, in one table.
• Conversations — every endpoint pair with packet/byte counts; the who-talked-to-whom summary.
• Follow TCP Stream — a whole conversation reassembled as two-tone text; applies a tcp.stream == N filter.
• Expert Information — Wireshark's severity-graded list of notable events; triage, not verdicts.
• Reply code (rcode) — the DNS response verdict: 0 success, 3 no-such-name (NXDOMAIN).
• NXDOMAIN — "the name does not exist," said authoritatively — DNS working, answer negative.
• Export Specified Packets — saving only the evidence excerpt rather than the whole capture.

Summary

• Capture filters decide what is recorded (irreversible); display filters decide what is shown (reversible) — capture broad, display narrow.
• The display-filter language queries header fields directly: ip.addr ==, tcp.port ==, bare protocol names, boolean combinations — with Apply-as-Filter as the built-in teacher.
• Investigations start from summaries: Protocol Hierarchy for composition, Conversations for who-talked-to-whom, Follow TCP Stream for one dialogue whole, Expert Information for triage.
• Evidence discipline: frame numbers, the exact filter, stated absences, minimal exports — a finding a colleague can reproduce.
• Captures are surveillance: authorization first, confidentiality always, excerpts not archives, deletion when done.
• Three investigations staged and solved: a DNS server saying no (rcode 3), one TCP conversation from SYN to FIN, and an ARP chorus explaining a command-line error message at frame level.

Next lesson

From the microscope to the boardroom: the next lesson is about keeping networks alive — uptime arithmetic, the risk-and-money argument that funds reliability, RAID, backups, power protection and QoS. Bring a calculator; the packets rest for a lesson.

Sources and further study

• Al-Doori, T., Network Essentials, Chapters 10 and 13 — the protocol analyzer's place in the toolkit and the management view of network instruments.
• Wireshark User's Guide — https://www.wireshark.org/docs/wsug_html_chunked/ — the official manual; the filtering chapters extend this lesson directly.
• Wireshark Wiki, "DisplayFilters" — https://wiki.wireshark.org/DisplayFilters — worked filter examples for daily use.
• Wireshark Wiki, "SampleCaptures" — https://wiki.wireshark.org/SampleCaptures — practice captures for every protocol in this course, when you want more cases.
• Download: Ports and Protocols Reference (the Module 5 card — port numbers are how you name what your filters find).