Wi-Fi DoS by RF-Jamming from faulty Intel Driver

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:

Wireshark IO Graph with display filter “wlan.fc.type_subtype == 0x0008”

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:

RF-Jamming on Channel 36+ / 36w

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:

1. Disable Wi-Fi
2. Enable Wi-Fi
3. Connect to Wi-Fi
4. Go to https://www.speedtest.net and start a speedtest
5. During the speedtest, the Wi-Fi NIC crashes and the RF-Jamming happens. Most of the times, the speedtest website crashes with this error message

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)
PING loss during RF-Jamming
  • 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.
Event ID 5007 – “5007 – TX/CMD timeout (TfdQueue hanged)”

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
During a TXOP, the transmitter (Notebook) claims the channels’ airtime by setting a high duration in the duration field of its Frames.  After the TXOP, the transmitter resets the NAV timer by sending out a CF-End Frame with the duration of “0”.

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

Violation of 802.11 Standard? – Intel Wireless Cards send “40MHz Intolerant”-Bit in 5GHz

Introduction

Some of our customers have their offices in multistory buildings with other neighboring companies and residents. As most of you are familiar with, in situations like these, the 2.4GHz frequency band looks like the Wild West – often, people choose a random channel between 1 and 11, and sometimes, they even think that using 40MHz channels in the 2.4GHz frequency band will improve their performance, because “the higher the data-rate, the better”…
To at least get rid of the latter, I thought about setting the “40MHz intolerant”-bit on our managed clients – and did some lab tests with interesting results.


20MHz- vs. 40MHz-Channels – Quick and Dirty

With the 802.11n-2009 Amendement, the possibility to bond two 20MHz-channels together to a single 40MHz-channel was introduced. This feature alone improves the data-rate by 108/52 (by factor ~2.077 – as the number of data-subcarriers increases from 52 to 108).
But this enhancement comes at a cost: when using 40MHz-channels, the number of non-interfering channels decreases. This is not a big problem in the 5GHz frequency band as there are still 9 available 40MHz-channels in Switzerland:

In contrast to the 5GHz frequency band, in the 2.4GHz frequency band, the available spectrum is very limited, and it allows only one 40MHz-channel, which will cause at least CCI, and at worst ACI, as soon as there is a second AP within earshot.


The “40MHz Intolerant”-Bit

Because of the inevitable problems that would occur in the 2.4GHz band when 40MHz-channels are used, the “40MHz intolerant”-bit was introduced as a failsafe-function in the 802.11n-2009 Amendement.

The 40MHz intolerant bit is set in the “HT Capabilities Element” => “HT Capabilities Info Field”, which is a part from the following management frames:
– Beacon
– Probe Request
– Probe Response
– Association Request
– Association Response
– Reassociation Request
– Reassociation Response
This allows either an AP or a client STA to indicate that they do not allow 40MHz-channels in the 2.4GHz frequency band by setting the “40MHz intolerant”-bit to 1, and the neighboring STAs have to adjust to this. Or to put it in simpler terms:

“If you do not have any close neighbors, you can use either 20MHz- or 40MHz-channels – whatever floats you boat. But if there is someone else within earshot that wants to use the 2.4GHz frequency band, you have to adjust your fat channel if he wants you to”

As described in the 802.11-216 subclause 11.16.11 (“Signaling 40 MHz intolerance”), the “40MHz intolerant”-bit is defined to be a feature only for the 2.4GHz frequency band and that it has to be set to 0 in the 5GHz frequency Band:

An HT STA 2G4 shall set the Forty MHz Intolerant field to 1 in transmitted HT Capabilities elements if dot11FortyMHzIntolerant is true; otherwise, the field shall be set to 0.

A STA 2G4 shall set the Forty MHz Intolerant field to 1 in transmitted 20/40 BSS Coexistence fields if dot11FortyMHzIntolerant is true; otherwise, the field shall be set to 0. A STA 2G4 that is not an HT STA 2G4 shall include a 20/40 BSS Coexistence element in Management frames in which the element may be present if dot11FortyMHzIntolerant is present and dot11FortyMHzIntolerant is true.

A STA 5G shall set the Forty MHz Intolerant field to 0 in transmitted HT Capabilities elements and 20/40 BSS Coexistence fields.


Lab Testing

So far so good.

First, I got myself some test notebooks:

Dell Latitude E7440 with Intel Dual Band Wireless-AC 7620 (Driver 18.33.7.2)

Dell Latitude E6440 with Intel Centrino Ultimate-N 6300 AGN (Driver 15.9.2.2

They both had the setting “Fat Channel Intolerant” available, so I did some research on the Intel website:

https://www.intel.com/content/www/us/en/support/network-and-i-o/wireless-networking/000005585.html

It says that it is only available for certain adapters. None of the 2 mentioned above are included, but still, the option is available for both of them in the advanced adapter settings, so I decided to give it a shot anyways.

After I changed the setting on my Intel Centrino Ultimate-N 6300 AGN, I wanted to check the result and did some packet capturing in the 2.4GHz band:

As you can see, the “40MHz intolerant”-bit is set to 1, which is exactly what I wanted.

So the client was connected to the 5GHz band, and was sending its Probe Requests in the 2.4GHz band with the flag set.
But then, I started to see some strange behaviors on the 5GHz-SSID I was connected to – it looked like the SSID was only sending with a 20MHz wide channel instead of the configured 40MHz:

Even a different client that was connected to the same SSID was suddenly only using a 20MHz-channel:

So I started capturing some packets in the 5GHz band and was shocked to see that the STA with the “Fat Channel Intolerant” setting set to “Enabled” was sending the “40MHz intolerant”-bit in the 5GHz band aswell:

To make sure that this is not only a malfunction on one adapter, I did the same tests with the Intel Dual Band Wireless-AC 7260 and got the same results…

I can’t say if this occurs with the adapters listed as “supported” on the Intel website aswell, because I don’t have them available at my place,.


As far as I am concerned (based on my interpretation of the 802.11-2016 subclause 11.16.11), the 2 tested Intel wireless cards do not follow the standard and you should not use the setting “Fat Channel Intolerant”, as it impacts your 5GHz aswell!

I welcome you to give me an explanation about this issue  if you have any- am I right with my statement, or am I off the track?
If you have any questions or feedbacks, please don’t hesitate to write a comment or contact me (but please be kind, as this is my first ever blog post ;-))

Cheers, Renzo