Wireshark turns captured network traffic into structured protocol fields. It can show the DNS query that preceded a connection, the flags and sequence numbers in each TCP segment, the status code in a plaintext HTTP response, and the time between related packets.

The hard part is rarely opening a capture file. Useful analysis depends on three decisions:

A packet capture is a record of what crossed one observation point. It does not directly record application method calls, server queue time, process scheduling, or packets that never reached that point. Wireshark can decode and correlate the captured bytes, but the interpretation still depends on where, when, and how those bytes were collected.

This chapter develops a practical workflow for capturing traffic, isolating a conversation, inspecting decoded fields, measuring time, and evaluating Wireshark's analysis hints.

Wireshark receives packet records from a capture mechanism such as libpcap or Npcap. Each record contains captured bytes and metadata such as an arrival timestamp, captured length, and interface information.

Protocol dissectors interpret those bytes. An Ethernet dissector identifies MAC addresses and the encapsulated protocol. An IP dissector identifies addresses and the transport protocol. A TCP dissector identifies ports, flags, and sequence numbers. An HTTP dissector can then interpret plaintext application bytes carried by TCP.

This pipeline creates an important distinction:

Generated fields are useful, but they are conclusions based on the packets available to the analyzer. Missing packets or an incomplete capture can change them.

The same application exchange can look different at different capture points.

Capture A can show the client's original connection, including local DNS queries and the client-facing IP address. Capture B can show a separate connection created by the load balancer, with different addresses, ports, sequence numbers, and timing.

Network Address Translation can rewrite addresses and ports between capture points. A proxy can terminate one TCP or TLS connection and open another. A tunnel can add an outer IP header. Host networking features can show packets before segmentation or after receive aggregation.

Before capturing, write down the question in observable terms:

Then choose a capture point that can observe the event. A client-side capture cannot prove that a packet reached the server. A server-side capture cannot show a client packet that was dropped earlier in the path. When one capture leaves multiple explanations, captures from two points can establish where the packet or delay appeared.

Switched Networks and Promiscuous Mode

A capture on a laptop normally sees traffic sent to or from that laptop, along with traffic such as broadcasts and some multicasts. An Ethernet switch does not send every unicast frame to every port.

Promiscuous mode asks the network interface to deliver all frames that reach it to the capture software. It does not make the switch copy unrelated traffic onto that port. Observing traffic between other machines usually requires a switch mirror port, a network tap, or a capture on one of the endpoints.

Wi-Fi monitor mode is a separate mechanism that can capture raw 802.11 traffic visible on a channel. Hardware, drivers, operating-system support, channel selection, and wireless encryption all affect what it can provide.

Wireshark's start screen lists available capture interfaces and shows activity beside active ones. Interface names vary by operating system and machine:

Choose the interface crossed by the target traffic. A request to 127.0.0.1 or ::1 uses loopback and will not appear on the physical Wi-Fi interface. A request sent through a VPN may appear on a tunnel interface, a physical interface as encrypted tunnel traffic, or both.

When the correct interface is unclear, generate a controlled request and compare the activity indicators. A narrow test is more reliable than selecting the interface with the largest traffic rate.

Some platforms offer an any pseudo-interface that captures from several interfaces. It is convenient for discovery, but it can lose interface-specific link-layer detail and combine traffic observed at different points in the host stack. Use a specific interface once the path is known.

If Wireshark lists no usable interfaces or cannot start a capture, fix the platform's packet-capture permissions. Running the complete Wireshark graphical process with administrator or root privileges exposes more code than necessary. Installations normally provide a smaller privileged capture component or a capture-driver permission mechanism.

Open Capture Options before starting a capture that matters. Confirm the interface, promiscuous-mode setting, capture filter, output file, and any file rotation limits.

For a short reproduction:

This produces a smaller file and makes the target exchange easier to correlate with logs.

Long-running investigations need explicit bounds. Wireshark can write packet data to files and rotate them according to size, duration, or file count. A ring of files prevents an unattended capture from filling a disk. File rotation changes storage behavior; it does not decide which packets are captured.

The snapshot length, often called snaplen, limits how many bytes are stored from each packet. A reduced snaplen saves space when only headers matter, but it can remove application data and later protocol fields. Capture complete packets unless the storage calculation requires a smaller value.

The capture buffer must also keep up with the packet rate. If it cannot, the capture mechanism drops packet records. Dropped capture records can look like network loss even when the network delivered every packet.

Wireshark's default analysis view connects three representations of the selected packet.

Packet List

Each row represents one packet record. Default columns commonly include:

The packet number does not change when a display filter hides earlier packets. If a filtered view starts at packet 427, packets 1 through 426 still exist in the capture.

The Info column is a summary, not the complete packet. A row labeled HTTP still contains lower-layer fields such as Ethernet, IP, and TCP. Expand those layers in Packet Details.

Packet Details

The details pane displays a protocol tree. A typical packet might contain:

Expand Frame first when arrival time, captured length, interface, or encapsulation matters. Expand the network and transport layers to confirm addresses, ports, flags, sequence numbers, and lengths. Application fields appear only when the relevant dissector can interpret the payload.

Selecting a field reveals its display-filter name in the interface and highlights its bytes. This is an efficient way to learn fields without remembering a large reference list. Right-clicking a field can prepare a filter, apply it as a filter, or add it as a custom column.

Packet Bytes

The bytes pane connects decoded meaning to the recorded bytes. Selecting the TCP destination port highlights its two bytes. Selecting an HTTP header highlights the characters belonging to that field.

Some detail items have no direct byte range because Wireshark generated them. A TCP stream index and an analysis warning, for example, are derived from multiple records or analyzer state.

Status Bar

The status bar reports counts such as captured packets, displayed packets, marked packets, and capture drops when that information is available. Check it before concluding that an unexpected sequence gap occurred on the network.

Wireshark has two filter languages. They operate at different stages and use different syntax.

The expression tcp port 443 is a capture filter. The expression tcp.port == 443 is a display filter. Copying an expression from one filter box into the other generally fails or changes its meaning.

Capture Filter Examples

Capture filters work with packet information available during collection:

The last filter can remove an administrative SSH connection from a remote capture, but it also removes any evidence carried on port 22. Apply capture filters only when the excluded traffic cannot be needed later.

Capture filters cannot usually inspect application fields such as an HTTP status code or DNS response code. Those fields become available after protocol dissection, which is the display-filter stage.

Display Filter Fundamentals

A protocol or field name by itself checks whether it exists:

Comparisons select packets with a field that has a particular value:

ip.addr matches an address in either direction. Direction-specific fields make intent explicit:

Boolean operators combine conditions:

The membership operator keeps several alternatives readable:

String fields support operators such as contains:

Display filters are type-aware. An IP address, integer, Boolean, time value, byte sequence, and string do not accept every operator in the same way. The filter input reports syntax validity while the expression is being edited.

A Practical Filter Library

Connection setup:

Initial SYN packets without ACK:

Connection resets:

TCP packets carrying payload:

Suspected TCP recovery events:

Receiver flow-control warnings:

Matched acknowledgments whose measured delay exceeds 100 milliseconds:

Packets in a relative time range:

DNS errors:

HTTP error responses visible in plaintext:

These expressions locate candidates. A retransmission label does not prove network loss, and a long ACK delay does not prove high end-to-end application latency.

A busy host can have hundreds of connections using the same service port. Filtering on tcp.port == 443 still combines unrelated traffic.

Wireshark assigns each decoded TCP connection a generated stream index. Once a relevant packet is selected, expand TCP and find its stream index, or right-click the packet and apply a conversation filter. The resulting expression resembles:

The number is local to that capture file. Stream 7 in another file has no relationship to it.

A TCP stream should correspond to one connection identified by its two endpoint addresses and ports. The stream index is usually easier to use because it remains valid in both directions and avoids a long address-and-port expression.

UDP has no connection handshake, but Wireshark can still group related traffic and assign stream indexes for supported analysis. The grouping depends on addresses, ports, and protocol behavior rather than a transport connection state.

Follow Stream

Select a packet, then use Analyze → Follow → TCP Stream or the packet's context menu. Wireshark applies a stream filter and opens a reconstructed bidirectional byte view.

Follow Stream is useful for:

The reconstructed view does not preserve TCP packet boundaries as application message boundaries. One HTTP request can span several segments, and one segment can contain bytes from more than one application message. The application protocol defines framing.

