Wireshark – GUI Packet Analyzer: Filters, TCP Analysis & Troubleshooting

1. What Is Wireshark?

Wireshark is a free, open-source graphical network protocol analyser. It captures packets directly from a network interface (or reads saved .pcap/.pcapng files) and presents them in a structured, colour-coded, layer-by-layer display. It is the industry standard tool for deep packet inspection across every major platform.

Use Case	What Wireshark Reveals
Connectivity troubleshooting	Is the TCP handshake completing? Are DNS responses arriving? Is ARP resolving the gateway MAC correctly?
Performance diagnosis	TCP retransmissions, duplicate ACKs, window size reductions, high round-trip times — all visible in packet timestamps and TCP analysis flags
Protocol learning	See DHCP DORA, OSPF Hellos, BGP keepalives, TLS handshakes in full detail — each field decoded and labelled
Security auditing	Cleartext credentials in HTTP/FTP/Telnet, port scans (many SYN packets), ARP spoofing (duplicate ARP replies), data exfiltration patterns
Incident response	Reconstruct attack sessions, extract transferred files, identify C2 traffic patterns, timeline events precisely from packet timestamps

2. Installation and Launch

Platform	Installation Method	Notes
Windows	Download installer from wireshark.org. Installer includes WinPcap/Npcap (required for live capture).	Run as Administrator for live capture on Windows. Npcap replaces legacy WinPcap on modern versions.
Linux (Debian/Ubuntu)	`sudo apt install wireshark`	During install: allow non-root users to capture. Add user to `wireshark` group: `sudo usermod -aG wireshark $USER`
Linux (RHEL/CentOS)	`sudo yum install wireshark-gnome`	The GUI package; `wireshark` alone installs only the CLI tshark
macOS	Download .dmg from wireshark.org, or: `brew install --cask wireshark`	May need to grant permission for ChmodBPF utility to access raw sockets without root

3. The Wireshark Interface — Three-Pane Layout

  ┌─────────────────────────────────────────────────────────────────────┐
  │  Toolbar: Start/Stop capture, Filter bar, navigation buttons        │
  │  Display Filter Bar: [  ip.addr == 192.168.1.1 and tcp          ▼ ] │
  ├─────────────────────────────────────────────────────────────────────┤
  │  PACKET LIST PANE  (one row per captured packet)                    │
  │  No.  Time    Source          Destination     Protocol  Length Info  │
  │  1    0.000   192.168.1.100   8.8.8.8         DNS       74     Std  │
  │  2    0.012   8.8.8.8         192.168.1.100   DNS       90     Std  │
  │  3    0.050   192.168.1.100   93.184.216.34   TCP       66     SYN  │
  │  4    0.112   93.184.216.34   192.168.1.100   TCP       66 SYN-ACK  │
  ├─────────────────────────────────────────────────────────────────────┤
  │  PACKET DETAILS PANE  (layer-by-layer tree for selected packet)     │
  │  ▶ Frame 3: 66 bytes on wire                                        │
  │  ▶ Ethernet II, Src: aa:bb:cc:00:00:01, Dst: aa:bb:cc:00:00:02     │
  │  ▶ Internet Protocol Version 4, Src: 192.168.1.100, Dst: 93.184... │
  │  ▼ Transmission Control Protocol, Src Port: 54321, Dst Port: 80    │
  │      Source Port: 54321                                             │
  │      Destination Port: 80                                           │
  │      Sequence Number: 0 (relative)                                  │
  │      Flags: 0x002 (SYN)                                             │
  │        .... ..1. = Syn: Set                                         │
  ├─────────────────────────────────────────────────────────────────────┤
  │  PACKET BYTES PANE  (raw hex + ASCII)                               │
  │  0000  aa bb cc 00 00 02 aa bb  cc 00 00 01 08 00 45 00   ........E.│
  │  0010  00 34 1f 4b 40 00 40 06  xx xx c0 a8 01 64 5d b8   .4.K@.@...│
  └─────────────────────────────────────────────────────────────────────┘

Pane	What It Shows	Key Interactions
Packet List	Chronological list of all captured packets. Columns: No., Time, Source, Destination, Protocol, Length, Info. Colour-coded by protocol/event.	Click row to select; right-click for Follow Stream, Apply as Filter, Mark Packet, etc.
Packet Details	Expandable tree of the selected packet — one node per protocol layer (Frame, Ethernet, IP, TCP/UDP, App layer). Every header field is labelled and decoded.	Click a field to highlight its bytes in the Bytes pane. Right-click a field to "Apply as Filter" or "Copy field value."
Packet Bytes	Raw hexadecimal and ASCII representation of every byte in the selected packet. Highlighted region corresponds to the field selected in Details pane.	Read cleartext payloads in the ASCII column. Identify specific protocol fields by their offset.

4. Capture Filters vs Display Filters — Critical Distinction

