The most surprising thing about network packet capture is that you’re not actually capturing packets in real-time; you’re dropping most of them, and the tool just happens to keep the ones you care about.
Let’s see it in action. Imagine we’re troubleshooting why a web server is slow to respond to a specific client. We’ll use Wireshark to inspect the traffic between them.
First, we need to identify the interfaces on our capture machine. On Linux, this is ip a or ifconfig. On Windows, it’s ipconfig /all. Let’s say we see eth0 and lo (loopback). If our server is on 192.168.1.100 and the client is 192.168.1.50, and our capture machine is also 192.168.1.100 (acting as a gateway or directly connected), we’d want to capture on the interface connected to the 192.168.1.0/24 network. On Linux, this might be eth0.
We don’t want all traffic on eth0, though. We only care about the conversation between 192.168.1.100 and 192.168.1.50. This is where capture filters come in, and they are crucial for performance and manageability. Display filters, applied after capture, are for analysis. Capture filters are applied by the capture driver before packets even hit Wireshark’s buffer.
To capture only traffic to and from 192.168.1.50 on eth0, we’d use a filter like host 192.168.1.50. This is a BPF (Berkeley Packet Filter) syntax.
In the Wireshark GUI, you’d select your interface (eth0 in this case) and then, before starting the capture, enter host 192.168.1.50 into the "Capture filter" box at the bottom of the interface selection window.
When you start the capture, Wireshark is telling the operating system’s packet capture library (like libpcap or WinPcap/Npcap) to only pass packets that match host 192.168.1.50 to Wireshark’s processing engine. The OS’s network stack is still seeing all the packets on eth0, but it’s filtering them at a very low level, drastically reducing the load on your CPU and memory.
The mental model here is that your capture device (your laptop, a dedicated appliance) is a gatekeeper. The network is a river of packets. The capture filter is the gate. You can open the gate wide and let everything through, then sort through it later (display filter). Or, you can install a specific sieve at the gate itself (capture filter) and only let through what you’re interested in before it even gets to your sorting area.
You can make filters more specific. If you only want the HTTP traffic (port 80) between our client and server, and assuming the server is 192.168.1.100, you’d use host 192.168.1.50 and tcp port 80. If you want to see both client-to-server and server-to-client traffic for a specific TCP port, you’d use (host 192.168.1.50 and tcp port 80) or (host 192.168.1.100 and tcp port 80). A more concise way for this specific case is host 192.168.1.50 and port 80. The port keyword matches either source or destination port.
The real power comes when you combine these. For our slow web server scenario, you might want to see all TCP traffic between the client and server, as HTTP is built on TCP. The filter would be host 192.168.1.50 and host 192.168.1.100. This ensures you see the full TCP handshake, any retransmissions, and the actual HTTP requests and responses.
The performance impact of a capture filter is immense. Capturing all traffic on a busy gigabit interface without a filter can quickly overwhelm a standard laptop, leading to dropped packets during capture, making your capture useless. A well-crafted capture filter keeps the packet rate manageable, allowing you to capture for longer periods without losing data.
The most common mistake people make is thinking display filters are sufficient. They are not for performance-critical captures. If you’re on a 10Gbps link and try to capture everything and then filter, you’ll drop packets before Wireshark even gets them. Capture filters are applied at the kernel level by the packet capture driver.
A common scenario is troubleshooting VPN connectivity. If you’re trying to reach a server 10.0.0.5 over a VPN, and your local IP is 192.168.1.50, and the VPN tunnel endpoint on your side is 192.168.1.100, your capture might need to be on eth0 (your local network interface) with a filter like (host 10.0.0.5 and host 192.168.1.100) or (host 192.168.1.100 and host 10.0.0.5). This captures traffic destined for the VPN endpoint that is also destined for the remote server.
Understanding the distinction between capture and display filters is key. Capture filters reduce the volume of data ingested by Wireshark, while display filters reduce the volume of data shown to you from the already-ingested data.
Once you’ve mastered interface selection and capture filters, the next step is understanding how to use Wireshark’s statistics and graphing features to identify performance bottlenecks.