Wireshark Capture and Save

Capture With a Clear Purpose

A stated CCST Networking objective is to perform a packet capture with Wireshark and save it to a file. That is an entry-level practical skill: open the tool, choose the right interface, capture the right moment, save the evidence, and handle the file responsibly. You do not need to decode every protocol field; you do need to avoid aimless captures that miss the problem or expose unnecessary data.

Wireshark records frames seen by a chosen interface. On an endpoint that is normally the traffic that host sends or receives, plus local broadcast and multicast. Because modern switches forward unicast only to the right port, a laptop will not see other devices' conversations. To capture another device's traffic, an engineer configures a SPAN (Switched Port Analyzer / port mirror), inserts a network tap, captures on a firewall, or pulls data from a wireless controller. A CCST technician follows those instructions rather than improvising monitoring on production gear.

A Disciplined Capture Procedure

1. Get authorization and define the test: user, device, path, symptom, destination, and reproduction steps.
2. Pick the correct interface (Wi-Fi vs. Ethernet vs. USB adapter). The interface list shows live sparkline graphs, follow the one with the relevant activity. If both Wi-Fi and wired are connected, confirm which carries the problem traffic.
3. Start the capture a few seconds before reproducing the fault.
4. Perform the minimum action: open the failing site, renew DHCP, ping the gateway, sign in, or hit the printer.
5. Stop soon after the failure. Short captures analyze faster and leak less sensitive data.
6. Save and annotate with the matching window: capture started 10:05:12, opened intranet portal 10:05:30, browser timed out 10:06:01, stopped 10:06:20.

Capture Filters vs. Display Filters

This distinction is exam-classic. A capture filter (set before you start, BPF syntax like host 192.0.2.10 or port 443) controls what is ever written, too narrow and the important packets are never saved. A display filter (applied after capture, Wireshark syntax) only changes what you see and never discards saved data. For entry-level work, capture a short unfiltered reproduction, then narrow the view with display filters.

Reading patterns is where captures earn their keep at this level:

• ARP shows IPv4-to-MAC discovery, useful for confirming a host found its gateway's MAC.
• DHCP shows the Discover, Offer, Request, Acknowledge (DORA) exchange, a missing Offer means no server answered.
• DNS shows queries and answers, including no-response or SERVFAIL cases.
• A TCP handshake should show the client SYN, the server SYN-ACK, then ACK; a SYN with no reply, or an immediate RST, suggests a firewall block or a closed port.

TLS/HTTPS hides the payload, but addresses, ports, timing, and handshake behavior remain visible and useful. Never claim to read encrypted application content from an ordinary capture, doing so unless the traffic was decrypted through approved means is both wrong and a privacy risk. Color coding helps too: by default Wireshark tints bad-checksum and RST/retransmission packets in red-ish hues, drawing the eye to problems, but those colors come from display coloring rules and do not change what was captured.

Worked Scenario

A laptop intermittently fails to load an internal portal. You start a capture on the Wi-Fi interface, reproduce the failure once, and stop. Applying the display filter dns, you see a query for the portal name with no response, then a retry, then a SERVFAIL. The capture has proven the problem is name resolution at this client, not the web server, and you attach the file with the time range to the ticket.

In a second case the dns filter shows a correct answer, but tcp.port == 443 shows the client sending SYN packets with no SYN-ACK in return, evidence of a firewall block or a down service on the path, again something you can prove rather than guess.

Save and Protect the File

Save in the standard .pcapng format unless told otherwise, with a clear, secret-free name like ticket-1842-laptop-wifi-dns-timeout-2026-05-06.pcapng. Store it in the approved location and attach it only if policy allows. Captures can contain usernames, hostnames, internal IPs, cookies, session tokens, DNS queries, and sometimes cleartext credentials, so treat every capture as sensitive evidence.

Practical handling rules at CCST level:

• Capture the shortest window that reproduces the symptom; long captures bloat the file and multiply the sensitive data inside it.
• Never share a capture in a public channel, paste, or screenshot, route it through the approved evidence location only.
• Delete local copies once the ticket is resolved, per your retention policy.
• Give the engineer a one-line summary plus the exact start/stop times so they can jump to the relevant packets without scrolling the whole file.

Following these rules keeps you within the exam's emphasis on authorized, focused, well-documented capture, the objective is to produce a useful, saved file responsibly, not to monitor everything everywhere.