Feature	Capture Filter	Display Filter
When applied	Before capture starts — set in Capture Options	After capture — applied to already-captured packets
Effect	Packets NOT matching are never saved — permanently excluded from the capture file	Packets not matching are hidden but still in the file — remove the filter to see them again
Syntax	BPF (Berkeley Packet Filter) — same as tcpdump	Wireshark display filter language — different syntax, much richer protocol field access
Examples	`host 10.0.0.1` `tcp port 80` `not arp` `net 192.168.0.0/24`	`ip.addr == 10.0.0.1` `tcp.port == 80` `!arp` `ip.src == 192.168.0.0/24`
Performance impact	High benefit — reduces kernel-level traffic volume and disk I/O. Critical on high-throughput links.	No impact on capture — only affects display rendering
Best practice	Use when you know exactly what you need — to limit file size and CPU load	Use for post-capture investigation — broad capture, narrow analysis

Recommended workflow: Capture broadly (minimal or no capture filter) so you don't miss context. Then use display filters to focus on what you need. Only use capture filters when performance is critical or disk space is constrained.

5. Display Filter Syntax — Complete Reference

Wireshark's display filter language uses dot-notation field names, comparison operators, and logical combinators. The filter bar turns green for valid syntax, red for invalid, and yellow for a partial match that might not do what you intend.

Comparison Operators

== (eq)   equals:          ip.addr == 192.168.1.1
!= (ne)   not equal:       tcp.port != 22
>  (gt)   greater than:    frame.len > 1400
<  (lt)   less than:       frame.len < 64
>= (ge)   greater/equal:   tcp.window_size >= 8192
<= (le)   less/equal:      ip.ttl <= 10
contains  substring match: http.host contains "google"
matches   regex match:     http.request.uri matches "\.php$"

Logical Operators

and (&&)  both true:  ip.addr == 10.0.0.1 and tcp.port == 80
or  (||)  either:     dns or dhcp
not (!)   negate:     !arp
()        grouping:   (ip.src == 10.0.0.1 or ip.src == 10.0.0.2) and tcp

Essential Display Filters

Filter	Purpose	Notes
`ip.addr == 192.168.1.10`	All traffic to or from a specific IP	Matches src OR dst — use ip.src / ip.dst for direction
`ip.src == 192.168.1.10`	Traffic sourced from specific IP only	Combine: `ip.src == A and ip.dst == B`
`ip.addr == 192.168.0.0/24`	All traffic involving the subnet	CIDR notation works in display filters
`tcp.port == 80`	All HTTP traffic (src or dst port 80)	Use tcp.dstport == 80 for inbound requests only
`tcp.flags.syn == 1`	All TCP SYN packets (new connection attempts)	Add `and tcp.flags.ack == 0` for pure SYN only
`tcp.flags.syn == 1 and tcp.flags.ack == 0`	Only first SYN (not SYN-ACK)	Watch for SYN flood — many sources, no ACK responses
`tcp.flags.reset == 1`	All TCP RST packets	Indicates port closed, connection refused, or firewall drop
`tcp.analysis.retransmission`	TCP retransmissions (data re-sent after no ACK)	Indicates packet loss or congestion on the path
`tcp.analysis.duplicate_ack`	Duplicate ACKs (receiving side requesting re-send)	Three consecutive duplicate ACKs trigger fast retransmit
`tcp.analysis.zero_window`	TCP zero window (receiver buffer full)	Sender must pause; indicates receiver-side congestion
`http`	All HTTP protocol packets	Does NOT match HTTPS (TLS); use `tcp.port == 443` for HTTPS
`http.request.method == "GET"`	HTTP GET requests only	Also: "POST", "PUT", "DELETE"
`http.response.code == 404`	HTTP 404 Not Found responses	Also: 200, 301, 302, 500, 503...
`dns`	All DNS traffic (queries and responses)	Includes both UDP/53 and TCP/53 (large responses)
`dns.flags.response == 0`	DNS queries only (not responses)	Helps spot what names are being resolved
`dns.flags.rcode != 0`	DNS error responses (NXDOMAIN, SERVFAIL, etc.)	rcode 3 = NXDOMAIN; rcode 2 = SERVFAIL
`dhcp` or `bootp`	DHCP traffic (Discover, Offer, Request, ACK)	Wireshark may show as "BOOTP" for DHCP
`icmp`	All ICMP packets (ping, unreachable, redirect)	Use `icmp.type == 8` for echo request only
`arp`	All ARP packets	Use `arp.opcode == 1` for requests, `== 2` for replies
`eth.addr == aa:bb:cc:dd:ee:ff`	Traffic for a specific MAC address	Use eth.src or eth.dst for direction
`frame.len > 1400`	Large frames (near-MTU traffic)	Find bulk transfers, identify MTU issues
`frame contains "password"`	Any frame with the literal text "password"	Security audit — detect cleartext credentials
`tls`	All TLS (HTTPS, encrypted) traffic	Content is encrypted; can analyse handshake fields
`ospf`	All OSPF packets (Hello, LSA, DBD)	Useful for verifying OSPF neighbour formation

6. Analysing Packets — The Packet Details Pane

