Wireshark’s capture filters are a superpower, but they’re not what you think: they discard packets before they even hit Wireshark’s display, saving you from wading through gigabytes of irrelevant noise.

Let’s see a real-world example. Imagine you’re troubleshooting a slow web server. You want to see only the HTTP traffic between your client and the server, and nothing else.

# Assuming your client IP is 192.168.1.100 and the server IP is 10.0.0.50
# This filter captures traffic only to or from port 80 (HTTP)
# on the specified IP addresses.
wireshark -i eth0 "host 192.168.1.100 and host 10.0.0.50 and port 80"

This command, run from your terminal, tells Wireshark to start capturing on interface eth0 but to only store packets that meet all three criteria: they must be from or to 192.168.1.100, from or to 10.0.0.50, and either the source or destination port must be 80. If you were to omit the port 80 part, you’d get all traffic between those two hosts, which might still be too much.

The magic behind Wireshark’s capture filters is the Berkeley Packet Filter (BPF) syntax. It’s a mini-language designed for efficiently selecting network packets at the kernel level. This means the filtering happens before the packet even gets to your application (Wireshark), which is crucial for high-traffic networks where capturing everything would overwhelm your system.

Here’s how to build your own BPF expressions, broken down by common scenarios:

Filtering by Host

This is the most fundamental filter.

  • Show traffic to or from a specific IP address: host 192.168.1.1 This captures packets where 192.168.1.1 is either the source or destination IP.

  • Show traffic from a specific IP address: src host 192.168.1.1 This captures packets only when 192.168.1.1 is the source IP.

  • Show traffic to a specific IP address: dst host 192.168.1.1 This captures packets only when 192.168.1.1 is the destination IP.

  • Show traffic between two specific IP addresses: host 192.168.1.1 and host 10.0.0.1 This combines the host primitive to get traffic involving either IP, and and to ensure both are present.

Filtering by Network

When you need to capture traffic for an entire subnet.

  • Show traffic to or from a network (CIDR notation): net 192.168.1.0/24 This captures packets where the source or destination IP falls within the 192.168.1.0 to 192.168.1.255 range.

  • Show traffic from a network: src net 192.168.1.0/24

  • Show traffic to a network: dst net 192.168.1.0/24

Filtering by Port

Essential for targeting specific application protocols.

  • Show traffic to or from a specific port: port 80 This captures packets where the source or destination port is 80 (HTTP).

  • Show traffic to a specific port: dst port 443 This captures packets destined for port 443 (HTTPS).

  • Show traffic from a specific port: src port 22 This captures packets originating from port 22 (SSH).

  • Show traffic for a range of ports: portrange 1000-2000 Captures traffic involving ports from 1000 up to and including 2000.

Filtering by Protocol

Focus on specific layers of the network stack.

  • Show only IP traffic: ip This is equivalent to ether proto 2 for Ethernet.

  • Show only TCP traffic: tcp This is equivalent to ether proto 6.

  • Show only UDP traffic: udp This is equivalent to ether proto 17.

  • Show only ARP traffic: arp This is equivalent to ether proto 806.

Combining Filters

The real power comes from combining these primitives.

  • TCP traffic from a specific host to a specific port: tcp and src host 192.168.1.100 and dst port 80 This is perfect for isolating client requests to a web server.

  • UDP traffic to or from a broadcast address: udp and dst net 255.255.255.255 Useful for debugging DNS or other broadcast protocols.

  • Traffic that is NOT DNS (port 53): not port 53 This excludes all DNS queries and responses.

  • Traffic to or from a host, but not SSH: host 192.168.1.1 and not port 22 This lets you see general traffic from a server but skip the SSH sessions.

Advanced Filters

Sometimes you need to dig deeper.

  • Filter by MAC address: ether src 00:11:22:33:44:55 ether dst aa:bb:cc:dd:ee:ff Useful when troubleshooting Layer 2 issues or specific devices on a local segment.

  • Filter by VLAN ID: vlan 10 Captures packets tagged with VLAN ID 10. You can also use vlan 10 and vlan 20 for double-tagged frames if your hardware supports it.

  • Filter by packet length: len <= 64 Captures packets that are 64 bytes or smaller. greater 1000 Captures packets larger than 1000 bytes.

The most surprising thing about BPF is how much it can do at the kernel level with such a simple syntax. It’s not just about filtering; it’s about performing calculations and comparisons on packet headers extremely efficiently. For instance, tcp[13] & 0xf0 doesn’t just look at a byte; it’s a byte offset (13) into the TCP header, and then applies a bitmask (& 0xf0) to isolate specific flags.

When you’re working with TCP, you’ll often want to see the flags. The byte at offset 13 in the TCP header contains the flags. The bits are ordered from most significant to least significant: URG, ACK, PSH, RST, SYN, FIN. To isolate the SYN flag, which is the 2nd bit from the right (value 2), you’d use tcp[13] & 2 != 0. To see packets that are only SYN and ACK, you might use tcp[13] = 0x12.

After fixing your capture filters and successfully isolating the traffic you need, the next common hurdle is understanding the display filters within Wireshark itself. These are applied after capture and offer a much richer, protocol-aware syntax.

Want structured learning?

Take the full Wireshark course →