Friday, 4 January 2019

The Windows WMM User Priority Issue - A Fix?

There is a known issue with Windows clients when it comes to marking applications for QoS over wireless. In short, even if a Windows client application is configured to use DSCP 46 (EF), for example to mark voice traffic, it will translate this over the air to to use a layer 2 UP value of 5, rather than 6. This means that it will end up in the Video WMM queue rather than the Voice queue that we’d like. This has an impact on traffic prioritization over the air and could have a negative impact on our high priority traffic. This has been an issue that people have just “lived with” for quite a while, but I suspect there is a solution to this issue. I’m “putting this out there” for feedback as I can’t find any information about others using this technique. I’d like feedback from my peers to understand if the approach is viable or anyone else has used/tried it

Background

Generally in my articles, I like to provide plenty of background information about a topic to encourage others to research and learn. But, in this instance, I’ll get straight to the point as there is too much ground to cover. If you’d like to know more about this topic, then please have a look at the following references:

The issue is shown on slide 47 of the presentation from Cisco Live referenced above:


As you can see, Microsoft translate the 3 most significant bits of the DCSP value in to a UP value of 5, which means that packets that are correctly marked with DCSP for EF end up in the WMM video queue, rather than the voice queue. The slide below (also borrowed from the same presentation) demonstrates the point (hopefully my friends at Cisco will excuse this liberty I'm taking with their content):



This means that both voice and video traffic (marked with DSCP 46 and 34 respectively) end up in the same WMM queue over the air from the client to an access point. Ideally, we want traffic marked with DSCP 46 to end up in the WMM voice queue and traffic marked with DSCP 34 to end up in the WMM video queue. But, this doesn’t happen by default when assigning QoS marking via the group policy editor

QoS Marking Tests


Application Marking With Group Policy Editor


The traditional method of marking applications with QoS is to use the Windows group policy editor. I 'll run through a basic example to show the process and result. However, note that the settings shown are definitely not what you would use in production. I’ll mark all Skype traffic from my laptop to send with DSCP value 46. In the real world, voice, video signalling etc. would be marked individually, so don't take this as a config to use in the real world.

I’ll then make a test voice call and capture a data frame that contains a Skype packet. I’ll also use an open SSID so that we can see both layer 2 & layer 3 decodes.

Here is the policy in the Group Policy Editor, showing the QoS policy:


Here is the resulting Skype packet showing the layer 2 priority 5 marking, together with the layer 3 DSCP marked (as expected) with EF. As mentioned previously, note that the layer 2 marking is using UP 5, so will be using the video WMM queue over the air, rather than the voice WMM queue we’d like to use:



Application Marking With Powershell


Ok, now to get to point of this blog article…

If we repeat the previous exercise, but this time set the QoS policy via Powershell, we can actually specify the layer 2 QoS marking that we actually want (i.e. set it to 6).

This is achieved by using the command “New-NetQosPolicy” in a Powershell console on your Windows laptop. Note that you need to run the command in a Powershell console opened as an administrator.


Note that we have now removed our original QoS Policy applied via the  Group Policy Editor (see screenshot above)

Here is the syntax required, together with a screenshot of the command being applied in Powershell:

New-NetQosPolicy -Name "Skype" -AppPathNameMatchCondition "Skype.exe" -DSCPAction 46 -PriorityValue8021Action 6



One point to note here is that when applying policy by this method, it is not shown in the policy configuration of the Group Policy Editor.The only way to check the applied QoS policy is to the use the “Get-NetQosPolicy” in a Powershell console on the Windows machine.

Now, if we look at the Skype packets from my laptop during a test call, we see that layer 3 is still marked with EF, as expected, but layer 2 is now marked with UP 6. This means that our traffic will use the correct WMM queue (i.e. the voice queue) over the air.



Using the correct WMM queue will ensure that our voice traffic can leverage the additional advantage in ECDA that this provides, which could be quite important on a busy wireless network carrying a mix of voice, video & data.

Questions


OK, this seems to be a reasonable approach to technically achieve the desired outcome for improved QoS marking over the air for Microsoft Windows clients. However, I don’t see anyone recommending this approach…

So, my questions are:

  • Is this a valid approach? 
  • Has anyone else used this approach? 
  • What are the pitfalls of this approach (if any)? 
  • Are there any flaws in my logic here? It seem strange that I don't find any information anywhere about this

Just a couple of caveats:

  • I’ve only tried this on my personal WIndows 10 machine that runs Win 10 Pro 
  • I’ve no idea if this approach would be scalable or supportable in a large Enterprise environment
  • I’m not a Windows or AD “Expert”

Please...let me know your thoughts (comments section at the bottom of this blog page, or track me down on Twitter - @wifinigel)

References


List of references from article & further reading:



Wednesday, 2 January 2019

WLANPiShark: Wireless Capture With a WLANPi on Windows


*** Note this article is out of date. Please use the information on this page until I get this artcile updated: https://github.com/WLAN-Pi/WLANPiShark2 ***

One huge advantage that Apple Mac users have over owners of Windows 10 machines is the ability to perform a native 802.11 wireless packet capture direct from their built-in wireless NIC. This is extremely useful for wireless pros who want to take a quick over-the air-capture into Wireshark to analyze traffic for troubleshooting purposes. Windows users don’t have the luxury of this native wireless capture capability. In this article, we take a look at how we can use a WLANPi unit as an adapter to capture traffic over the air, straight into Wireshark on a Windows machine. With the WLANPi being powered from the USB of the laptop, this is a super convenient, portable and powerful capture method that gets Windows users a little closer to the capabilities of their cousins on Apple Macs.

Background


I’ve always felt really bad for Windows users who want to use their laptop for wireless packet capture purposes. I’ve been a long time Windows user and have often looked at how I might best use my Windows laptop to capture 802.11 frames over the air. This is a trivial exercise for Apple Mac users, as the native drivers on Macs allow their adapters to be put in to monitor mode and capture frames over the air. It’s been a goal of mine to find a low-cost solution to enable Windows users to be able to perform over the air captures. It was something I dreamed of the whole time I was studying for my CWAP in the days before I could afford a Mac!

Windows wireless NIC drivers, unfortunately, do not provide the required monitor mode capability to allow wireless packet capture. I’m guessing this is down to the huge variety of NICs that may be used by Windows devices. It simply isn’t worth the development costs for NIC manufacturers to code in the capability for their wireless NIC drivers to support monitor mode (as most users will never need it!). There are one or two software companies that provide specialist NIC drivers that they have developed for their own capture software for Windows, but these are only available with the purchase of specific packet capture software, which has a significant price tag.

There are a few lower cost software solutions that support Windows packet capture, but they rely on wireless NDIS drivers that have a number of compromises when capturing packets. I’m guessing this is because they aren’t operating directly at the NIC driver level. Limitations include the inability to select capture channel widths and limited/inaccurate RadioTap header information. These are OK(ish)...but they don’t provide the flexibility and depth of information I need to see for activities such as troubleshooting.

Earlier this year, I became interested in the “WLANPi “initiative started by Jerry Ola at the Phoenix 2018 WLAN Pros Conference. Jerry’s idea was to develop a single board computer platform equipped with a suite of free tools for wireless LAN pros to use in their testing and commissioning work. A number of excellent open source tools already exist, and were included in the distribution he created for the platform (find out more here). The WLANPi is a Linux-based (Debian), single board computer in the same vein as the Raspberry Pi, but is provided as a much smaller form factor. It also has low power requirements, so can be run from the USB port of a laptop. It has no onboard wireless adapter, but there is good driver support for the Comfast CF-912AC adapter, which is relatively low cost NIC that can be plugged in to the USB socket of the WLANPi. The WLANPi also has a Gig Ethernet port, which allows high speed data transfer between the WLANPi and a laptop. This combination of characteristics means that it can be used as a powerful wireless capture device, hooked up to a Windows laptop via its Ethernet port, and powered directly by the laptop’s USB port. Here is a picture to show you what it looks like. You can think of the WLANPi as a wireless adapter on steroids for your Windows laptop:



To allow the WLANPi to capture frames over the air, I have created a Windows batch file (a script file) that will set up the WLANPi to capture frames, then stream the capture over the Ethernet port of the WLANPi to a copy of Wireshark running on your laptop.

This might sound complicated, but trust me...after some initial setup, it’s really straightforward to use. Here is an overview diagram:



Quickstart Guide


For those of you in a bit of rush and who are comfortable with all of the concepts shown later in this article, here’s a very quick “get-you-going” setup guide. (For everyone else, I suggest you carry on to the next section of this article.)

  • Build/obtain a WLANPi with the latest image installed (unmodified) 
  • Plug in a Comfast CF-912AC adapter to a USB port on the WLANPi 
  • Install Wireshark on your Windows laptop - note the installation location 
  • Install Putty on your laptop (we need Plink which is installed along with Putty) - note its installation location 
  • Download the windows batch file from GitHub to your Windows laptop (use “Clone or Download” to download the zip archive) - https://github.com/wifinigel/WLANPiShark 
  • Place the WLANPiShark.bat file in a convenient directory on laptop (your home directory) 
  • Edit WLANPiShark.bat file with notepad to configure user-configurable variables 
  • Hook up the WLANPi to your laptop with a USB to microUSB cable (provides power) 
  • Hook up the WLANPi to your laptop with an Ethernet cable (streams capture data) 
    • Ethernet port of laptop must be set to use DHCP 
  • Wait for WLANPi display to show its 169.254.0.0/16 address - note this address for later (this may take around 30 secs to appear) 
  • Open Windows command shell (i.e. cmd), change to the directory where WLANPiShark.bat installed and type : WLANPiShark.bat -h (verify help screen shown) 
  • In the Windows command shell, start test capture with: WLANPiShark.bat -c 1 
  • You’re done...


What You’ll Need


You’re going to need a few component parts to get things set up to allow you to try out this packet capture method for yourself. If you’ve ever attended one of the WLAN Pro’s Conferences in the recent past, you may already already have most of these components. If not, I’ll give you a few pointers along the way.

WLANPi Hardware


To complete this exercise, you must have a WLANPi. These have been provided as part of the some the deep dive sessions at recent WLAN Pros conferences, so you may already be lucky enough to have one.

If you don’t have one, I’d advise you think about getting hold of one for a number of reasons: it comes packed with some useful free performance tools, it’s a great platform to practice your Linux and coding skills, and it will allow you to have a go at trying out various projects (such as the one in this article) that are being developed by enthusiasts in the WLAN community.

If you don’t have one, you have two options:

  • Buy one pre-built from the WLAN Pros store: https://www.wlanpros.com/shop/nanopi-neo2-kit-usb-nic/ 
  • Buy one direct from the supplier, but do the build and burning work yourself (full instructions on this site: http://www.wlanpi.com). Note that you will also need to buy a Comfast CF-912AC adapter and micro SD card reader if you use this option - the full parts list is available from WLANPi.com. (If you buy direct from the supplier, the platform is known as a NEO2, not a WLANPi)

Once you receive your WLANPi, ensure that it has the latest image from WLANPi.com installed. Some of the older images had NIC drivers issues, so go with the latest and greatest. Once installed, do not globally update the packages using ‘apt-get’ on the WLANPi CLI, as this may overwrite the install NIC drivers and stop things working as expected. I tend to just stick to the vanilla image as provided at WLANPi.com.

Windows 10 Laptop


I’m guessing you already have a Windows 10 laptop, otherwise you likely wouldn’t have got this far in your reading! I’ve only tested the batch file I created on Windows 10, so I’m not sure if this will work for any of you diehard Windows 7 users out there.

Software Packages


There are a couple of software packages you will need to install on your Windows laptop, if you don’t already have them:

Wireshark is our (free) packet capture and decode software, which hopefully needs no further explanation.

Putty is a free terminal emulation software that is used by many network engineers who want a robust, reliable piece of software to SSH to devices around their network. Putty software is installed with a number of supporting utilities. We are not interested in Putty itself, but in the accompanying utility: Plink. Plink allows us to send single commands to devices over an SSH session. You don’t need to install Plink separately - it is automatically installed as part of the standard Putty installation.

When installing Wireshark and Putty, make a note of the location in which they are installed. This will be useful to us later when configuring the batch file that ties everything together and performs the magic. If you already have both software packages installed you may need to use the search tools in Windows File Explorer, or poke about in some well known install locations such as “C:\Program Files\ or ”C:\Program Files (x86)” to find their installation location.

Networking


As we’ll be hooking up the Ethernet port of our laptop to the WLANPi, we need to configure the IP setup of our laptop Ethernet adapter. To keep things nice and simple, just set the laptop adapter to use DHCP - no static IP addressing is required.

The reason for doing this is that when connected to the WLANPi, it will fall back to using its RFC3927 address (169.254.0.0/16). The WLANPi will also do the same thing, so that they can communicate using their 169.254.0.0/16 addresses when directly connected. This keeps thing nice and simple and avoids having to keep configuring static addresses every time you need to use the WLANPi with your laptop.

Hooking it all Together


Once you’ve installed the required software on your Windows laptop, you’re ready to hook everything together.

To connect your laptop to the WLANPi, you’ll need 2 cables:

  • USB to micro-USB cable (supplied with the WLANPi) 
    • Connect this between your laptop USB port and the micro USB port of the WLANPi - this will power the WLANPi 
  • Standard Ethernet UTP cable 
    • Connect this between your laptop Ethernet port and the Ethernet port on the WLANPi

When the WLANPi is connected to the laptop, it will initially show a 127.0.0.1 address on its display. After 30 secs or so, it will fall back to a 169.254.x.x address, which will replace 127.0.0.1 on the WLANPi display.

Obtaining and Configuring the Batch File


The glue that pulls all of this together is a Windows batch file that I wrote that will automatically set up the WLANPi to start collecting data over its WLAN adapter, and then stream the captured data back to Wireshark on your laptop. Once you’ve got hold of the batch file, you need to do a one-time configuration exercise, then it’s good-to-go to run from the command line of your Windows laptop.

Lets step through what you need to do:

1. Get the Latest Batch File

Visit my Github repository and download the latest file archive that contains the batch file. If you go to the GitHub site and select “Clone or download”, then select the “Download Zip” option (see screenshot below)



You will then be prompted to download a zip archive which contains the batch file that you will need. Download the zip file to a suitable location on your laptop so that you can unzip it and access the files that it contains.

2. Extract the Batch File

Once you have downloaded the zip file, open Windows file explorer, right click on the downloaded file and hit the extract option - this will extract all files in the archive to a new directory.

There are several files included in the zip file that is downloaded. The only file we are interested in using is the file titled “WLANPiShark.bat”:



Using Windows file explorer, move the “WLANPiShark.bat” file to your home directory.To find your home directory, open up a Windows command shell and check out the directory path indicated before the command prompt (see below):



3. Configure the Batch File

The final step is to configure the batch file for your environment. Don’t worry, you should only need to do this once.

Using a plain text editor such as Notepad or (even better) Notepad++, open the WLANPiShark.bat file. (Sidenote: if you don’t already have Notepad++, get it. You can thank me later. There are so many things you can use it for.)

When you open the file, it can look a little overwhelming as there is a lot of stuff in there! Scroll down to around line 50 and you should see something that looks similar to this:



There are 6 variables that need to be configured. These are indicated by the “set” statements shown above. All that needs to be done is to edit the value shown after the “=” symbol with a value for your environment. Many of them likely won’t need changing if you have a default WLANPi setup. When making any edits, ensure that you don’t add any leading or trailing whitespace characters (yes, I got stuck for a long time trying to figure that out at one stage...)

Make sure you hit “Save” when you’ve made your edits!

Let’s take a look at each variable:
  • WLAN_PI_USER: this is the username used to login to your WLANPi via an SSH session. The default is “wlanpi”, so unless you’ve created new accounts on the WLANPi, you can leave this as-is. 
  • WLAN_PI_PWD: this is the password of the account name specified in the previous variable. Again, if you’ve left everything as default, this is also “wlanpi”. If you have changed the user account password from default, then put in the password value here. (Note: this could be a security worry for some people, but I don’t have a good workaround for this, sorry
  • WLAN_PI_IP: this is the IP address of the WLANPi itself. The IP address is shown on the display of the WLANPi. By default this will be a 169.254.x.x address unless you have previously assigned a static address to the WLANPi Ethernet adapter 
  • WIRESHARK.EXE: this is the full directory path to the Wireshark executable on your laptop - it must also include the Wireshark executable filename. Hopefully you made a note of this during installation.If not, you will need to find it using a tool such as Windows File Explorer 
  • PLINK: this is the full directory path to the Plink executable on your laptop - it must also include the Plink executable filename. Hopefully you made a note of this during the installation of Putty - it will be in the same directory as Putty. If not, you will need to find it using a tool such as Windows file Explorer 
  • WLAN_PI_IFACE: this is the name of the wireless LAN adapter interface on the WLANPi device. By default, if there is only one WLAN USB NIC attached, it will usually be “wlan0”. If you need to check this, simply SSH to your WLANPi and (with the WLAN adapter plugged in), run the command “sudo iwconfig” and inspect the output for the name of the WLAN interface: 



Testing


Assuming you have followed the instructions above, you should be good to go for a test to capture some frames over the air via your WLANPi and display them in Wireshark on your Windows laptop.

The required steps are:
  1. Open a command shell on your Windows laptop (i.e. Start > Cmd) 
  2. Type the following command at the command prompt: WLANPiShark.bat -c 1 
  3. Following a few status messages at the Windows command prompt, you should now see Wireshark open on your laptop and frames being captured on channel 1 (Note: the first time you do this, you may be prompted to accept a key at the Windows command prompt - accept this by hitting “y”. You will only prompted to do this once.
  4. When you have captured enough frames, use the usual Wireshark controls to stop your capture and perhaps save them off if you want to keep them

Here are a couple of screenshots showing typical output in the Windows command shell and the Wireshark capture window itself:





(want to know where all those crazy colours came from in the wireshark capture? See this article: http://wifinigel.blogspot.com/2014/02/wlan-packet-capture-frame-colorization.html)

Caveats & Limitations

As useful as this approach is, it has a few foibles and limitations of which you should be aware:

  • You should only use the latest WLANPi image from http://wlanpi.com. Don’t update the packages using “apt-get upgrade” as it will likely break the drivers supplied for the CF-912AC and break the capture capability.
  • Capture restrictions: 
    • Although the CF-912AC can capture 802.11ac frames, it can only capture 1 and 2 spatial stream fames. Data frames for 3 spatial stream devices will not be captured 
    • Capture is only possible for 20Mhz and 40Mhz width channels - this is a limitation of the ‘iw’ command in Linux (unless anyone has a clever work-around?) 
  • When installing Putty, remember that it is the Plink executable path you need to configure in the batch file, not Putty.exe 
  • This solution is bit clunky compared to native capture with an on-board adapter (though it is still quite powerful): 
    • It would probably be best written in another scripting language, but this adds another step of software to install to support that scripting language 
    • As ths is a Windows batch file, the CLI syntax checking is minimal. Check and double check the syntax you have used if you get strange results. It is easy to get Wireshark to fire up even though the entered CLI parameters are garbage. 
    • The batch file executes a number of remote commands on the WLANPi prior to firing up Wireshark. This means that there is a delay of a couple of seconds before Wireshark actually fires up. This could be possibly improved by adding a shell script on to the WLANPi itself, but I wanted to keep this as easy as possible to get going - hence I wrapped everything in to one file that runs on the Windows laptop 
  • Each time you need to do a capture, you have to run the batch file again - Wireshark does not run continually. You cannot just hit the stop/start button in Wireshark (sorry) 
  • In this article, I have shown how to run the capture using a direct Ethernet connection between the laptop and WLANPi. Obviously, by configuring IP addresses correctly, the laptop and WLANPi could be remote from each other. If you decide to try this approach, consider the bandwidth available between the laptop and the WLANPi and impact on other network infrastructure. Consider using the slicing option to keep the capture size down. 
  • Anything else you need is likely covered on the following GitHub page (inc full syntax and option details): https://github.com/wifinigel/WLANPiShark

References


Sunday, 27 May 2018

The 5GHz “Problem” For Wi-Fi Networks: DFS

Wi-Fi networking provides us with 2 bands for the operation of wireless LAN networks: the 2.4Ghz band and the 5GHz band. The 2.4GHz band has a reputation of being something of a “sewer” of a band, due to its limited number of usable channels, the number of Wi-Fi devices already using the band, and the high levels of non-Wi-Fi interference that it experiences. Many wireless LAN professionals will generally advise that you put your “important stuff” on the 5GHz band whenever possible. 5GHz has far more channels available, a corresponding lower number of devices per channel, and generally suffers much lower non-Wi-Fi interference. However, beneath the headline of “2.4Ghz = bad, 5Ghz = good”, there lurks a shadowy figure that can be troublesome if you’re not aware of its potential impact: DFS.

Background


Wi-Fi networks operate in areas of RF spectrum that require no licence to operate. This is in contrast to many other areas of the radio spectrum that generally require some form of (paid-for) licence to operate radio equipment.

All wireless services are generally subject to a range of enforceable technical restrictions to ensure they operate in a manner that will minimize interference to other wireless services. This may include restrictions on parameters such as RF transmit power levels and limiting the spectral characteristics of transmitted signals (e.g. channel widths used, spectral masks etc.).

Even though they may be licence-exempt, Wi-Fi networks are still subject to restrictions to minimize their impact on other wireless services and equipment in the same areas of spectrum used by WLANs.

One particular service that shares spectrum with wireless LANs is radar. Some types of radar installation operate in the 5GHz band that is used by Wi-Fi network. This means that they may use some of the same frequencies that are used for Wi-Fi networks. This doesn’t apply to all radar stations that have been deployed; there are many radar installations do not use 5GHz.

However, due to the coexistence of both radar and Wi-Fi networks in the same area of spectrum, the Wi-Fi standard (IEEE 802.11) was designed to incorporate a spectrum sharing mechanism on 5GHz to ensure that Wi-Fi networks do not operate on frequencies (hence causing interference) that are used by nearby radar stations. This mechanism is known as Dynamic Frequency Selection (DFS) and is designed to mitigate interference to 5GHz radar by WLANs.

How Does DFS Work?


DFS operation is as follows:

Channel Availability


Before an AP will use a channel that may be impacted by radar, it will perform a “Channel Availability Check” to check for radar signals on that channel. The AP will listen for 60 seconds for the presence of radar signals. If no radar is detected, then the channel is designated as being an “Available Channel”.

When powering up an AP that uses a DFS channel, you will see that the 2.4GHz radio becomes available as soon as the AP has completed its boot sequence, but the 5Ghz radio may not available for another minute. This is due to the AP performing its channel availability check, if the AP is trying to use a DFS-impacted 5GHz channel.

In some regions, where channels 120 – 128 are allowed for use by Wi-Fi networks, there may be an increased channel availability check of 10 minutes. This means that the 5GHz radio is not available until 10 minutes after the access point has booted up. This extended checking period is due to weather radar restrictions on those channels.

In-Service Monitoring


Once an AP is operating on a DFS channel, it has to monitor for the presence of radar signals appearing on that channel. This is known as “In-Service Monitoring”.

The AP must continuously monitor its channel for the presence of radar signals.
Channel Shutdown

If a radar signal is detected, then the AP must cease transmissions on the channel within the “Channel Move Time”, which is 10 seconds in the EU/UK.

At the end of this period, the AP will have ceased transmissions and moved to a new channel.

Prior to moving channels, some WLAN solutions may provide a “Channel Switch Announcement” 802.11 frame to connected clients to advise them which channel the AP will be moving to. Support for this on both WLAN infrastructure and client equipment seems to be optional from my own observations and should not be relied upon as a reliable method for clients to find the AP on its new channel.

Experience shows that there are variations between WLAN solutions around which channels an AP will choose to move to when radar is detected. In some solutions, APs that detect radar will move to channel 36 exclusively. In other solutions, APs will choose to move to any of the available non-DFS channels. Some will jump to any available 5GHz channel they find (DFS or non-DFS). Behaviour in this area seems to be inconsistent and is not defined within the 802.11 standard.

Non-Occupancy Period


Once radar has been detected on a channel, then the “Non-Occupancy Period” begins. This is a 30-minute period in which no further transmissions will be made by the AP on the affected channel.

At the end of the 30-minute period, most APs will attempt to return to their original channel, subject to a channel availability check. (Again behaviour in this area varies between vendors)

Radar Signal Characteristics


Radar signals themselves are very short duration pulses of Radio Frequency energy. In contrast to WLAN signals, they have no specific framing format, which makes their identification quite challenging.

Looking at the testing methodology in ETSI EN 301 893 V2.1.1 (Annex D), test pulses sent to WLAN gear under test may vary between 0.5 and 30 micro-seconds and be subject to a variety of test patterns. The table below is an extract from the document:



(Credit: Extract from ETSI standard: EN 301 893 V2.1.1)

The diagram below shows a single burst pattern that may be used to test WLAN devices:



(Credit: Extract from ETSI standard: EN 301 893 V2.1.1)

There is little doubt, that compared to the detection of well-structured, longer duration 802.11 frames, WLAN equipment has been set quite a challenge in reliably detecting radar signals (which can lead to annoying side-effects, discussed later).

Are All 5GHz Channels Subject to DFS?


No, not all channels in the 5GHz band are subject to DFS. The channels that are exempt vary from country to country, as dictated by local regulations. In the UK/EU, channels 36, 40, 44 and 48 are not subject to DFS. However, all remaining channels are subject to DFS. In the USA, channels 36 - 48, together with 149 - 165 are exempt from DFS operation, with all remaining channels requiring DFS operation. (Check your local spectrum regulation authority for the latest information for your country).

Channels that are not subject to DFS operate without having to perform any radar checks. Therefore, they are not subject to any disruptions from local radar equipment (or any other sources RF interference that may cause false-positive detection)

What Happens To Clients During a DFS Event?


Devices that are subject to DFS checks are divided in to two roles: master and slave. It is the role of the master device to advise slave devices when radar has been detected and that a channel shutdown is required.  In WLANs, the access point is usually the master device, with the associated clients designated as slaves.

Once radar is detected, it is the duty of the master device to advise the slaves that a channel change is imminent via a channel switch announcement message. This message should advise slaves (clients) which channel the AP intends to move to.

What Is The Impact on Client Applications During a DFS Event?


Once a radar signal has been detected, the impact on clients due to the required channel change is “variable”.

WLAN systems may or may not send a channel switch announcement (CSA). If no announcement is received by a client (or is lost in transit), then the client will be forced to go through its probing process to find a suitable BSSID with which to associate. Depending on the network configuration and client capabilities (e.g. 802.11k/v/r), the time to re-associate with the network will vary. Note that even if a CSA is received, a client may still choose to go through its own AP discovery process based on probing or 80.211k information it has received.

Once the move to a new channel has been completed, there will then be the usual delays in the resumption of application data flow due to processes such network access authentication and DHCP exchanges – these will again vary with network configuration.

Whatever the configuration of the WLAN and client capabilities, the move to a new channel will not be without some connectivity impact. This impact may be unnoticeable for users who are using non-real-time applications (e.g. mail, web browsing), but will certainly have an impact on latency sensitive, real-time applications (e.g. voice, video).


What Causes False DFS Detection?


Although DFS is, in theory, a great idea to protect systems that share the 5GHz spectrum, it has a major pitfall: false positives.

Detecting a radar signal signature is quite a tricky business. Due to the variety of radar signatures that may be detected, together with the short-duration nature of radar signals, false positive events may be quite frequent in some WLAN systems.

A false positive means that an AP is fooled into thinking that a radar signal is present by a non-radar RF signal. This causes a channel change, when one is not needed. This obviously leads to un-necessary WLAN disruption, that has varying impact on clients, depending on the applications in-use.

Theories around the exact cause of false positive events seem to be numerous, depending on who you speak with. I’ve heard the following possible causes cited:

  •  Transient conditions due to high densities of clients
  •  Bad client drivers causing short term RF spikes
  •  Co-channel interference from distant APs on the same channel
  •  Local non-Wi-Fi equipment interference

Whatever the cause, the false positives observed generally tend to be observed during times of increased user presence (i.e. they seem more likely during “office hours” as user numbers & activity increase).

How Do I Detect DFS Events?


To find out if your network is being impacted by DFS events, you need to check the trap logs or syslog messages from your wireless system.

All systems should report when a radar hit has been detected. This will generally be recorded in the logs of the AP, wireless controller or management system. Often this will be forwarded as an SNMP trap to a management system or perhaps as a syslog message to your logging server.
If you have log analysis and trending capabilities, it is well worth monitoring radar events to look for patterns of behaviour (e.g. particular sites, event times and channels)

What Do “Real” DFS Events Look Like?


You might be scratching your head at this point wondering how you can tell the difference between “real” DFS events and false positives.

In my experience, DFS events caused by genuine radar systems tend to be limited to a specific subset of channels on the 5GHz band. For instance, you may check your system logs and find that in a particular building, only channels 116 and 120 (for example) are reporting DFS events (i.e. radar hits). Also, these tend to be at a consistent rata throughout the day.

In contrast, false positives tend to be spread across a very wide portion of the 5GHz band and will vary in frequency throughout the day. They also generally fall to very low levels outside of office hours and at weekend (depending on the working patterns of your particular establishment).

How Can I Mitigate DFS Events on a Wi-Fi Network?


There are a few options available to try to mitigate the impact of DFS events on a WLAN:
  1. For genuine radar events that are impacting a subset of the 5GHz band, simply exclude the impacted channels from any channel planning. If using static channel planning, then avoid using affected channels. If using an auto-RF mechanism (i.e. automated channel planning), then exclude the affected channels from those available to the configuration of the auto-RF process
  2. Trying to mitigate false positives is a little more tricky. Options include:
    1. If you have sufficient non-DFS channels, do not use DFS channels at all in channel planning. This option is very much dependent on WLAN capacity requirements and the local regulatory domain in which the network operates
    2. Work with the WLAN vendor to find out if they have a more recent version of operating code that is less susceptible to DFS false positives. I have seen this approach used many times, with varying degrees of success
    3. Work with a vendor or VAR to try to identify any local sources of interference that may create false positives. Occasionally, it may be possible to identify a particular client type or item of non-Wi-Fi equipment that is causing false positives, If you have a support contract, assistance from a suitably qualified WLAN expert armed with a spectrum analyser and able to perform log analysis may be invaluable in tracking down offenders.
    4. If you vendor is unable to fix the issue, it may be worth trying an alternative vendor. Though this may seem extreme, I have seen huge variations between vendors and their susceptibility to DFS false positives. A limited-scope proof of concept costs little to deploy and can provide amazing leverage with your existing vendor…


What will be the impact of DFS on my Wi-Fi Network?


The impact of DFS events on your network (both “real” & false positive) will always be the same: a DFS event is detected and an AP will change channels. This will also cause the associated wireless clients to change channels.

The actual impact on the end-user will vary depending on what they are doing on their client.

Many applications that aren’t latency sensitive will simply continue with little obvious impact on service. If a user is browsing the web, sending email or even streaming a video file (assuming some buffering), they will generally not notice their client jump between channels as their associated AP changes channels. This assumes your WLAN is correctly designed so that clients have viable alternative APs available.

If clients are using real-time, latency sensitive applications, then they are much more likely to observe some sort of negative impact. The transition to a new channel is likely to be quite long (in WLAN terms). It will vary depending on the required operations (e.g. channel probing, 802.1X exchanges, DHCP exchanges etc.), but will generally be long enough to have an impact of real-time applications such a voice and real-time video. The use of enhanced WLAN features such as 802.11r/k may help to ensure that clients can significantly speed up the AP selection and roaming process.

These considerations provide a useful indication as to whether DFS events are going to provide problems on your WLAN and whether you should consider the impact of DFS on your wireless network.

Conclusion


In many Enterprise wireless WLANs, there will generally be a requirement to use as many unique 5GHz channels as possible. This provides opportunities to mitigate co-channel interference and increase capacity through the use of channel bonding (if required).

However, understanding and verifying the impact (if any) of radar detection is important to ensure the requirements of our WLAN design are not compromised.

References


Here are some other great sources of information you might like to look at for more information about DFS: