Wireshark Display Filters Explained with Real Examples

🔹 Introduction

When you start capturing packets in Wireshark, the sheer volume of data can be overwhelming. Thousands of packets flash across the screen in seconds, making it hard to spot what really matters. That’s where Wireshark display filters come in.

Display filters are like powerful lenses—you can zoom in on exactly the traffic you care about: DNS lookups, failed TCP handshakes, specific IPs, or even suspicious activity. Mastering filters transforms Wireshark from a noisy stream into a precision analysis tool.

This article explains how display filters work, provides syntax examples, and shows you how to use them in real troubleshooting and security investigations.

🔹 Difference Between Capture Filters and Display Filters

• Capture Filters: Applied before capture, limit what packets are saved. Syntax based on BPF (Berkeley Packet Filter). Example: tcp port 80.
• Display Filters: Applied after capture, let you slice and dice the packets in your trace file. Syntax is unique to Wireshark. Example: http.request.method == “GET”.

Best practice: Capture broadly, filter narrowly. Capture filters risk missing important traffic; display filters let you focus later.

🔹 Basic Filter Syntax

A display filter usually follows this structure:

<protocol>.<field> <operator> <value>

Examples:

ip.addr == 192.168.1.10

tcp.port == 443

http.request.method == "POST"

Operators

🔹 Common Display Filter Examples

IP Filtering

• All traffic from/to a host:

      ip.addr == 10.10.1.25
    

• Traffic between two hosts:

      ip.src == 10.10.1.25 && ip.dst == 10.10.2.50
    

• Exclude a host:

      ip.addr != 192.168.100.1
    

TCP Filters

• Show only TCP traffic:

      tcp
    

• Filter on port:

      tcp.port == 443
    

• SYN packets only:

      tcp.flags.syn == 1 && tcp.flags.ack == 0
    

• Retransmissions:

      tcp.analysis.retransmission
    

UDP Filters

• Show only DNS traffic:

      udp.port == 53
    

• Show all UDP:

      udp
    

HTTP Filters

• All HTTP traffic:

      http
    

• GET requests only:

      http.request.method == "GET"
    

• POST requests only:

      http.request.method == "POST"
    

• Requests to a specific host:

      http.host == "www.example.com"
    

DNS Filters

• All DNS queries:

      dns
    

• Queries for a specific domain:

      dns.qry.name == "sanchitgurukul.com"
    

• Failed responses:

      dns.flags.rcode != 0
    

TLS/SSL Filters

• Show all TLS traffic:

      tls
    

• Handshake failures:

      tls.alert_message == 40
    

• Specific cipher suites:

      tls.handshake.ciphersuite == 0x0035
    

VoIP/SIP Filters

• Show SIP signaling:

      sip
    

• Show RTP streams:

      rtp
    

• Filter by call ID:

      sip.Call-ID == "1234@pbx.example.com"
    

Advanced Examples

• All traffic from a subnet:

      ip.addr == 192.168.1.0/24
    

• Find large packets:

      frame.len > 1000
    

• Regex filter:

      http.host matches ".*google.*"
    

🔹 Real-World Use Cases

1. Troubleshooting Slow Web Browsing

Scenario: Users report slowness loading http://www.company.com.
Filter:

      http.host == "www.company.com"
    

Analysis:

• See if requests are delayed.
• Check for TCP retransmissions with tcp.analysis.retransmission.
  Outcome: Found packet loss on WAN link causing multiple retransmissions.

2. Diagnosing DNS Failures

Scenario: Intermittent failures accessing SaaS app.
Filter:

      dns.qry.name == "app.saasprovider.com"
    

Analysis: Some DNS queries returned SERVFAIL.
Outcome: Identified misconfigured DNS forwarder.

3. Security Investigation: Suspicious Traffic

Scenario: IDS flagged potential data exfiltration.
Filter:

      ip.addr == 203.0.113.50 && http.request.method == "POST"
    

Analysis: Found repeated POST requests to unknown IP. Payloads matched sensitive data.
Outcome: Host quarantined, incident escalated.

4. VoIP Call Quality Issues

Scenario: Choppy audio in SIP calls.
Filters:

      sip
    

      rtp
    

Analysis: High RTP packet loss and jitter.
Outcome: Bandwidth policing misconfiguration fixed.

5. IoT Device Monitoring

Scenario: Smart device behaving oddly.
Filter:

      ip.addr == 192.168.1.55
    

Analysis: Found device continuously contacting unknown external servers.
Outcome: Blocked traffic, escalated to security.

🔹 Best Practices for Using Display Filters

• Start broad (http, dns) then narrow down.
• Save frequently used filters in Wireshark for quick access.
• Use coloring rules with filters for visual cues.
• Combine multiple filters with AND/OR logic.
• Document filters in your troubleshooting playbooks.

🔹 Summary

Wireshark display filters are the secret to making sense of complex network captures. With them, you can:

• Focus on specific conversations.
• Diagnose application issues.
• Investigate security incidents.
• Learn protocols in depth.

The key to mastery is practice—start with simple filters like dns or http, then move to advanced conditions with logical operators. Once you’re fluent, Wireshark becomes not just a packet capture tool, but a precision microscope for networks.

🔹Useful Links

https://www.wireshark.org/docs/relnotes

https://sanchitgurukul.com/basic-networking

https://sanchitgurukul.com/network-security