Following the underlying TCP stream for a TLS connection without decryption material shows encrypted TLS records. IP addresses, ports, TCP behavior, TLS record boundaries, and some handshake metadata remain visible, but protected HTTP headers and bodies do not.

Reassembly Changes Where Fields Appear

Wireshark can reassemble IP fragments and TCP byte streams so an application dissector can parse a complete protocol data unit. A field may therefore appear on the packet where reassembly completes rather than on the first packet carrying bytes from that message.

The Packet Bytes pane can expose a reassembled-data view. Inspect the contributing frame references when the application field's apparent packet position seems inconsistent with the original segment boundaries.

Reassembly requires the relevant pieces. A capture that starts late, drops packets, or stores truncated payloads may prevent higher-level dissection even when the endpoint processed the complete message.

Packet captures contain timestamps assigned by the capture system. Wireshark can display them as:

Relative time is convenient for request analysis because the first target event can become time zero. Set a time reference on a packet such as the initial SYN or DNS query, then compare later events against it.

Three time fields answer different questions:

This measures time since the previous captured frame. Unrelated background traffic can make the value small even when the current conversation was idle.

This measures time since the previous frame in the current displayed set. Its meaning changes when the display filter changes.

This measures time since the previous frame in the same TCP stream.

Wireshark can also generate:

This is the time between a segment and an acknowledgment that Wireshark associates with it. It is measured at the capture point and depends on seeing the required packets.

An observed gap between a request and response combines everything that happened between those packet observations:

One capture usually cannot divide that total precisely. Server logs, distributed traces, and captures at additional points can separate network time from processing time.

Custom Time Columns

Right-click a field in Packet Details and choose Apply as Column to add it to the packet list. Useful analysis columns include:

A cell remains empty when its packet does not contain that field. For example, tcp.analysis.ack_rtt appears only where Wireshark has a matched measurement.

Statistics views summarize the packets already loaded. They help locate important traffic before individual packets are inspected.

Protocol Hierarchy

Statistics → Protocol Hierarchy groups traffic by decoded protocol and reports packet and byte proportions. It quickly answers questions such as:

An absent protocol can mean no matching traffic was captured, the payload was encrypted, packets were truncated, required segments were missing, or the dissector did not recognize the protocol.

Endpoints

Statistics → Endpoints lists observed addresses at supported layers. Sort by packets or bytes to find major participants. Use the IPv4 or IPv6 tab when the investigation concerns hosts rather than Ethernet interfaces.

Endpoint totals are directional aggregates for one address. They do not separate individual connections to the same host.

Conversations

Statistics → Conversations groups traffic between pairs of endpoints. The TCP tab can show connection-level packet counts, byte counts, start times, and durations. Sorting by bytes can locate bulk transfers, while sorting by duration can locate long-lived or stalled connections.

The Limit to display filter option makes these statistics operate on the current filtered view. Confirm whether it is enabled before interpreting totals.

I/O Graphs

Statistics → I/O Graphs plots packet or byte rates over time. Separate graph lines can use different display filters, which makes it possible to compare all traffic with retransmissions or one service with the complete host.

For example:

An I/O graph reveals bursts, quiet periods, and correlations. It does not determine the cause of a burst or prove that every packet reached the peer.

Wireshark dissectors attach Expert Information to notable events. Open Analyze → Expert Information to group them by severity, protocol, or summary.

Examples include:

Expert Information is an index into the capture, not a root-cause report. A red or yellow entry means the dissector marked something notable according to its rules. The event may be expected in that environment, caused by an incomplete capture, or unrelated to the reported symptom.

TCP analysis is especially dependent on capture completeness and order. Wireshark infers recovery events by tracking sequence numbers and acknowledgments. These filters are useful:

For every flagged event, inspect:

tcp.analysis.lost_segment means Wireshark expected an earlier sequence range that is absent from its view. The packet may have been lost on the network, omitted by the capture, recorded on another interface, or sent before collection began.

Coloring Rules

Packet-list colors are produced by ordered display-filter rules. They help scan for traffic classes and analysis events, but a color has no universal meaning outside the active profile. Inspect the rule or decoded fields before drawing a conclusion.

