Wireshark for Beginners: What to Look for in Your First Packet Capture

You can open Wireshark, start a capture, and collect thousands of packets before you have decided what you are looking for.

That is a fast way to make networking feel harder than it is.

Your first capture should be small and slightly boring on purpose. Generate a few kinds of traffic yourself. Stop the capture. Then find the packets you expected to create.

You are not trying to memorize every field in Wireshark.

You are trying to answer questions:

• Which device sent this?
• Where was it going?
• Which protocol carried it?
• Did a request receive a response?
• Did a connection establish successfully?
• Where did the behavior stop matching what you expected?

The packet list is evidence. Start with a question and make the evidence smaller.

2. What Wireshark Actually Shows

Wireshark is a network protocol analyzer. It can capture traffic from supported interfaces or open previously saved capture files and dissect the packets into protocol fields you can inspect.

That makes Wireshark useful for:

• Learning how protocols behave
• Troubleshooting network communication
• Comparing working and broken behavior
• Inspecting request-and-response sequences
• Following conversations between systems
• Reviewing packet captures during security analysis

Wireshark is mostly an observation tool.

It does not discover open ports the way Nmap does. It does not make a firewall allow traffic. It does not prove that an application is healthy simply because packets reached the server.

It shows you network evidence from the place where the capture occurred.

That last part matters. Wireshark's own capture guidance notes that you must choose the right interface and capture at the right place in the network to see the traffic you care about.

3. Start With a Controlled Capture

For a first exercise, capture traffic from your own computer on a network you own or are authorized to inspect.

On Windows, the official Wireshark installer includes Npcap, which is required for live packet capture. You can still open saved capture files even if live capture is not available.

When Wireshark opens, the welcome screen lists available capture interfaces. Activity beside an interface appears as a small sparkline. If you are connected through Wi-Fi, the active Wi-Fi interface is usually the useful starting point. If you are connected through Ethernet, choose the active Ethernet interface.

Do not start by selecting every interface.

Pick the one carrying the traffic you intend to generate.

Create traffic you can recognize

On Windows, open Command Prompt and run:

ipconfig

Find the Default Gateway for the active adapter.

Start the Wireshark capture, then generate three simple kinds of traffic:

nslookup example.com && ping -n 2 <default-gateway> && curl -I https://example.com

Replace <default-gateway> with the gateway address shown by ipconfig.

This should give you several useful things to find:

• A Domain Name System (DNS) lookup
• Internet Control Message Protocol (ICMP) echo traffic to the gateway
• A Transmission Control Protocol (TCP) connection
• Transport Layer Security (TLS) traffic for HTTPS

Stop the capture after the commands finish.

The exact packet sequence can vary by operating system, cache state, network configuration, Internet Protocol version, and application behavior. That variation is useful. Your job is to explain what your computer actually did, not force the capture to match a diagram.

If live capture setup gets in the way of learning, Wireshark maintains a SampleCaptures collection with saved packet captures you can open without generating the traffic yourself.

4. Read the Three Main Panes

Wireshark's default packet view gives you three important levels of detail.

Packet List

Each row represents one captured packet.

The default columns include:

• Packet number
• Time
• Source
• Destination
• Protocol
• Length
• A short Info summary

Start here.

If you see a DNS row, a TCP SYN, or an ICMP echo request, you already have a useful clue about what that packet is doing.

Packet Details

Select one packet and the middle pane shows the decoded protocol layers as an expandable tree.

A typical Ethernet TCP packet might contain layers such as:

Ethernet → Internet Protocol → TCP → TLS or application data

Expand one layer at a time.

This is where you can inspect fields such as:

• Media Access Control (MAC) addresses
• IP addresses
• Source and destination ports
• TCP flags
• Sequence and acknowledgment information
• DNS query names and answers
• ICMP types
• TLS handshake information

Packet Bytes

The bytes pane shows the raw packet data in hexadecimal and ASCII form.

It is useful when you need to connect a decoded field to the bytes that produced it.

You do not need to begin there. The hex pane is useful, but it is not an entrance exam.

Start with the summary, expand the protocol fields, and go to the bytes when the raw representation helps answer a question.

5. Use Display Filters First

A short capture still contains background traffic.

Display filters let you hide packets that do not match the question you are asking without deleting them from the capture.

Try these one at a time:

Wireshark's display filter language can go much deeper than these examples. For a first capture, protocol names are enough to reduce the noise and reveal a sequence.

A display filter changes what you see, not what the capture file contains.

That is why it is safe to experiment with them.

