Calculate 802.11 Retry Rate with Wireshark

There are many broadcast and unicast messages between a user and an access point that the user has no idea about! So what if some of them fail while you are streaming or having an internet-based call? A low-quality call? Lags and buffering? Slow uploads and downloads?

Probably all of them! Why? Because for every failure in communications, there will be a retry, and once these retries increase, they will affect your service indirectly.

The number of retries now matters, and in this post, we will take a closer look at how we can calculate Wi-Fi retry rate. We will also try to understand some of the reasons why we can have retries in Wi-Fi.


There are three types of frames in Wi-Fi: Management, Control, and Data. Since all of the Data frames are unicast, by protocol, they have to be acknowledged. If not, the transmitter has to re-send the frame; hence the retry. Not all management and control frames are unicast frames so it is more precise to calculate the retry rate only on data frames.

In order for that to be calculated, we need the number of all data frames and the number of all retried data frames.

Here is the formula you can use to calculate the retry rate in Wi-Fi:


We need some beef to cook! Here are the instructions:

First, we need to capture Wi-Fi frames while users are using the network on the relevant channel. In order to know which channel is used by our AP/network, we can use a Wi-Fi scanner (such as Wi-Fi Explorer Pro). In my case, my AP was using channel 36 – see picture bellow:

Knowing the channel, connect your sidekick to your laptop and use Ekahau Capture to capture some Wi-Fi frames. I did it for about 10 minutes while I was generating some internet traffic.

Once you save it on your computer, you will have a pcap file. You can then open it in Wireshark. When you open it, you will encounter a lot of different frames, and you need to filter them. The filter to use if you want to see all of the data frames is:

wlan.fc.type == 2 and wlan.ta == CLIENT_DEVICE_MAC_ADDRESS

And to filter all of the retransmitted data frames (the retries):

wlan.fc.retry == 1 and wlan.fc.type == 2 and wlan.ta == CLIENT_DEVICE_MAC_ADDRESS

If you want to know more about Wireshark filter please check out this link:

Then head towards the Statistics bar and choose I/O Graph to see something like this:

On the main page of Wireshark, you can use each filter to see how many packets you have for each filter. In our case, I have captured 156170 packets that 9787 of which are data packets for my mobile phone, and 292 of them have a retry flag.

By doing this easy math, you know your network retry rate:



Client stations often stubbornly stick to an AP and do not roam to the others. This might be due to not having a proper received signal strength and some frames not being properly decoded in both uplink and downlink communications. Therefore, these frames are likely not to be acknowledged, resulting in re-transmissions.

Power Mismatch

Some retransmissions could be generated when an AP is set to transmit with the highest power available and the client cannot match the same transmit power levels. Some network operators set the transmit power of the APs to the maximum. This could appear like a good idea to maximize the coverage area of the AP, however, this can also generate retransmissions. Indeed, when the client devices will be farther away from the AP, it will still be able to “hear” the AP quite well however, it won’t have enough power to respond back to the AP. And, by the time the reply reaches the AP, the signal might be too low for the AP to actually be able to decode the frame, therefore generating a retransmission.


It is needless to say that non-Wi-Fi interferences are one of the main reasons for corrupting frames. If the Signal to Noise Ratio (SNR) decreases below average, retry attempts ramp up. Adjacent and co-channel interference in crowded public areas (stadium, arenas, shopping malls, airports, etc.) or residential areas (neighbours’ AP, microwave ovens, cordless phones, Bluetooth devices, etc.) should also be considered as another source of interferences.

Low Signal Levels

In an environment with variable levels of signal strengths and not optimal coverage, you could see a higher amount of retries. This is especially true in modern Wi-Fi networks as disabling lower data rates is now common practice. The problem is that having a lower signal strength might not be enough to be able to decode the lowest configured data rates, generating retransmissions.

To avoid these problems, a proper Wi-Fi design can be put in place.

Post by Amin Sedighfar

Notify of
Oldest Most Voted
Inline Feedbacks
View all comments

Thanks François for your post! Personally, I use another Wireshark feature to calculate the retry rate. It’s called “Wireless>>WLAN traffic.” The advantage is that you can obtain the retry rate without performing any calculations. Simply use the filter to filter out the traffic you want to examine. In a simple case, the filter could be wlan.addr == <CLIENT_MAC> && wlan.fc.type == 2. An additional bonus feature of this method is the ability to calculate the retry rate for all clients connected to the same BSSID. To do this, use the BSSID as the filter, like wlan.addr == <BSSID> && wlan.fc.type == 2.
Sometimes, it is very helpful to look deeper into the retry statistics. For better understanding of a problem, I use a filter such as wlan.fc.type_subtype == 40 instead of wlan.fc.type == 2. This allows me to focus on QoS Data frames only, filtering out data frames that are not essential for transmitting user information (for example null data frames)
Another useful feature is to differentiate between Upstream and Downstream by using filters like wlan.ta == <CLIENT_MAC> for Upstream and wlan.ra == <CLIENT_MAC> for Downstream. This differentiation helps in understanding the nature of retries.

Erick Martin

Great content! I appreciate the simplicity.