When using the EtherScope™ nXG to analyze WiFi traffic, one of the things you may notice is “Retries.” In this tech tip, we are going to go through what they are, what causes them, and how they look in Wireshark, when captured.
Each time a WiFi device transmits a data frame, it must receive an acknowledgment from the receiving device. Unlike wired networks, which assume that every frame is received successfully, 802.11 networks require that the receiver acknowledge the successful receipt of the frame. If the transmitter does not receive an acknowledgment for the data frame, it will retransmit the frame. By default, the transmitter will attempt to retransmit the frame 7 times before giving up and allowing one of the upper layer protocols to retransmit.
In most cases, these unacknowledged frames are the result of interference in the 2.4 GHz and 5 GHz bands. When the frame is received, the CRC contained in the frame does not match the CRC calculated by the receiver and the frame is discarded.
The RF and Traffic Statistics section of the EtherScope™ nXG provides a per-channel view of the key WiFi statistics. Included in this is a graphical representation of the precent of retries observed by the EtherScope® nXG. The graph above shows the retries when running an iPerf test between an AirCheck® G2 and a Test Accessory.
The packet capture app on the EtherScope™ nXG was used to capture the traffic between the AirCheck® G2 and the Test Accessory. Let’s take a look at some of that traffic to get a better idea of what happens when a WiFi frame is resent.
Above is a portion of the capture file, displayed in Wireshark. Frame 11690 contains the initial frame sent by the AirCheck® G2. This frame is sent at 52 Mbps. When it does not receive an acknowledgment from the access point, it retransmits the frame and sets the Retry Bit in the Frame Control Flags field.
Having still not received an acknowledgment, it tries again in frame number 11696. This time it reduces the data rate to 26 Mbps. The idea is that by reducing the data rate, the frame is more likely to make it successfully to the receiver. This is unsuccessful. After two more attempts and reducing the data rate to 13 Mbps, the access point finally acknowledges the data frame.
The time between when the initial frame was transmitted and the acknowledgment is 6.32 milliseconds. Something that should have taken only microseconds, ended up taking milliseconds. When this occurs over and over again, the overall throughput goes down and congestion on the channel goes up.
To view retry frames in Wireshark, use the following filter:
wlan.fc.retry==1
Causes of high retries include:
- Non-802.11 Interference
- Weak Signal
- Adjacent Channel Interference
- Transmit Power Mismatch
- Lower Speeds Disabled
- Hidden Nodes
When addressing the possible causes, be sure to change one thing at a time. Monitor the retry rates for the channel after the change to determine the impact of the change on the retry rates. While retries are a normal part of WiFi operation, excessive retries will lead to lower data rates and poor network performance.