6. Find the DNS Exchange

Apply:

dns

Look for the query created by nslookup example.com.

A basic DNS exchange gives you a useful request-and-response pattern:

1. Your system sends a query to a DNS server.
2. The query identifies the name and record type being requested.
3. The DNS server returns a response.
4. The response may contain one or more answers or indicate another result.

Select the query and expand the DNS section in Packet Details.

Then inspect the response.

Questions to ask:

• Which DNS server received the query?
• Was the query for an A record, an AAAA record, or something else?
• Did the response contain an answer?
• Which IP addresses were returned?
• How much time passed between the query and response?

You may see both IPv4 and IPv6-related lookups.

You also may notice that browser traffic does not always produce ordinary DNS packets you can see. Browsers and operating systems can use caches or encrypted DNS mechanisms. Using nslookup gives you a more deliberate DNS exchange for this exercise.

The lesson is not "DNS always looks exactly like this."

The lesson is learning how to find a request, identify its response, and inspect the fields that explain what happened.

7. Look for Local Discovery and ICMP

Now try:

arp

If your computer needed to learn the Ethernet address associated with an IPv4 neighbor, you may see an Address Resolution Protocol request and reply.

For example, your computer may effectively ask:

Who has the gateway's IPv4 address?

and the gateway replies with its MAC address.

If you do not see a new ARP exchange, the mapping may already have been cached.

On an IPv6 network, similar local-neighbor work is handled through IPv6 Neighbor Discovery using ICMPv6 rather than ARP. The icmpv6 display filter can expose those messages.

Next try:

icmp

If the gateway answered the ping, you should see echo requests from your computer and echo replies from the gateway.

That gives you another simple question:

Did traffic leave, and did a response return?

A failed ping does not automatically prove the network is down. ICMP can be filtered or disabled. It is one piece of evidence.

8. Follow TCP and TLS

The curl command gives you a more layered exchange.

Start with:

tcp

Look for a new connection associated with the HTTPS request.

A normal TCP connection begins with the familiar three-way handshake:

1. SYN
2. SYN, ACK
3. ACK

Select those packets and expand the TCP details.

The point of the handshake is not to memorize three labels again. You want to recognize what successful connection establishment looks like in captured traffic.

If you see repeated SYN packets with no SYN-ACK returning, that tells a different story than a completed handshake followed by an application problem.

After TCP establishes the connection, HTTPS commonly uses TLS.

Apply:

tls

You may see TLS handshake packets followed by encrypted application data.

TLS is an important lesson in what packet analysis can and cannot reveal.

Without the required TLS secrets, Wireshark does not simply turn encrypted HTTPS application content back into readable web traffic. Wireshark's own documentation notes that TLS decryption requires TLS secrets.

You can still learn a great deal from encrypted traffic:

• Which endpoints communicated
• Which transport protocol and ports were used
• Whether TCP established successfully
• Packet timing and direction
• Connection resets or retransmission behavior
• TLS handshake information that is visible
• How much data moved and when

Also remember that modern web traffic is not always TCP plus TLS. Browsers may use QUIC for HTTP/3, which runs over User Datagram Protocol (UDP). Do not diagnose a missing TCP handshake until you have confirmed that the application was actually using TCP.

9. Follow One Conversation

A busy packet list makes one connection hard to read.

Wireshark can isolate a protocol stream for you.

Select a TCP packet from the connection you care about, then use:

Analyze → Follow → TCP Stream

You can also reach Follow from the packet's context menu.

Wireshark applies a display filter that selects the packets in that stream and opens a stream view.

This is useful even when the application data is encrypted. Close the stream window and study the filtered packet list:

• Which side started the connection?
• Did the handshake complete?
• Which side sent most of the data?
• Was the connection reset?
• Did the exchange stop unexpectedly?

Wireshark supports following several kinds of streams, not only TCP. The current User's Guide lists TCP, UDP, TLS, HTTP, HTTP/2, QUIC, and several others.

For a first capture, TCP is enough.

10. Use Statistics When the Capture Gets Noisy

Filters help when you know what protocol you want.

Statistics help when you do not yet know what dominates the capture.

Two useful starting points are:

Statistics → Protocol Hierarchy

Protocol Hierarchy summarizes which protocols appear in the capture and how much packet and byte activity they represent.

Use it to answer:

• Is this capture mostly TCP or UDP?
• Is there a large amount of DNS?
• Does Wireshark recognize TLS, HTTP, ICMP, or another protocol?
• Which protocol families deserve a closer look?

