It had been several months since I updated the OpenWrt firmware on my router. I kept delaying the upgrade because of several personal issues which made me lose motivation to work on sysadmin stuff at home. I was using OpenWrt version 22.03.2, which was released back in October 2022, and the latest available version was 22.03.5, which was more than a month old at that point. I performed the last sysupgrade using the attended sysupgrade facility offered by OpenWrt, which had made my bespoke sysupgrade shell scripts obsolete. A few weeks ago, I decided that it was time to upgrade the OpenWrt firmware on my router. All I had to was enter "auc" in the busybox ash shell, confirm that I wanted to upgrade, wait for a custom firmware build from sysupgrade.openwrt.org, and let the sysupgrade happen. Shouldn't be a problem right? Well, not really.
auc/0.2.5-1 Failed to load attendedsysupgrade config Bad address (14)
A few minutes of searching the openwrt forums and git commits gave me the following configuration for auc:
$ cat /etc/config/attendedsysupgrade
config server 'server'
option url 'https://sysupgrade.openwrt.org'
config client 'client'
option upgrade_packages '1'
option auto_search '0'
option advanced_mode '0'
I'm not sure when this configuration file became necessary to use auc. Anyways, after creating this configuration file, auc finally worked and my router was upgraded. Unfortunately, a day after the upgrade, my 3rd gen iPhone SE stopped detecting my 5 GHz Wi-Fi SSID. I thought maybe it's just a random issue with my phone or my router and I restarted both of them but that didn't help. It was time to ssh into the router and check what was wrong.
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 22.03.5, r20134-5f15225c1e
-----------------------------------------------------
After I was inside my router, I checked the syslog and found these errors from hostapd:
DFS start_dfs_cac() failed, -1 Interface initialization failed wlan1: interface state DFS->DISABLED wlan1: AP-DISABLED
What's DFS? I have no idea. Let's find out.
A Wi-Fi router with the 802.11ac wireless networking standard works within the 5 GHz radio wave frequency range, also called the 5 GHz band. The values of this range might differ from one country to another. The exact values are available in a db.txt file in the wireless-regdb.git repository, which is available in the Linux kernel git tree.
db.txt file from wireless-regdb.git repository, commit ae1421f
I'm in India and our government has allowed usage of the 5 GHz band in the following frequency bands:
# iw reg get
global
country IN: DFS-UNSET
(2402 - 2482 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 30), (N/A)
(5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS
(5470 - 5725 @ 160), (N/A, 24), (0 ms), DFS
(5725 - 5875 @ 80), (N/A, 30), (N/A)
You'll notice how certain bands are marked as DFS, although we'll talk about that later.
These values can also be found in a circular from the Department of Telecom (DoT) in India.
The Circular from DoT about 5 GHz usage, the English text starts at page 6
The generation and transmission of radio waves in bands starting from 3 Hz and going all the way up to 3000 GHz are regulated by national laws. For example, the band between 3-30 Hz is used for communication by submarines. In the context of Wi-Fi, the bands in the output mentioned above are subdivided into channels, with the lowest channel width being 20 MHz. When using the legacy 802.11n Wi-Fi standard, we use 20 MHz channel width (and a 5 MHz buffer between each 20 MHz channel to prevent interference) to get three non-overlapping channels in the 2.4 GHz¹ band. Although you can try to use 40 MHz channel width when using 802.11n Wi-Fi, it probably won't work well because of certain "good neighbor" policy restrictions and because of how crowded the 2.4 GHz band already is.
The 802.11ac standard uses 80 MHz channel width in the 5 GHz frequency band, which gives us the following seven channels:
A Wi-Fi device will probably present a list of 20 MHz channels even when 802.11ac standard is in use. However, it's important to note that even if we select either one of channel 36, 40, 44, or 48, a Wi-Fi device will automatically choose the corresponding 80 MHz channel, channel 42. This is one of the 80 MHz channels that is unencumbered by DFS restrictions, the other one being channel 155. Although the 802.11ac standard also presents optional support for 160 MHz channel width, the three channels (50, 114, 163) that we get using this channel width are either encumbered by DFS (50 and 114) or not well supported by all devices (163).
It's interesting to realize that radio waves aren't just used for Wi-Fi devices at our home and offices. If we restrict ourselves to the 5 GHz band, modern radars, communication satellites, and weather systems also use the same band. It's not prudent for Wi-Fi devices at home to interfere with these government radio wave transmissions, which is why Wi-Fi devices are required to implement DFS, a feature that forces Wi-Fi devices to detect any radar transmissions on the channel they're using and if found, switch to a different channel to avoid them.
For better or worse, not all Wi-Fi devices support use of DFS channels. If the firmware on a Wi-Fi device doesn't support using DFS channels, we're restricted to using only two 80 MHz channels, 42 and 155. A new 80 MHz channel, 171, was introduced by the FCC in 2019 but Wi-Fi devices and clients may not support using it. The same goes for the 160 MHz channel 163. To confirm if a Wi-Fi device supports DFS channels out of the box, visit WikiDevi, get the FCC ID of a device, and then visit the FCC website to list the frequency bands which the device is licensed for. If a Wi-Fi device supports DFS frequency bands, it'll also have a test report for DFS, which will mention if the device can serve as a router (master) and/or a client (slave). For example, here are the relevant links for the Linksys WRT32X Wi-Fi router.
The WikiDevi page for Linksys WRT32X, FCC ID "Q87-WRT3200ACM"
The FCCID.IO page for Linksys WRT32X, check the operating frequencies section
The Linksys WRT32X Wi-Fi router seems to have support for all the DFS channels. However, the Netgear R7800 doesn't, which limits this router to only two channels in the 5 GHz band. Fortunately, it seems that if we flash an open source firmware like OpenWrt on the Netgear R7800, it gets support for using DFS channels as well. Unfortunately, it looks like either I'm doing something wrong or OpenWrt might be buggy on MediaTek MT7615N Wi-Fi chips because it doesn't fallback to non-DFS channels when a radar transmission is detected on a DFS channel.
Even if a Wi-Fi device supports using DFS channels, it may not be able to use them because if radar transmissions are detected, the Wi-Fi device will fall back to channel 42 or 155. From what I've read, Wi-Fi 6 (802.11ax) isn't a significant improvement over Wi-Fi 5 (802.11ac). Wi-Fi 6E is pretty new as on August 2023 and not all clients support it. The significant change in 6E is the addition of 1200 MHz (5925-7125 MHz) of frequency range, although it's already encumbered by "point-to-point microwave links and some fixed satellite systems" according to an FCC document.
FCC document on the 6 GHz band
I would suggest sticking to a non-Broadcom² Wi-Fi router that supports 802.11n and 802.11ac with 4x4 MU-MIMO which supports using all DFS channels.
---
¹ Apparently, 802.11n can also operate in the 5 GHz band using 20 MHz and 40 MHz channel widths.
² Broadcom Wi-Fi chips don't have FOSS drivers so they don't work with OpenWrt
---
Updated: 2023-08-03
Created: 2023-07-31