When you click a packet in the Packet List, the Details pane shows a collapsible tree with one node per protocol layer. Each layer maps to an OSI layer — expanding it reveals every field name, value, and bit offset.

  Example: HTTP GET request decoded in Packet Details Pane

  ▶ Frame 42: 487 bytes on wire (3896 bits), 487 bytes captured
      Arrival Time: 2025-03-10 14:23:45.123456789 UTC
      Frame Number: 42
      Frame Length: 487 bytes

  ▶ Ethernet II
      Destination: aa:bb:cc:dd:ee:01 (Router MAC)
      Source: aa:bb:cc:00:11:22 (Host MAC)
      Type: IPv4 (0x0800)

  ▶ Internet Protocol Version 4
      Source Address: 192.168.1.100
      Destination Address: 93.184.216.34
      Protocol: TCP (6)
      Time to Live: 64
      Header Checksum: 0xabcd [correct]

  ▶ Transmission Control Protocol
      Source Port: 54789
      Destination Port: 80
      Sequence Number: 1 (relative)
      Acknowledgment Number: 1 (relative)
      Flags: 0x018 (PSH, ACK)
      Window: 65535
      Checksum: 0x1234 [correct]

  ▼ Hypertext Transfer Protocol
      GET / HTTP/1.1\r\n                     <-- Request line
      Host: example.com\r\n                  <-- Virtual host header
      User-Agent: Mozilla/5.0...\r\n         <-- Browser identification
      Accept: text/html,...\r\n
      Connection: keep-alive\r\n
      \r\n                                   <-- End of headers

Clicking any field in the Details pane highlights the corresponding bytes in the Bytes pane. Right-clicking a field allows you to Apply as Filter (adds that field value directly to the display filter bar) or Copy field value for documentation.

7. Follow Stream — Reconstructing Full Sessions

Follow Stream reassembles all packets of a single TCP, UDP, or TLS session into a single human-readable conversation view. It is one of Wireshark's most powerful features for application-layer analysis.

  How to use Follow TCP Stream:
  1. Find any packet from the session you want to reconstruct.
  2. Right-click the packet in the Packet List.
  3. Select: Follow > TCP Stream (or UDP Stream, TLS Stream, HTTP Stream)
  4. A new window opens showing the complete conversation.

  In the Follow TCP Stream window:
  - Red text:  data sent FROM the client (src of the first SYN packet)
  - Blue text: data sent FROM the server

  Example HTTP session reconstructed:
  [Red]  GET /login.php HTTP/1.1
         Host: example.com
         Cookie: session=abc123

  [Blue] HTTP/1.1 200 OK
         Content-Type: text/html
         Set-Cookie: session=xyz789; Path=/

         <html><body>Welcome back, admin</body></html>

  What this reveals:
  - Cleartext username/password in POST body (HTTP security risk)
  - Session cookie values (cookie theft vulnerability)
  - Server software version in response headers
  - Full application request/response cycle

Stream Type	Menu Path	Best For
Follow TCP Stream	Right-click → Follow → TCP Stream	HTTP sessions, FTP transfers, Telnet sessions, any TCP application
Follow UDP Stream	Right-click → Follow → UDP Stream	DNS conversations, TFTP, SNMP
Follow TLS Stream	Right-click → Follow → TLS Stream	HTTPS when TLS keys are loaded (see Section 11)
Follow HTTP Stream	Right-click → Follow → HTTP Stream	HTTP/1.x sessions; auto-decodes chunked encoding

After using Follow Stream, Wireshark automatically applies a display filter to show only that stream's packets. Click the X on the filter bar to clear it and return to the full capture view.

8. Colour Rules — Reading the Colour Coding

Wireshark colour-codes rows in the Packet List to help spot important events at a glance. Default colour rules cover the most common protocols and TCP analysis events.

Colour	Default Meaning	Action
Light blue / lavender	TCP traffic (general)	Normal data flow — no action needed unless other indicators
Light green	HTTP traffic	Web requests/responses — inspect for errors or cleartext data
Pale green	TCP SYN/FIN/RST connection events	Track connection setup/teardown
Light red / pink	TCP errors: retransmissions, out-of-order, duplicate ACK	Investigate immediately — indicates packet loss or congestion
Darker red	TCP RST packets or serious TCP errors	Connection reset — find the cause (firewall, port closed)
Yellow	ARP, ICMP, or other non-TCP/UDP protocols	Check ARP for duplicates; check ICMP for unreachables
Grey	TCP keepalives or ACK-only packets	Normal — connection maintenance
Black	Malformed packets or protocol errors	Investigate — packet may be corrupted or crafted

Customise colour rules: View → Coloring Rules. You can add your own rules — for example, highlight all traffic to a suspicious IP in bright orange.

9. Statistics and Analysis Tools

Protocol Hierarchy (Statistics → Protocol Hierarchy)

Shows the percentage breakdown of every protocol in the capture by packet count and bytes. Useful for understanding the traffic mix and spotting unexpected protocols.

  Protocol         Percent Packets  Bytes    End Packets  End Bytes
  Ethernet         100.0%   4521   5234456  0            0
    IPv4           97.3%    4399   5198000  0            0
      TCP          78.2%    3537   4812000  1205         892000
        HTTP       52.1%    2356   3200000  2356         3200000
        TLS        26.1%    1181   1612000  1181         1612000
      UDP          19.1%     862   386000   0            0
        DNS        14.2%     642   96000    642          96000
        DHCP        4.9%     220   290000   220          290000
    ARP             2.7%     122   7324     122          7324

Conversations (Statistics → Conversations)

Lists all unique conversations by layer (Ethernet, IP, TCP, UDP) with byte/packet counts. Sort by bytes to find the largest flows — useful for identifying bandwidth consumers or data exfiltration.

