Sometimes a problem arises that requires more than a cursory look at network traffic.

One of the more dynamic tools for packet capture and traffic analysis is Wireshark, used by many for its adaptability and open-source coding. If you’re reading this, it’s very likely you already know what Wireshark is and why you need to use it. This tutorial will help you get started capturing and analyzing your own network traffic. I’ll also go over a real world example of how this tool can be used to troubleshoot problems or improve network efficiency.

There’s a myriad of uses for Wireshark, and this tutorial is by no means the extent of what the program is capable of. I’ll be using version 2.6.1 (May 22, 2018) release, but most of what’s shown here will apply to older versions of the software as well.

Before you get started you’ll want to have a clear goal in mind. One of Wireshark’s greatest strengths is its ability to handle a huge range of issues, and if you dive in without a focus in mind its easy to get lost. Once you’ve decided what you want to get out of Wireshark, it’s time to get started. I’ll be using Wireshark to diagnose a simple network coding error in an off-site piece of software. The end-users are periodically experiencing enormous client-side lag spikes, and it’s time to find a fix.

Let’s capture a ton of packets

Once you’ve installed Wireshark and started it up, you’ll be greeted with the option to start capturing packets along with a list of interfaces and an option to add a capture filter.

Starting to capture packets is simple; just click the interface you want to collect from and hit “capture.”

That’s way too many packets, how about a capture filter?

Ok, we just snagged everything going into and out of that interface, and received tens of thousands of entries before being able to hit the big red STOP button. Before applying a capture filter, Wireshark will grab every single piece of traffic regardless of what it is. This includes router broadcasts, Windows protocols, DHCP requests, everything. Our list not only looks like a jumbled pile of garbage, but if we had continued running this capture we’d end up with a big and clunky snapshot that took forever to load and provided way more information than needed.

Adding a capture filter lets us narrow down what traffic Wireshark is going to be looking for on that interface. Keep in mind that a capture filter is not a display filter. Display filters are much more dynamic and detailed, and are only used after a capture has been made to narrow down displayed information.


Wireshark uses the standard LibPcap/WinPcap library, so if you’re already familiar with the syntax used by other LibPcap/WinPcap programs, you’ll be right at home here. If you’ve never used these libraries before, there’s lots of helpful documentation up on the Wireshark wiki, which can be found here.

In our case, we’re only looking for UDP traffic. Before we start our capture, we’ll enter “UDP” in the capture box, then hit enter to start capturing packets. We could put any number of criteria here to filter, from specific IPs or ports, to entire subnets or specific protocols.

WS screenshot 1

It’s highly recommended that you set some kind of capture filter before starting a capture. While it’s possible to simply add a display filter after you’ve captured everything on a given interface, it’s entirely unnecessary and can slow down analysis of the capture itself. That being said, you don’t have to add a filter if you don’t want to.

Narrowing it down with a display filter

Now that we’ve captured a set of packets, we’re going to need to narrow down what we’re looking at. Through the use of display filters, we can take a large collection of packets and look for specific addresses, protocols, ports, or even packet contents in order to find what we’re looking for.

Just like with the capture filters, Wireshark display filters utilize the LibPcap/WinPcap libraries, so these display filters will share a common syntax with other programs that use those resources. Again take note that display filters and capture filters are not the same, and each filter uses a slightly different syntax. You can find more detailed information on the list of display filter syntax by visiting the Wireshark Wiki.

As an example, if we wanted to view all the packets from the source IP to destination IP between the hours of 1:03 PM local time and 2:03 PM local time, we’d put the following into our display filter:

ip.src == && ip.dst == && ((frame.time >= “July 11, 2018 13:03:00”) && (frame.time <=”July 11, 2018 13:03:00”))

Parenthesis can be used to encapsulate commands to be executed together or change the way the command operates.

Wireshark also lets us create display filters through the GUI with some restrictions and limited functionality. By right-clicking on a packet entry, we can apply our highlighted field as a display filter.

  • Wireshark supports both English and “C-like” filter strings. As an example, if we want our source IP to equal, we can use “eq” or “==”. These commands are interchangable.
  • Integers in Wireshark can be expressed in decimal, octal, or hexidecimal.
  • We can combine expressions with logical operators. Again, these can be expressed in both English or C-like strings.
  • The “is not” expression will not always work as intended when it comes to addresses. Because each packet contains both a source and a destination field, entering the expression ip.addr != will still display packets with that address, as it still contains one field that does not have that address. Instead we’d use ! (ip.addr ==
  • As mentioned above, we can filter any part of a field given within a packet. This includes its frame information and the bits contained within.

Display filters are the primary tool that we use within Wireshark, and mastering them will give you power to find the information you are looking for. By combining the various display filters into complex expressions we can essentially pull and display anything we want from a packet capture. This can be used for everything from diagnosing errors in network software code to aiding in tightening security.

Practical application

Now that we’ve gone over display filters, let’s put it to use in our working example. We’re not only looking for the source of the slowdown, but hoping to provide the engineers with a working solution based on the information contained within our captured packets.

After running a capture filter on only UDP packets, we still have too much data to glean anything useful, so we apply a display filter for the specific port our software is using to communicate with the client host. We only want UDP packets on that port, so our display filter is UDP.port ==59322.

This provides us with only the packets we are looking for.

WS Screenshot 2

We can see in the screenshot something isn’t quite right with the timing on these packets. Normally the server is supposed to be sending less than 20 per second, and we’ve got thousands. Sure enough, when we pull up a log of the last reported slowdown and match the times, there’s a correlation. We pull this information using the previously mentioned frame.time filter and get these results:

WS Screenshot 3

We can see the exact fraction of a second the server goes from “working fine!” to “goodbye, bandwidth!” With thousands of packets flooding the client each second, we’re essentially DDoSing our own network. We want to save this filtered data to look at later and try to find a fix, so we go to File → Save As and use the eloquent “lagspikecapture.pcapng” file name. After spending some time analyzing the bit field down at the bottom, we should be able to source the problem.

The bit field down at the bottom tells us exactly what is inside each packet. In our case, this data is fully encrypted, but many packets are not. You can access a wealth of information by looking at the bit field of a given packet. Using the information found within our captured packets, we were able to quickly identify the issue and implement a fix.

How to get more out of Wireshark

Wireshark can be used in an almost endless number of different ways. You can monitor interfaces for security intrusions, diagnose network errors, and even use plugins like Response Time Viewer to analyze traffic to improve network optimization. Once you know what you want to do, Wireshark can help capture packets, analyze traffic, and ultimately improve your networking experience.

Response Time Viewer for WiresharkDownload FREE tool at