Remember that protocol percentages overlap because one packet can contain several protocol layers.

Statistics → Conversations

Conversations groups traffic between endpoint pairs.

Use it to find:

• Systems exchanging large amounts of traffic
• A client and server that appear repeatedly
• IPv4 or IPv6 conversations
• TCP or UDP conversations worth isolating

This is often faster than scrolling through thousands of rows hoping an interesting packet introduces itself.

11. Capture Filters vs. Display Filters

Wireshark has two different filter systems, and their similar names cause unnecessary trouble.

The syntaxes are different.

For a beginner working in a quiet lab, a short broad capture plus display filters is usually easier to learn from. You keep the surrounding evidence and can change your question afterward.

Capture filters become valuable when traffic volume is high, storage matters, or you already know exactly which traffic you need.

The important part is knowing which filter you are using.

A capture filter can remove evidence before you ever have a chance to look at it.

12. What Wireshark Cannot Show You

Wireshark is powerful enough that it is easy to expect too much from it.

Traffic that never reached the capture point

Your computer cannot analyze packets it never received.

On a switched network, starting Wireshark on one endpoint does not automatically give you every unicast conversation occurring between other devices. Promiscuous mode changes what the interface is willing to accept, but it does not force the network to deliver every packet to that interface.

Capturing another system's traffic may require a different capture point, switch port mirroring, a network tap, or another authorized design.

Encrypted application content without the keys

TLS exists to prevent intermediaries from casually reading application data.

Wireshark can identify and analyze many parts of an encrypted conversation, but decrypting TLS application traffic requires the appropriate secrets.

Do not treat encrypted payload as missing evidence. Sometimes "encrypted and successfully exchanged" is itself useful evidence.

Application intent

A server can accept a TCP connection and still return an application error.

A DNS response can be technically valid and still point to the wrong place.

A packet capture tells you what crossed the network. You still need configuration, logs, application behavior, and system context to explain why.

Traffic outside the capture window

If the problem happened before you clicked Start, the packet is not waiting around out of politeness.

Reproduce the issue when it is safe to do so, or obtain a capture made during the actual event.

13. Treat Capture Files Like Evidence

A packet capture can contain much more than the few fields you are currently displaying.

Depending on the traffic, a capture may expose:

• Internal and external IP addresses
• MAC addresses
• Hostnames and DNS queries
• Network structure
• Unencrypted application data
• Cookies, tokens, credentials, or other sensitive fields when protocols transmit them without adequate protection
• Timing and communication patterns

Do not upload a real workplace, client, school, or private-network capture to a public forum just because you want help with one packet.

Use a lab capture, an official sample capture, or a deliberately sanitized example when possible.

If you are handling a capture from an organization, follow its rules for collecting, storing, sharing, and disposing of that data.

A .pcap or .pcapng file is not "just a screenshot of the network." Treat it like collected evidence.

14. A Repeatable First-Capture Workflow

When Wireshark starts to feel like too much information, return to this sequence:

1. Write down the question. What are you trying to observe or troubleshoot?
2. Choose the capture point. Which interface can actually see that traffic?
3. Generate or reproduce one small event. DNS lookup, ping, web request, lab login, or another controlled action.
4. Stop the capture quickly. A smaller capture is easier to explain.
5. Apply a display filter. Start with the protocol you expect.
6. Find the request and response. Identify the endpoints and direction.
7. Expand the protocol layers. Check addresses, ports, flags, names, and response fields.
8. Follow the conversation when useful. Isolate the packets that belong together.
9. Compare expected behavior with observed behavior. Where do they stop matching?
10. Write down the evidence. Record what the packets actually proved.

Cert Happens can help with the supporting references while you work. Use Ports and Protocols when a port number needs context, the IPv4 subnet calculator when addressing needs verification, and the IPv6 addressing reference when an IPv6 packet introduces unfamiliar notation or Neighbor Discovery behavior.

Wireshark becomes much easier when you stop asking, "What do all these packets mean?"

Ask instead:

"Which packets answer the question I am working on?"

15. Official References

• Wireshark User's Guide
• Wireshark User's Guide: Start Capturing
• Wireshark User's Guide: Capture Interface Selection
• Wireshark User's Guide: Main Window
• Wireshark User's Guide: Packet List
• Wireshark User's Guide: Display Filters
• Wireshark Display Filter Reference
• Wireshark User's Guide: Following Protocol Streams
• Wireshark User's Guide: Protocol Hierarchy
• Wireshark User's Guide: Conversations
• Wireshark SampleCaptures