I/O Graphs (Statistics → I/O Graph)

Plots traffic volume over time. Multiple lines can be overlaid with different display filters — for example, plot all traffic vs retransmissions to visualise when packet loss occurred during a session.

Expert Information (Analyse → Expert Information)

Wireshark automatically categorises notable events across the capture into severity levels. This is the fastest way to find problems in a large capture.

Severity	Colour	Examples
Error	Red	Malformed packets, checksum errors, protocol violations
Warning	Yellow	TCP retransmissions, duplicate ACKs, out-of-order segments, zero window
Note	Blue	TCP window updates, connection resets, ICMP errors
Chat	Grey	Normal connection events (SYN, FIN, HTTP responses)

TCP Stream Graph (Statistics → TCP Stream Graph)

Visualises TCP sequence numbers over time, RTT graphs, window scaling, and throughput. Useful for diagnosing slow TCP performance (receiver window limits, high RTT, retransmissions).

10. Real Troubleshooting Scenarios

Scenario 1: Slow Website — Identify TCP Retransmissions

  Problem: Users report website loads slowly.

  Step 1: Capture with display filter: http
  Step 2: Check for red rows (retransmissions) or Expert Information warnings
  Step 3: Apply filter: tcp.analysis.retransmission
          -- If many red rows appear, data is being re-sent due to loss
  Step 4: Apply filter: tcp.analysis.zero_window
          -- If zero window events appear, server buffer is full
  Step 5: Statistics > TCP Stream Graph > Round Trip Time
          -- Plot RTT over time; spikes indicate latency bursts

  Finding: Many tcp.analysis.retransmission events between client and server
  Diagnosis: Packet loss on the path between client and web server
  Action: Check network path with traceroute; inspect switch error counters

