Introduction
It all started with people telling me that when they were gathered in a meeting room, everybody loses their connection to the Wi-Fi. This happened sporadically and everyone got disconnected at the same time. Obviously the AP and the Wi-Fi were thought of being the source of this problem, so I started my analysis.
After some digging and frame capturing, it showed that during the occurrence of this issue, no Wi-Fi frames were transmitted on that given channel for about 10 seconds, not even Beacon Frames.
As an example below a Wireshark IO Graph with all the Beacon Frames my sniffer received on that affected channel during the issue:
There was no logical explanation for me, so I started up Ekahau and the Sidekick to look at the RTFM (real time frequency monitor), and the following happening revealed itself:
As you can see, there is something that interferes with the Wi-Fi and jamms up the whole channel for about 10 seconds. Upon further investigation, it was noticeable that not the AP was the source of that interference, but one of the notebooks in the room.
Reproduce Issue
It seemed that the RF-Jamming was happening mostly after the notebooks were woken up from some power saving or hibernation modes. I looked for a way to reproduce it and was able to find the following process to do so 100% of the times:
Please note: During the RF-Jamming, the notebook reinitializes the Wi-Fi card (happens automatically) and reconnects to the Wi-Fi. After that, the issue does not occur any more when you start the speedtest again. It looks like the reason for this is that after the reinitialization, the notebook does not use TXOPs with CF-End frames any more (see section “Setup that causes issue” for more details).
But when you follow the steps above, you can reproduce it again.
Observe Issue
You can use different methods to observe the test above.
- Frame Capture next to the notebook that causes the RF jamming (see section “Introduction”)
- Spectrum Analysis next to the notebook that causes the RF jamming (see section “Introduction”)
- Ping from or to a client within the affected BSA (Basic Service Area)
- Check Eventlog from the notebook that is causing the issue. There is a Netwtw06 5007 Error “5007 – TX/CMD timeout (TfdQueue hanged) and a 10400 NDIS Warning that indicates that the Wi-Fi NIC got reinitiated.
Setup That Caused Issue
With a lot of “try and error”, I tried to narrow down the setup and combination of variables that causes this behaviour. Please note that this is based on my lab results with the equipment I had available, so your situation may vary (especially the part “Wi-Fi Specific Characteristics”). You are more than welcome to ping me with your results, and I will update this post accordingly.
Notebook Characteristics
- WiFi Card: Intel® Dual Band Wireless-AC 8265
- Driver Version: 20.50.0.X
Wi-Fi Specific Characteristics
- SSID with 802.11ac (VHT) capabilities
- Coding: BCC
- Notebook using TXOPs with CF-End Frames
Setup That Caused Issue
I found two ways to remedy this problem:
- Update Driver: The simplest way to solve this problem is to upgrade the Intel® Dual Band Wireless-AC 8265 to a version other than 20.50.0.X. However, if you have hundreds of clients with the faulty driver version, this might be a drag and needs proper planning and execution
- Switch coding to LDPC: An alternative solution I found working for myself is to switch the coding from BCC to LDPC on the AP/radio. Please note that LDPC is only an optional feature in the Wi-Fi Certified ac program (and Wi-Fi Certified n for that matter), so there might be clients that have issues with that.
As always, please don’t hesitate to hit me up if you have any questions or different results with this topic
Cheers, Renzo
