Most network engineers know how to launch Wireshark and start a capture. Fewer know how to use it efficiently at scale — filtering to the exact traffic that matters, measuring RTT and retransmissions, distinguishing network-layer problems from application-layer problems, and capturing remotely on production hosts without disrupting traffic. This guide covers the practical techniques.

Capture Filter vs Display Filter — Know the Difference

These are fundamentally different mechanisms with different syntax and different points of application:

  • Capture filter (BPF syntax): Applied at capture time by libpcap/WinPcap. Packets that don't match are never stored. Essential for reducing capture file size on busy links. Syntax: host 10.1.1.1 and tcp port 443, not arp, udp and port 53.
  • Display filter (Wireshark syntax): Applied post-capture to filter what you see. Does not remove packets from the capture file — it hides non-matching packets. More expressive than BPF. Syntax: ip.addr == 10.1.1.1 && tcp.port == 443, tcp.flags.syn == 1 && tcp.flags.ack == 0.

Common mistake: using display filter syntax in the capture filter box. BPF does not understand Wireshark field names. If your capture filter is ip.addr == 10.1.1.1, it will silently capture everything (or fail, depending on OS).

Essential Display Filters for Troubleshooting

/* TCP retransmissions and errors */
tcp.analysis.flags && !tcp.analysis.window_update

/* Only retransmissions */
tcp.analysis.retransmission || tcp.analysis.fast_retransmission

/* TCP RST — abrupt connection terminations */
tcp.flags.reset == 1

/* DNS failures */
dns.flags.rcode != 0

/* HTTP errors */
http.response.code >= 400

/* TLS handshake failures (Alert) */
tls.record.content_type == 21

/* Slow ACKs — server delay */
tcp.analysis.ack_rtt > 0.1

Measuring Application Latency

Wireshark's TCP stream analysis reveals where time is being spent in a transaction. The key metric: time delta between displayed frames in a filtered TCP stream.

Technique: Follow TCP Stream (right-click → Follow → TCP Stream) to isolate a single connection. Enable the tcp.time_relative column (View → Column Preferences). Look for large deltas:

  • Client → Server delay followed by Server → Client response: The server is processing the request. This is application or database latency, not network latency.
  • Server → Client packets followed by a long gap before ACK from client: Client-side processing delay or network latency to the client.
  • Many small packets from client/server with no large delay: Normal streaming. If you expected a response but see TCP ACKs only, the server hasn't responded yet — application bottleneck.

The RTT Expert: Statistics → TCP Stream Graphs → Round Trip Time. This plots the measured RTT for each segment in the stream over time. A flat line is good. Steps upward indicate path change or congestion. Spikes indicate transient queuing or retransmission events.

Remote Capture on Linux Servers

Running Wireshark on a production Linux server via GUI is impractical. Use tcpdump to capture remotely and pipe to Wireshark over SSH in real time:

ssh user@server "sudo tcpdump -i eth0 -U -s0 -w - 'port 5432'" | wireshark -k -i -

Breaking this down:

  • -U — packet-buffered output (write each packet immediately, don't buffer)
  • -s0 — capture full frame (default snaplen of 65535 bytes)
  • -w - — write to stdout
  • wireshark -k -i - — open Wireshark, start immediately (-k), read from stdin (-i -)

For environments where SSH to production is not permitted, capture to a file: tcpdump -i eth0 -w /tmp/capture.pcap -s0 'host 10.1.2.3'. Transfer the file with scp and open it locally.

TLS Decryption with Pre-Master Secret Logs

In environments where you control the client application, you can decrypt TLS traffic in Wireshark using the NSS keylog file. Configure the client to log TLS secrets:

# For applications using OpenSSL:
export SSLKEYLOGFILE=/tmp/tls-keys.log

# For Chrome/Firefox (set before launch):
SSLKEYLOGFILE=/tmp/tls-keys.log google-chrome

In Wireshark: Edit → Preferences → Protocols → TLS → Master-Secret log filename. Point to the keylog file. Wireshark will now decrypt captured TLS sessions for those connections in real time or from a saved capture.

This technique is invaluable for debugging HTTPS applications where you see TCP-level communication but need to inspect HTTP/2 frames, gRPC calls, or REST API responses.

Identifying MTU and Fragmentation Issues

Display filter: ip.flags.mf == 1 || ip.frag_offset > 0 — shows fragmented IP packets. If you see fragmentation on paths that should have jumbo frame support (iSCSI, NFS, vSAN), it indicates MTU mismatch. Check with: ping -M do -s 1472 10.1.1.1 (Linux) or ping -f -l 1472 10.1.1.1 (Windows) — if this fails while smaller sizes succeed, you have an MTU black hole on the path.

Sripadatech's network engineers diagnose complex application and infrastructure performance issues. Contact us to engage our network troubleshooting team.