Scenario 2: DNS Resolution Failure

  Problem: Host reports "name not found" for external websites.

  Step 1: Apply filter: dns
  Step 2: Look for:
    a. DNS queries (blue) with no corresponding response (missing pair)
    b. Responses with rcode != 0:
       Filter: dns.flags.rcode != 0
       rcode 3 = NXDOMAIN (name doesn't exist)
       rcode 2 = SERVFAIL (server failure — DNS server can't resolve)
  Step 3: Check destination IP in DNS queries:
    Filter: dns.flags.response == 0
    Look at Dst IP column -- is it reaching the correct DNS server?

  Finding: DNS queries are sent but no responses received
  Diagnosis: DNS server unreachable / firewall blocking UDP port 53
  Action: Ping DNS server; check firewall rules for port 53

Scenario 3: DHCP Not Assigning IP Address

  Problem: Host stuck at 169.254.x.x (APIPA) -- DHCP failed.

  Step 1: Apply filter: dhcp or bootp
  Step 2: Look for DHCP DORA sequence:
    a. DHCP Discover  (client broadcasts, src 0.0.0.0, dst 255.255.255.255)
    b. DHCP Offer     (server unicast/broadcast to client with offered IP)
    c. DHCP Request   (client accepts offer, broadcasts confirmation)
    d. DHCP ACK       (server confirms assignment)

  Finding: DHCP Discover present but no Offer received
  Diagnosis: No DHCP server reachable / DHCP snooping blocking response /
             DHCP relay not configured for this VLAN
  Action: Verify DHCP server is up; check DHCP snooping trust on uplinks;
          add ip helper-address on VLAN SVI

Scenario 4: Detect ARP Spoofing

  Problem: Suspected man-in-the-middle attack on a network segment.

  Step 1: Apply filter: arp
  Step 2: Look for duplicate ARP replies:
    - Two different source MAC addresses claiming the same IP address
    - Filter: arp.opcode == 2 (ARP replies only)
  Step 3: Check Packet Details for:
    arp.src.proto_ipv4 -- the IP being claimed
    arp.src.hw_mac     -- the MAC making the claim

  Red flag output:
  Packet 100: 10.0.0.1 is at aa:bb:cc:11:22:33 (legitimate router)
  Packet 101: 10.0.0.1 is at aa:bb:cc:ff:ee:dd (attacker's MAC!)

  Finding: Two MACs claiming the gateway IP -- ARP poisoning detected
  Action: Isolate attacker port; enable Dynamic ARP Inspection (DAI) on switch

Scenario 5: Detect Unauthorised Connections

  Problem: Security team suspects data exfiltration.

  Step 1: Statistics > Conversations > TCP tab > Sort by Bytes column
          -- Identify top talkers by data volume
  Step 2: Apply filter to suspicious IP: ip.addr == x.x.x.x
  Step 3: Follow TCP Stream to inspect the conversation content
  Step 4: Check for:
    - Cleartext data in unusual directions (outbound large transfers)
    - Connections to unfamiliar external IPs on unusual ports
    - DNS queries for unusual domain names: filter dns.qry.name contains ".ru"
    - Beaconing: regular small outbound connections at fixed intervals (C2 traffic)

11. TLS Decryption — Analysing HTTPS Traffic

HTTPS traffic is encrypted with TLS. Wireshark can decrypt it if you provide the session keys. Two methods are supported.

Method 1: SSLKEYLOGFILE (recommended for browsers)

  # On Linux/macOS (set environment variable before starting browser):
  export SSLKEYLOGFILE=/tmp/ssl-keys.log
  firefox &
  # or: google-chrome &

  # On Windows (PowerShell):
  $env:SSLKEYLOGFILE = "C:\ssl-keys.log"
  Start-Process firefox

  # In Wireshark:
  Edit > Preferences > Protocols > TLS
  Set "(Pre)-Master-Secret log filename" to the SSLKEYLOGFILE path
  Wireshark auto-decrypts TLS sessions in real time.

Method 2: Server Private Key (TLS 1.2 without PFS only)

  # Only works if the server uses RSA key exchange (not ECDHE/DHE)
  # Does NOT work with TLS 1.3 or any Perfect Forward Secrecy ciphers

  Edit > Preferences > Protocols > TLS > (Legacy) RSA Keys List
  Add: IP address, Port, Protocol, Key File path

12. Saving, Exporting, and File Management

  File > Save As (.pcapng)         Save all packets in current capture
  File > Export Specified Packets  Save only filtered/selected packets
  File > Export Objects            Extract files transferred over HTTP, FTP, etc.
                                   (recovers images, documents from HTTP sessions)
  File > Export Packet Dissections Export display to CSV, JSON, XML, plain text

  File formats:
  .pcapng  -- modern format; supports multiple interfaces, comments, metadata
  .pcap    -- legacy libpcap format; compatible with all tools including tcpdump
  Both can be opened by Wireshark, tshark, and most analysis tools.

Capturing from a Remote System via SSH + tcpdump

  # Live remote capture piped directly into Wireshark:
  ssh user@server 'sudo tcpdump -U -i eth0 -s 0 -w - "not port 22"' | wireshark -k -i -
  # -U = per-packet buffer flush (critical for live streaming)
  # -w - = write raw PCAP to stdout
  # wireshark -k -i - = start Wireshark reading from stdin immediately
  # "not port 22" = exclude SSH management traffic from capture

13. Security and Legal Considerations

Authorisation is mandatory. Capturing network traffic on any network you do not own or have explicit written permission to analyse is illegal in most jurisdictions — including the Computer Fraud and Abuse Act (US), Computer Misuse Act (UK), and equivalents worldwide. Always obtain written authorisation before capturing.
Sensitive data exposure. Packet captures may contain cleartext credentials (HTTP, FTP, Telnet, SNMPv1/v2 community strings), session cookies, personal health or financial data, and private communications. Treat all .pcap files as sensitive — restrict access, encrypt at rest, delete when no longer needed.
Privacy regulations. GDPR, HIPAA, PCI-DSS, and other regulations govern capture and retention of user traffic. Consult your organisation's data protection and security policies before capturing on production networks.
Safe-harbour practices. Document every capture: date, time, interface, capture filter, purpose, and authorising manager. This creates an audit trail protecting you if your actions are questioned.

14. Key Points & Exam Tips

Wireshark is a GUI packet analyser; tcpdump is its CLI equivalent. Both use the same .pcap file format and libpcap library.
Three panes: Packet List (one row per packet), Packet Details (layer-by-layer tree), Packet Bytes (hex + ASCII). Clicking a row populates the other two panes.
Capture filter = BPF syntax, set before capture, permanently excludes non-matching packets. Display filter = Wireshark syntax, set after capture, hides but does not delete packets. Colour: green = valid, red = invalid.
Display filter syntax: ip.addr == (src or dst), ip.src ==, tcp.port ==, protocol names (http, dns, icmp, arp, dhcp), combine with and/or/!.
TCP analysis filters: tcp.analysis.retransmission (packet loss), tcp.analysis.duplicate_ack (congestion), tcp.analysis.zero_window (receiver buffer full), tcp.flags.reset == 1 (connection rejected).
Follow TCP Stream: right-click any packet → Follow → TCP Stream. Reconstructs entire session. Red = client data, Blue = server data.
Expert Information (Analyse menu): auto-categorises warnings into Error/Warning/Note/Chat. First stop for investigating a new capture — go straight to Warnings (yellow) for TCP problems.
Statistics menu: Protocol Hierarchy (traffic breakdown), Conversations (top talkers), I/O Graphs (traffic over time), TCP Stream Graph (RTT, throughput, window).
File > Export Objects > HTTP: extract files transferred over unencrypted HTTP from the capture (images, documents, scripts).
On switched networks, Wireshark only captures traffic involving the capture host. Use a SPAN/mirror port on a managed switch to see all traffic on a segment.

15. Wireshark – GUI Packet Analyzer Quiz

1. An analyst opens a large 500 MB capture file in Wireshark and needs to quickly find the first sign of a problem. Which feature should they open immediately, and why?

A. Scroll the Packet List from the top — problems appear in chronological order B. Apply a display filter for tcp to narrow down the traffic C. Use File > Export Specified Packets to reduce file size D. Analyse > Expert Information — Wireshark automatically categorises all notable events by severity (Error, Warning, Note). Jump to the Warnings section to see all TCP retransmissions, duplicate ACKs, and zero window events instantly — no manual scrolling required

Correct answer is D. Expert Information is the fastest path to problems in any capture, regardless of size. Wireshark analyses every packet as it is loaded and automatically classifies notable events: Errors (red) = protocol violations, malformed packets, checksum failures. Warnings (yellow) = TCP retransmissions, duplicate ACKs, out-of-order segments, zero window events, RST packets. Notes (blue) = connection resets, ICMP errors, window updates. Chat (grey) = normal events like SYN, FIN, HTTP responses. Opening Analyse > Expert Information gives an instant summary of every warning in the file with the packet number, so you can jump directly to the first problem event without scrolling through thousands of packets. The Warnings category in particular is where the vast majority of network performance problems appear. Scrolling the Packet List (option A) is impractical for 500 MB captures. Applying a filter (option B) requires knowing what you're looking for first.

2. An engineer captures traffic and applies the display filter `tcp.flags.syn == 1 and tcp.flags.ack == 0`. What does this filter show, and what problem would many results from random source IPs indicate?

A. All TCP packets with any flag set; many results indicate normal traffic B. Only the initial SYN packet of new connections (SYN without ACK — not SYN-ACK). Many results from many different source IPs with no corresponding SYN-ACK completions indicates a SYN flood DDoS attack — thousands of half-open connections exhausting server resources C. TCP FIN packets closing connections; many results indicate clients disconnecting normally D. All TCP ACK packets acknowledging received data

Correct answer is B. The filter tcp.flags.syn == 1 and tcp.flags.ack == 0 precisely isolates the very first packet of any new TCP connection — the initial SYN. This is the packet a client sends to initiate a three-way handshake. Adding tcp.flags.ack == 0 excludes SYN-ACK packets (which have both SYN and ACK set, value = 18 = 0x12). In normal traffic, each initial SYN is quickly followed by a SYN-ACK from the server and then an ACK from the client to complete the handshake. A SYN flood attack sends massive numbers of SYN packets — often with spoofed source IPs — without ever completing the handshake. Each SYN causes the server to allocate a half-open connection table entry and send a SYN-ACK. The spoofed sources never reply with ACK. When the table fills, the server cannot accept legitimate connections. Seeing hundreds or thousands of this filter's results per second from diverse random source IPs, with no corresponding ACK completions, is the Wireshark signature of a SYN flood. You would also typically see the server generating many SYN-ACK retransmissions (tcp.analysis.retransmission) as it waits for the ACKs that never arrive.

3. A network engineer wants to see all the HTTP traffic between a specific client (10.0.0.50) and a web server (203.0.113.10) in one readable view, including the full request URL and server response. What is the correct sequence of actions?

A. Apply display filter http and read each packet individually B. Apply capture filter ip.addr == 10.0.0.50 before starting C. Apply display filter ip.addr == 10.0.0.50 and ip.addr == 203.0.113.10, click any HTTP packet in the result, right-click → Follow → HTTP Stream. The full request/response conversation appears with client traffic in red and server traffic in blue D. Use Statistics → Conversations to find the conversation and export it

Correct answer is C. The correct workflow combines a focused display filter with Follow Stream. Step 1 — apply the display filter: ip.addr == 10.0.0.50 and ip.addr == 203.0.113.10. This shows only packets between these two specific IP addresses (in either direction). The ip.addr == operator matches src OR dst, so this filter captures traffic flowing both ways. Step 2 — click any HTTP packet from this conversation in the filtered Packet List. Step 3 — right-click → Follow → HTTP Stream (or TCP Stream for non-HTTP). Wireshark then: (a) finds all packets belonging to this TCP session using the 4-tuple (src IP, dst IP, src port, dst port); (b) reassembles the segments in sequence; (c) presents the complete application-layer conversation in the stream window with client data in red and server data in blue. You can see the full HTTP GET request line, all headers, and the complete server response body. Option A (reading packets individually) would require examining dozens of packets and manually piecing together the conversation. Option B is incorrect because ip.addr is a display filter syntax — it cannot be used as a capture filter (which uses BPF syntax like host 10.0.0.50).

4. An analyst sees many rows highlighted in red in the Wireshark Packet List during a capture of web traffic. The Expert Information shows numerous "TCP Retransmission" and "Duplicate ACK" warnings. What do these indicate, and how should the investigation proceed?

A. Packet loss on the network path — data is being sent more than once because ACKs are not arriving. Apply tcp.analysis.retransmission to isolate affected flows, then check Statistics → TCP Stream Graph → Round Trip Time to identify when RTT increased and correlate with the network path B. The web server is sending duplicate data intentionally for reliability C. Wireshark is displaying the same packet twice due to a capture error D. The TCP window size is too large and needs to be reduced

Correct answer is A. Red-highlighted rows with TCP Retransmission and Duplicate ACK warnings are the classic Wireshark signature of packet loss on the network path. Understanding the mechanism: TCP Retransmission — the sender did not receive an ACK for a segment within the retransmission timeout. It resends the segment. The Wireshark flag tcp.analysis.retransmission marks the duplicate. Duplicate ACK — the receiver got out-of-order data (a gap in sequence numbers), so it ACKs the last in-order byte repeatedly to signal the sender to re-transmit the missing segment. Three duplicate ACKs trigger "fast retransmit" without waiting for the timeout. Investigation procedure: (1) Apply filter tcp.analysis.retransmission to count and see which flows are affected. (2) Open Statistics → TCP Stream Graph → Round Trip Time — plot RTT over time. A sudden RTT spike followed by retransmissions indicates the path became congested at that time. (3) Check the network infrastructure for errors: switch interface error counters (show interfaces), wireless signal quality, or WAN link health. TCP window size (option D) is a separate issue — zero window events cause the sender to PAUSE, not retransmit already-sent data.

5. A security analyst wants to find any HTTP packets in a capture that contain the word "password" anywhere in the payload. They also want to exclude HTTPS traffic. What display filter achieves this?

A. tcp.port == 80 contains "password" B. ip contains "password" C. http and frame contains "password" — the http filter limits to unencrypted HTTP traffic (port 80); frame contains "password" searches the full packet bytes for the literal string D. tls contains "password"

Correct answer is C. This question tests two concepts: (1) protocol filtering for HTTP vs HTTPS, and (2) payload content search. The http display filter matches packets that Wireshark identifies as HTTP protocol — this is port 80 unencrypted HTTP. It does NOT match HTTPS (TLS-encrypted traffic on port 443) because Wireshark recognises those as tls protocol, not http. This automatically satisfies the "exclude HTTPS" requirement without an extra negation. The frame contains "password" filter searches the raw bytes of the entire frame for the ASCII string "password" — it's case-sensitive and matches anywhere in the frame. Combining with and: the filter shows only HTTP packets that also contain the word "password." Common findings: cleartext login forms submitting credentials via POST, basic authentication headers ("Authorization: Basic..."), or API keys in HTTP query parameters. Option A is invalid syntax — you can't apply contains directly to a port filter expression like that. Option D is counterproductive — TLS payloads are encrypted, so frame contains "password" would never match in TLS traffic.

6. An engineer sets up a capture with no display filter and sees `dhcp` packets in the capture. They apply the filter `dhcp` and see a Discover but no subsequent Offer. What is the significance, and what should be investigated next?

A. This is normal — DHCP takes several minutes to respond on busy networks B. The DHCP server is not reachable or not responding — the Discover was broadcast but no server replied with an Offer. Check if DHCP Snooping is blocking the Offer on the switch, whether the DHCP server is up, or whether a DHCP relay (ip helper-address) is needed for this VLAN C. The DHCP server already has a lease for this client; it skips the Offer step D. The capture filter excluded DHCP Offer packets

Correct answer is B. The DHCP DORA process (Discover → Offer → Request → ACK) is a complete 4-step handshake. A DHCP Discover is a broadcast (src IP 0.0.0.0, dst IP 255.255.255.255) sent by the client trying to find any available DHCP server. A DHCP Offer is the server's response, providing an available IP address, subnet mask, default gateway, and lease time. If the Discover is visible in Wireshark but no Offer appears, the server did not respond. Possible causes: (1) DHCP Snooping: if enabled on the switch and the uplink to the DHCP server is not marked as "trusted," DHCP Offer messages arriving on untrusted ports are dropped. (2) No DHCP server on the segment: the server may be on a different subnet, requiring a DHCP relay agent (ip helper-address command on the Layer 3 interface or SVI). (3) DHCP server is down or has no available addresses in its pool. (4) Firewall blocking UDP ports 67 and 68. The engineer should: check DHCP snooping trust on switch uplinks; ping the DHCP server; verify ip helper-address on the SVI; check DHCP server logs for errors.

7. What is the difference between using `ip.addr == 10.0.0.1` and `ip.src == 10.0.0.1` as display filters, and when would the distinction matter?

A. They are identical — Wireshark treats src and addr interchangeably B. ip.addr is faster because it searches fewer fields C. ip.src matches both source and destination; ip.addr matches source only D. ip.addr == 10.0.0.1 matches any packet where 10.0.0.1 appears as EITHER source OR destination. ip.src == 10.0.0.1 matches ONLY packets where 10.0.0.1 is the source. The distinction matters when isolating traffic direction — e.g., seeing only requests FROM a host vs all traffic involving it

Correct answer is D. This is one of the most important and commonly misused display filter distinctions. ip.addr == X: matches any packet where the value X appears in either the IP source field OR the IP destination field. It is a bi-directional filter. Use it to see "all traffic involving this host" — both packets it sends and packets addressed to it. ip.src == X: matches ONLY packets where X is the source IP. It is unidirectional. Similarly, ip.dst == X matches only packets addressed to X. Practical examples of when direction matters: Security analysis — an analyst suspects a host is scanning the network. Apply ip.src == 10.0.0.50 and tcp.flags.syn == 1 — shows only connections initiated FROM the suspicious host. If you used ip.addr, you'd also see incoming connections to it, which could obscure the outbound scan. Performance diagnosis — you want to see only the server's responses (not client requests): use ip.src == server_ip. Troubleshooting NAT — verify outbound traffic uses the public IP with ip.src == public_ip. An important caveat: the filter ip.addr != 10.0.0.1 does NOT work as expected — it shows packets where 10.0.0.1 is NOT both the source AND destination simultaneously (almost all packets). Use !(ip.addr == 10.0.0.1) instead.

8. An engineer is performing a security audit of unencrypted network traffic. They use Follow TCP Stream on an HTTP session and see a POST request with "username=admin&password=P@ss123" in the body. What does this demonstrate about the application, and what should the engineer document?

A. The application transmits credentials in cleartext over HTTP (no encryption). This is a critical security vulnerability — any attacker with network access or a capture file can extract the password. Document: the filter used, timestamp, source/ destination IPs, the fact that credentials are visible, and recommend enforcing HTTPS with HSTS B. This is normal — HTTP POST forms always encrypt the body separately from the transport C. Follow TCP Stream decrypts TLS traffic automatically, so this is from an HTTPS session D. The password is hashed — POST body data is always hashed before transmission

Correct answer is A. This scenario demonstrates one of the most critical findings in a network security audit. HTTP (port 80) provides no transport-layer encryption — all data, including form submissions in POST request bodies, is transmitted in plaintext. When Follow TCP Stream shows "username=admin&password=P@ss123" in red (client data), this is the literal content of the HTTP POST body as sent over the wire. Any device on the network path — a switch with a mirror port, a wireless access point, a compromised router — can capture and read this content. The vulnerability is "cleartext credential transmission." Severity: Critical. Documentation requirements for the audit report: (1) Evidence: Wireshark screenshot of Follow TCP Stream window showing the credentials. (2) Timestamp and packet numbers from the capture. (3) Source IP (client), destination IP (server), destination port (80). (4) Filter used to find it:

http.request.method == "POST" and
                  http.file_data contains "password"

. (5) Recommendation: enforce HTTPS (TLS 1.2+) with HTTP Strict Transport Security (HSTS); redirect all HTTP to HTTPS; consider certificate pinning. Option B is false — HTTP POST bodies have no encryption independent of transport. Option C is false — Follow TCP Stream does not decrypt TLS without providing session keys (SSLKEYLOGFILE). Option D is false — POST body data has no automatic hashing; what you see in the stream is what was sent.

9. An analyst captures traffic on a workstation but only sees traffic to and from that workstation — not traffic between two other hosts on the same switch. What is the reason, and what network change enables capturing all segment traffic?

A. Promiscuous mode is not enabled in Wireshark — enable it in Capture Options B. A display filter is hiding the other traffic — remove all filters C. Modern switches forward frames only to the correct destination port — the analyst's NIC physically never receives traffic between other hosts. A SPAN (port mirror) session on the managed switch must copy source port traffic to the analyst's port, allowing Wireshark to capture inter-host traffic D. The capture file format (.pcap) only supports capturing the local host's traffic

Correct answer is C. This is the fundamental limitation of packet capture on modern switched networks, and understanding it separates skilled analysts from beginners. Promiscuous mode (option A) puts the NIC in a state where it accepts ALL frames that physically arrive at the NIC — not just those addressed to its MAC. But on a switch, the frames between other hosts never physically arrive at the analyst's port — the switch's forwarding hardware ensures unicast frames go only to the correct destination port. Enabling promiscuous mode cannot make the NIC receive frames it never physically received. The solution is a SPAN session (also called port mirroring): the switch copies traffic from designated source ports to a dedicated mirror/destination port where the analyst's workstation is connected. On Cisco switches: monitor session 1 source interface Gi0/1 - 3 both and monitor session 1 destination interface Gi0/24. Now ALL traffic flowing through Gi0/1-3 is copied to Gi0/24 where Wireshark can capture it. Hardware TAP devices (inline physical taps) are an alternative — they passively copy all traffic on a link without requiring switch configuration. Note: on hubs (now rare), all traffic is broadcast to all ports, so promiscuous mode alone gives full visibility — but this is not how modern networks work.

10. An engineer uses Statistics → I/O Graph in Wireshark during a performance investigation. They add a second line with the filter `tcp.analysis.retransmission`. What does each line represent, and what pattern would indicate a specific problem?

A. Both lines show total bandwidth; the second shows bandwidth used by retransmissions only. An equal height means the network is efficient B. The first line shows total traffic volume over time (all packets). The second line shows retransmission events over time. If the retransmission line spikes at the same time as a dip in total throughput, it indicates a period of packet loss causing TCP to slow down and retransmit — congestion collapse on the path C. The second line shows TCP SYN packets; comparing the lines reveals connection rates D. I/O Graph only supports one line; adding a second requires a paid Wireshark licence

Correct answer is B. Wireshark's I/O Graph (Statistics → I/O Graph) is a powerful tool for correlating traffic patterns over time. By default it plots total packet rate or byte rate across the capture duration — you can see when traffic was high or low in a time-series view. Adding a second line with a specific display filter (tcp.analysis.retransmission) overlays the count of retransmission events on the same time axis. This allows visual correlation: scenario 1 — retransmission spikes during periods of high throughput — indicates the high traffic rate itself is causing congestion (buffer overflow on a bottleneck link). Scenario 2 — retransmission spikes cause the total throughput line to DROP simultaneously — this is TCP congestion control in action: TCP detects packet loss (via retransmission timeout or 3 duplicate ACKs), reduces its congestion window, and sends less data. You see total throughput fall and retransmissions rise at the same inflection point. This pattern precisely pinpoints WHEN the packet loss started, which you can then correlate with network events (switch failover, link congestion, new traffic flow beginning). Wireshark I/O Graph supports multiple lines with any display filter (option D is false — it's a free tool). Each line can use different Y-axis units (packets/sec, bytes/sec, or counts).

← Back to Home