Wireshark Part 01 — Capture, Read, and Filter Your Own Traffic

Capture and read your own traffic with Wireshark, using scoped filters, packet details, and a short authorized exercise.

Series index · Next: Connection failures

Sources checked 18 September 2026 · Exercises have not been run on THL hardware.

Use case: Build a trustworthy capture before attempting a diagnosis. By the end, you should be able to identify your capture interface, explain one request/reply exchange, and save a private PCAPNG file.

Legitimate use: Learn protocols and troubleshoot your own applications. Harmful use: Monitor other people’s activity without authorization or pass sensitive packet captures to people outside the agreed scope. Even an apparently passive capture can expose private information. The capture point and permission determine what is appropriate.

Wireshark is a packet analyzer. It records and decodes traffic available at a capture point; it does not automatically see an entire switched network, recover every password, or diagnose every fault. Wireshark introduction

Permission comes first

Use these exercises only on a lab you control or within explicit authorization from the responsible network owner. Permission to join a Wi-Fi network is not permission to capture other users’ traffic or audit their passwords. A previous college exercise does not authorize testing that college’s network today.

For an institutional exercise, obtain a written scope identifying the network, access points, test devices/accounts, permitted capture and password-testing methods, time window, data handling, and a contact who can stop the exercise. Authorization must cover password testing separately if it is part of the work. Applicable law and organizational rules still apply.

Use disposable credentials and test devices. Keep captures and recovered test passwords private; they can contain identifiers, application data, and authentication material. Stop if unrelated traffic or real credentials enter the exercise. This guide uses ordinary connections by your own test client; it does not require disconnecting other users or impersonating an access point.

1. What Wireshark can see

The capture point determines what you can observe. Capturing on your laptop normally shows its traffic and some local broadcast/multicast traffic. It does not automatically show every device on the network.

Capture situation What to expect
Your computer’s normal Ethernet or Wi-Fi interface Traffic delivered to or sent by that interface; useful for investigating your own applications.
A supported Wi-Fi interface in monitor mode Raw 802.11 frames received on the selected channel, potentially including nearby networks. Hardware, drivers, channel, and capture quality limit visibility.
An existing training capture Only what was recorded at its original capture point. Missing packets cannot be recovered by changing a display filter.

Promiscuous mode and monitor mode are different. Promiscuous mode does not make a Wi-Fi adapter a universal radio sniffer. Raw Wi-Fi capture requires support across the adapter, driver, operating system, and capture software; normal Wi-Fi captures may instead look like Ethernet. Wireshark WLAN capture guide

Encryption is another boundary. You may observe addresses, timing, lengths, and some protocol metadata while the application content remains encrypted. Knowing a Wi-Fi password does not automatically reveal HTTPS messages: Wi-Fi encryption and TLS protect different layers. TLS analysis needs appropriate session secrets to show encrypted content. Wireshark TLS guide

2. Install and prepare

For the first exercise, use your existing computer on an authorized network. No new equipment is needed to learn from saved training captures.

  1. Download a current stable release from the official Wireshark download page.
  2. On Windows, install the Npcap capture component offered by the installer if it is not already installed appropriately. On macOS or Linux, follow Wireshark’s platform instructions for capture permissions. Run the main application with ordinary user privileges where the installation permits it. Capture privileges
  3. Create a private local folder for the exercises. Avoid shared or automatically synchronized folders for raw captures and recovered passwords.
  4. Close unrelated applications to reduce background traffic. Record your Wireshark version under Help → About Wireshark.

Windows users do not need raw 802.11 monitor mode for the first exercise. Npcap’s optional raw wireless support is relevant to the later radio-capture exercise and still depends on the adapter and driver. Npcap users’ guide

3. Make your first capture

This Windows example generates a DNS lookup, a few pings to your own gateway, and one ordinary web request. Use an authorized test network and do not sign into accounts during the exercise.

  1. Open PowerShell and run ipconfig. Find the active connection’s IPv4 address and Default Gateway. Keep these as your reference addresses.

  2. In Wireshark, open Capture → Options. Select the interface associated with that connection. Its activity graph should move when the connection is in use. Leave monitor mode off, and disable promiscuous mode for this exercise. Leave the capture filter empty for this short, controlled capture.

  3. Click Start. In PowerShell, run:

    nslookup example.com

    Then send four pings to your own gateway. Replace the example address below with the gateway shown by ipconfig:

    ping -n 4 192.168.1.1

  4. Visit https://example.com in your browser. After roughly 20–30 seconds of capture, click Wireshark’s red Stop button.

  5. Select File → Save As and save first-capture.pcapng in your private exercise folder. PCAPNG is Wireshark’s default capture format. Starting a capture, capture options

