Wireshark is the world’s most popular protocol analyzer, and the possible uses for the tool are endless. Yet, the first time you begin to capture network traffic, it can be overwhelming how many packets you’ll have to sift through to find just the ones you need. Proper analyzer placement combined with capture filters can help you avoid the dreaded packet vortex.
The easiest approach is to be selective in where you begin to capture data in the first place. Let’s say you were troubleshooting slow application response time. Users can access the application, but they complain that it’s “slow”. I recommend starting at the server and working your way back to the affected clients. This will get to the root cause of the problem faster, but means that millions of packets will be captured. That’s where the capture filter comes into play.
- Disable TCP/IP on the host running Wireshark so that its traffic doesn’t interfere in any way with the test. Bonus – fewer packets to review.
- Configure a port span on the switch to copy all packets to/from the server interface to the Wireshark host.
- Enlist the assistance of a user who has experienced the slow response. Find out their current IP address.
- Configure a capture filter in Wireshark for the IP address of the test user (step by step instructions below).
- Start capturing.
- Go back to the user and have them access the application. Make copious notes about what they do and where the “slow” responses are to make it easier to understand what you’re seeing in the packets. I like to use my cell phone to video their screen as they work so I can remember everything in the application.
- Stop capturing and review the packet trace file.
Sometimes people ask, “Why is the syntax different for capture filters versus display filters? Isn’t it all just Wireshark?” The answer is Wireshark does not actually capture the packets from the network itself. Special link-layer drivers pass the packets from the network to the capture engine component dumpcap, the special drivers, WinPcap and libpcap, are responsible for the filtering. You’ll use WinPcap in Windows and libpcap in Unix (or any operating systems based on Unix). WinPcap and libpcap use Berkeley Packet Filter syntax. If you have ever used tcpdump, you should be familiar with this syntax. If not, Wireshark checks your capture filter syntax and gives great visual feedback – green for “go,” red for “stop and fix.”
So, what are the specifics for setting up the capture filter in Wireshark? First, you need to determine which capture interface to use, Capture | Capture Interfaces. My en2 device is my Ethernet connection. Notice that it has no IP address associated with it now that I have disabled my TCP/IP stack for that device. Next, click Options then double-click on the interface. The Edit Interface Settings dialog box is where you will type your capture filter. I have “host 10.20.50.130” which is the IP address of my user. Click OK | Start, and you’ll be capturing only traffic between the test user and the server.
Here are a few other useful capture filters:
- net 10.20.50.0/24 — Capture traffic to/from a subnet.
- port 53 — Capture either TCP or UDP port 53 for DNS.
- tcp port 80 — Capture only TCP port 80, not UDP port 80.
- portrange 9500–9600 — Capture a range of TCP or UDP ports for a custom application.
Any of these filters can be combined with operators using symbols or words; &&, ||, !, and, or, not. For example:
- not port 53 and (host 10.20.50.130 or host 10.20.50.131) — Capture all traffic to/from either IP address, but not if uses TCP/UDP port 53.
- !port 53 && (host 10.20.50.130 || host 10.20.50.131) — This would yield the same result. Using symbols or words is a matter of preference.
Once the user has demonstrated the issue, you can analyze the trace file to find the root cause. Realize that you may have to repeat the process in various positions in the network to find the true culprit. At least now you have avoided the packet vortex!
Related Courses
Troubleshooting TCP/IP Networks with Wireshark