Custom coloring is useful for a stable working set such as:

Keep the set small enough that the important events remain visually distinct.

Dissectors use port conventions, explicit negotiation, and protocol heuristics. A service running HTTP on an unusual port may appear only as TCP data. A heuristic can also interpret bytes as the wrong protocol.

Use Analyze → Decode As when the protocol is known from independent context. This tells Wireshark which dissector should interpret the selected traffic. It changes the analysis view, not the bytes stored in the capture.

Decode As should not be used to force a desired conclusion. If the bytes do not follow the selected protocol, the dissector may report malformed data or produce misleading fields.

Dissection can also fail because:

Check these conditions before assuming the endpoint sent invalid traffic.

A Wireshark configuration profile stores a related analysis setup, including columns, coloring rules, filter buttons, and many protocol preferences.

Separate profiles prevent one investigation's preferences from affecting another. A practical HTTP and TCP profile might contain:

Protocol preferences affect dissection. Record any non-default settings when sharing a capture analysis, especially Decode As rules, reassembly settings, and checksum-validation settings.

A loopback capture provides a controlled way to practice the complete workflow without unrelated network traffic or TLS encryption.

1. Start a Local Server

Run this command in one terminal:

The command starts a basic HTTP server on loopback port 8000.

2. Configure Wireshark

Select the loopback interface:

Enter this capture filter:

Start the capture.

3. Generate One Request

Run this command in a second terminal:

The requested path will normally produce an HTTP error response because the file does not exist. Stop the capture after curl exits.

Windows PowerShell users can replace /dev/null with NUL when using the native curl executable.

4. Isolate the Connection

Apply this display filter:

Select one packet, expand TCP, find the stream index, and apply:

Replace <stream-number> with the value in the selected packet.

5. Read the Exchange

Locate the initial SYN:

Then inspect the SYN-ACK and final ACK. Confirm that the address and port directions reverse between client and server.

Find application packets:

Expand the HTTP request and inspect its method, request URI, and Host field. Expand the response and inspect its status code and content length. Select each field and observe the highlighted bytes.

If Wireshark does not decode port 8000 as HTTP, select a packet and use Decode As to associate that TCP traffic with HTTP.

6. Follow and Measure

Use Follow TCP Stream to view the request and response as reassembled byte streams. Return to the packet list, set the initial SYN as the time reference, and compare these intervals:

Add tcp.stream, tcp.time_delta, and tcp.len as columns. The capture now supports both packet-level and stream-level reading.

Exact packet counts can vary with the operating system, server implementation, ACK behavior, and host offloads. Validate the protocol sequence and byte ranges instead of expecting one fixed row count.

7. Save the Capture

Save the file as pcapng. The pcapng format can preserve metadata such as interface information and packet comments. Use pcap when a downstream tool requires its broader legacy compatibility.

Record the interface, operating system, capture filter, reproduction command, and approximate time with the file. This context can be as important as the packet bytes.

Stop the local HTTP server with Ctrl+C after saving the capture.

When opening an unfamiliar capture, work from broad structure toward individual fields:

The workflow keeps the analysis tied to observable evidence. Starting with a filter such as tcp.analysis.retransmission can find an event, but it can also anchor the investigation on an analyzer label before the affected connection is identified.

Capture Loss

If the capture process drops packets, sequence gaps and missing responses may exist only in the file. Check capture statistics and the status bar. A second capture point can show whether the supposedly missing packet crossed the network.

Truncated Packets

When snapshot length is smaller than the original packet, Wireshark stores only a prefix. The Frame section distinguishes captured length from original length. Truncation can remove payload, checksums, and higher-level fields.

The display filter:

finds records whose captured length is shorter than their reported on-wire length.

Checksum Offload

An outgoing host capture can occur before the network interface calculates the final TCP or UDP checksum. Wireshark may mark the stored checksum invalid even though the transmitted packet was correct.

If checksum warnings appear mainly on outbound packets from the capture host, inspect offload context before treating them as wire corruption. A capture from another machine or a network tap observes the packet after transmit offload.

Segmentation and Receive Offload

Transmit offload can make a host capture show a large TCP payload that hardware later divides into wire-sized segments. Receive aggregation can combine several wire segments before the capture point in the receive path.