Expected observations depend on your setup. DNS queries and replies may appear, pings may show requests and replies if the gateway answers, and browser traffic will usually include TLS or QUIC. A VPN can change which interface exposes these packets. A blocked ping does not, by itself, establish a broken network.

If live capture is unavailable, open a suitable file from Wireshark’s sample captures collection with File → Open and practice the following inspection steps. Use a current Wireshark release when opening downloaded captures.

4. Read a packet

The main window normally contains three useful panes:

Pane How to use it
Packet list Pick a packet by time, source, destination, protocol, length, or the Info summary.
Packet details Expand the decoded layers: link layer, IP, TCP/UDP, and application protocol where available.
Packet bytes Inspect the underlying bytes. Readable fragments are not a complete reconstruction of a conversation.

Selecting a field in the details pane highlights its bytes. Start with decoded fields; memorizing hexadecimal is unnecessary. Main window

Try these small investigations on first-capture.pcapng:

  • Enter dns in the display-filter bar and press Enter. Select a query, expand Domain Name System, and find the requested name. Locate the corresponding response and inspect its answer or error code. A name may resolve to several addresses.
  • Enter icmp. Compare an echo request and reply using their identifier and sequence number. An IPv6 ping uses icmpv6 instead.
  • Enter tcp.flags.syn == 1 to find connection attempts. Select a SYN packet, expand Transmission Control Protocol, and note its Stream index. Replace the filter with tcp.stream == N, substituting that index for N. You can now look for the SYN, returning SYN/ACK, and following ACK; the earlier SYN-only filter would hide that third packet. An already-established connection or a QUIC conversation will not show this sequence.
  • Enter tls or quic. You may see protocol exchanges and encrypted data, but should not expect the page text or login passwords in plaintext.

The DNS and TCP field references explain the decoded fields. Clearing the display-filter bar restores the full packet list.

5. Use the right kind of filter

A capture filter decides which packets get recorded. A display filter selects which recorded packets you currently see. Their syntax is different, and a display filter does not remove hidden packets from the capture file. Capture filters, display filters

Task Capture filter, set before capture Display filter, applied to recorded packets
Traffic involving an example IPv4 address host 192.168.1.50 ip.addr == 192.168.1.50
TCP traffic involving port 443 tcp port 443 tcp.port == 443
Traffic involving TCP or UDP port 53 port 53 tcp.port == 53 or udp.port == 53

Replace example addresses with your own. An IPv4 host filter can exclude IPv6 and non-IP traffic; port 53 is not a universal filter for encrypted DNS. Port numbers alone do not establish an application’s identity.

Useful display filters to keep nearby:

Filter Purpose
dns Decoded DNS traffic.
arp Local IPv4 address-resolution traffic.
icmp or icmpv6 ICMP traffic, including ping.
tcp or udp Packets containing either transport protocol.
tcp.analysis.retransmission Packets Wireshark labels as suspected TCP retransmissions.
tcp.flags.reset == 1 TCP reset packets.
tls or quic Decoded TLS or QUIC traffic.
eapol EAP over LAN, including applicable Wi-Fi key exchanges.
wlan Decoded raw 802.11 traffic, if present.

These are display filters, entered above the packet list. The wireless entries are documented in the EAPOL and 802.11 references.

6. Move from individual packets to conversations

For TCP, select a packet and use right-click → Follow → TCP Stream. Wireshark gathers the stream’s captured data into a conversation view. Plaintext protocols may be readable; following a stream does not decrypt TLS. Following streams

Use Statistics → Conversations to compare endpoint pairs and their packet/byte counts. Use Statistics → I/O Graphs to see when traffic rises and falls. Check whether each view is limited to the current display filter before interpreting its totals. These describe the capture, not all network activity everywhere. Conversations, I/O graphs

Analyze → Expert Information highlights conditions worth investigating. A retransmission flag or warning is a clue, not a diagnosis or proof of an attack; an incomplete capture can complicate interpretation. Expert Information

Exercise and completion check

Save a short authorized capture, locate one query and its response (or document the missing response), and write five lines: capture point, test action, display filter, relevant packet numbers, and what remains unknown. Use the capture worksheet.

You have completed this part when another reader can locate your evidence and distinguish your observation from your explanation. If live capture is unavailable, complete the same task using a benign training capture and record its source.

Continue with Part 02: Connection failures. For a controlled Wi-Fi authentication exercise, read Part 06.