These artifacts affect displayed segment sizes, packet counts, and timing. They do not change the TCP byte stream delivered to the application.

Name Resolution

Wireshark can replace numeric MAC addresses, IP addresses, and ports with resolved names. Resolved labels improve readability, but the labels are not necessarily present in the packet. Resolution can also depend on local configuration and external lookups.

Disable name resolution when exact addresses and ports are part of the evidence. Save both the numeric value and any useful resolved name in the analysis notes.

Encryption

Encryption limits application-layer visibility. A capture of HTTPS can still expose endpoint addresses, transport behavior, TLS records, and parts of the handshake. It does not expose protected HTTP methods, paths, headers, or bodies without appropriate decryption material.

Do not classify encrypted application data as malformed TCP data because it is unreadable as text.

Asymmetric Visibility

A capture may contain only one direction because of routing asymmetry, switch mirroring configuration, tunnel placement, or capture filtering. TCP analysis becomes less reliable without acknowledgments from the other direction.

Confirm that packets from both endpoint address-and-port directions exist before using missing ACKs as evidence of a peer failure.

Timestamp Limitations

Packet order and time accuracy depend on capture clocks, driver behavior, buffering, and file merging. Two hosts can have different clock offsets even when both use time synchronization.

Compare durations within one capture when possible. When correlating separate captures, measure and correct clock offset before comparing absolute timestamps.

Packet captures can contain authentication cookies, API tokens, unencrypted passwords, personal data, internal addresses, DNS names, and proprietary payloads. Even encrypted captures reveal metadata about communicating endpoints, timing, and traffic volume.

Capture the smallest useful scope, restrict file access, and define a retention period. Before sharing a file, inspect its payload and metadata. Renaming hosts in a report does not remove the original bytes from the pcapng file.

Packet comments and capture metadata can also contain sensitive host or analyst information. Share a sanitized derivative only when the transformation preserves the evidence needed for review.

A display filter does not delete packets. It changes the visible set while the complete captured set remains loaded.

A capture filter and display filter are different languages. tcp port 443 and tcp.port == 443 belong to different stages.

Promiscuous mode does not copy all switched traffic to one port. The interface can process only frames that reach it.

The Protocol column does not show every layer. It usually shows the highest protocol Wireshark decoded for that row.

Packet number is not a transmitted header field. It is the record's stable position in the capture file.

Follow TCP Stream does not reveal TCP message boundaries. TCP carries an ordered byte stream, and application framing determines message boundaries.

A Wireshark analysis label is not direct wire data. Retransmission, lost-segment, and ACK RTT fields are analyzer results.

A missing packet in one capture does not prove network loss. Capture drops, filtering, truncation, interface selection, and observation point all affect visibility.

A bad checksum in a host capture does not always mean a bad packet on the wire. Checksum offload can move calculation after the capture point.

A long request-to-response gap does not identify where the time was spent. The interval can include network travel, queueing, proxy work, and application processing.

Encrypted payload is not absent payload. Wireshark can record the bytes without being able to decode the protected application content.

Resolved names are not always transmitted values. Wireshark can obtain them from local or external name-resolution sources.

Wireshark records packets at one observation point and decodes them into searchable fields. Interface choice determines which traffic and transformations are visible: loopback, VPN, container, and physical interfaces show different views. Promiscuous mode processes frames delivered to the interface but does not bypass switching.

Capture filters limit stored packets; display filters select from what was recorded. The packet list summarizes traffic, the details pane decodes fields, and the bytes pane verifies those fields against raw data. Conversation filters and stream indexes isolate bidirectional traffic, while Follow Stream reconstructs application bytes without treating TCP segments as message boundaries.

Timestamps, custom columns, Protocol Hierarchy, Endpoints, Conversations, and I/O Graphs expose timing and large-scale patterns. Expert Information and TCP analysis fields are hints, not facts independent of the capture.

Loss, truncation, offloads, name resolution, encryption, and asymmetric visibility can distort results. Record the capture context, test alternatives, and correlate packets with logs, traces, metrics, or another observation point.

Capture at a useful point, isolate one conversation, verify decoded fields against bytes, measure time, and respect the capture's limits.