Things that irritate me about Wi-Fi
After a month of redesigning and redeploying Wi-Fi in my home office, I’ve come across some features of this wireless network that need improvement. Recent developments in the 802.11 standards have emphasized data transfer performance, which is fine as far as it goes, but the usability and security side of things needs work.
For all practical purposes, Wi-Fi reached its performance goal in 802.11ac, AKA Wi-Fi 5. By making 80 MHz channels available, it crossed the gigabit threshold long before gigabit throughput was available from most Internet services.
My testing revealed that 802.11ac stations could achieve download speed of 1.09 Gbps up to 50 feet from the access point (AP). Wi-Fi 7, based on 802.11be, offers a token improvement at this distance, 1.33 Gbps. Wi-Fi 7 is dramatically faster at 10 feet, 3 Gbps, but that figure isn’t terribly significant when we factor in the bottleneck speeds of typical broadband plans.
Wi-Fi is faster than the typical ISP
My 3rd generation iPad Pro is limited to 80 MHz channels although it’s ostensibly an 802.11ax device. It scores between 800 and 900 Mbps on Speedtest over an ultra-fast fiber (8 Gbps) broadband connection and a semi-enterprise Unifi Wi-Fi network. This is on the 5 GHz band.
A more recent iPhone 15 Pro Max with 6 GHz capability (Wi-Fi 6E) scores closer to 1.5 Gbps, well more than the typical broadband plan. A MacBook Air with 6E scores similarly. Apple likes 6 GHz but is not enthusiastic about Wi-Fi 7.
Moving on to Wi-Fi 7, an Acer laptop scores 2 Gbps 10 feet from the access point, using channel aggregation via the MLO feature that combines 5 and 6 GHz bands. Faster computers come closer to 3 Gbps.
Poor housekeeping in the 5 GHz band
Wi-Fi’s number one constraint is low quality IoT devices. Because it’s a shared spectrum system, one poorly designed device can drag the performance of the system down to its level.
Case in point is 5 GHz devices that don’t work on Dynamic Frequency Selection (DFS) channels. DFS channels take up 360 Mhz of the allocated 5 GHz band for unlicensed, while non-DFS channels only span 230 MHz.

To make matters worse, DFS channels 96-144 are contiguous, spanning 260 MHz, while the largest non-DFS region only spans 130 MHz, from 149-176. Applications that want to use 160 MHz channels in 5 GHz are forced to use DFS.
Dragging Wi-Fi down
DFS is a system that detects radar signals and disables Wi-Fi transmission on channels where radar is found. It’s a function of Wi-Fi access points (APs), AKA “routers,” but Wi-Fi client devices have a role to play.
When an AP discovers radar, it signals clients on the contaminated channel to stop transmitting immediately and to go to a different channel. Not all devices can do this, which means they fail FCC certification to operate over the DFS zone, known as UNII-2a and UNII-2c.
These devices require APs configured to only use non-DFS channels. In fact, they don’t even see APs broadcasting over DFS channels.
The state of play
Networks with a single AP have to exclude DFS for all devices if even one can’t pass FCC certification. Alternatively, they can deploy both DFS and non-DFS APs with different SSID network names.
Not all Wi-Fi systems allow this because it creates interference. DFS devices want to also use non-DFS spectrum: a 160 MHz channel centered on channel 50 spans both zones and is the only way to get two 160 MHz channels in the 5 gig band.
So the presence of a single non-DFS client drags down the Wi-Fi experience for everyone. Such devices typically support the 2.4 GHz band, which is less than ideal if they’re trying to do HD or UHD video.
Hidden information
Network administrators have to chose between degrading everyone’s experience a little bit by excluding DFS channels for their networks or degrading the experience of non-DFS devices a lot by exiling them to 2.4 GHz IoT land, the home of 50 cent Wi-Fi chips.
Vendors of non-DFS devices don’t make it easy for admins to be aware of their limitations. DFS support is now common among major vendors such as Amazon and Apple: Most Echo and Home Pod devices are on-board, as are the newer watches, phones, tablets, and laptops.
The major culprits today are video doorbells. Most of them don’t even pretend to support DFS, and one that does – Ring – excludes everything below channel 100.
This means Ring supports some but not all DFS channels. Google Wi-Fi uses a feature called “band steering” that tells the ring what band and channel to use, but typical dual-band bells, such as Ecobee, ignore these suggestion, leading to lack of connection.
Doorbells need a little more bandwidth than other IoT devices because they stream video, so the fashion among them is to offer dual-band solutions that are woefully incomplete.
Changing SSID and pre-shared key
I recently retired the naming scheme and password on my Wi-Fi network because I figured 10 years on one password was long enough. This meant going around to all my Wi-Fi devices – all 40 of them – and updating their Wi-Fi settings. Changing Wi-Fi parameters is not that big a deal for most IoT devices but for some it’s a nightmare.
The easiest one to change was in the Tuya Smart Life app, used by 350+ smaller Chinese companies for things like smart power strips and ceiling fans. It allows you to store multiple SSID/password combinations and to pick one as the default. Easy-peasy.
It also handles the Alexa, Google Home, and Home Assistant integration. iSmartgate was nearly as good, offering up a page where I could type in the new SSID and password.
I don’t know what happens if you make a typo, but I was careful. IOW, the better IoT devices – and a lot of pretty poor ones – allow users to update Wi-Fi parameters in their apps.
The bottom of the barrel
Ecobee thermostats are OK, putting up a pair of prompts and a virtual keyboard on the screen. By far the worst device in the whole world for Wi-Fi tweaking is the Ecobee doorbell cam.
On this device, you need to remove the cam from HomeKit, Alexa, and the thermostat. Then you have to factory reset the cam and go through a complete fresh install to get the Wi-Fi SSID/PW screen.
Then you need to pair it back with the thermostat and any smart home controllers you may have. I have to tweak their parameters because they’re too verbose by default, and it requires some guesswork to understand the parameters.
Given the low quality of the documentation for Ecobee’s dual band Wi-Fi implementation – and its DFS limitations – it’s often necessary to try a number of configurations to find the best one. This shortcoming deserves some attention from Ecobee’s marketing and engineering teams. You can cut corners on some things, but not on everything.
A system too complicated for the average consumer to administer
The first proto-Wi-Fi devices were designed in the late ’80s, when life was simple and IEEE 802 approved relatively untested modulation and coding schemes devised on napkins. This was how WaveLAN and Photolink got off the ground.
40 years later, we have an 802.11 standard with close to 60 amendments that’s a rich field for PhD dissertations. We’re on the fifth revision of the security standard and we still mostly rely on a shared key.
The spectrum allocation has gone from 75 MHz to 2000 by adding support for Unlicensed National Information Infrastructure (U-NII) spectrum, grouped as UNII-1 through UNII-8. The U-NII channels are full of national and regional exclusions and limitations that make it difficult to implement products that use them, as we’ve noted.
More spectrum isn’t always the answer
Understanding and managing the U-NII channels is a challenge for consumers as well as tech support agents. Enterprise networks are run by highly-trained engineers, but residential Wi-Fi is more or less and hit-or-miss proposition.
This all adds up to a less than ideal use of spectrum. If IoT devices could operate over DFS (and Transmit Power Control) channels, the pressure to open up 1,200 MHz around 6 GHz would be much less intense.
It’s downright disheartening to see companies that haven’t figured out how to use all of the 5 GHz range, UNII-1 through UNII-4, effectively demanding huge grants in 6 GHz from UNII-5 through UNII-8. Using upper U-NII effectively means consulting Automatic Frequency Coordination (AFC) databases as well as using dedicated sensing radios that are only just now emerging at the high end of the prosumer and enterprise markets.
Unifi only supports this combination in its $500 E7 access point and Omada is yet to introduce a competitive option. In a world where 50 MHz of licensed spectrum goes for $23 billion it’s bizarre to see Wi-Fi devices sneering at 360 MHz of DFS spectrum because “it’s just too complicated.”
Correcting bad incentives
Wi-Fi has issues with overblown marketing claims, inefficient spectrum use, basic housekeeping, security, and network administration. Companies aren’t likely to fix these issues on their own because they’re so widespread across the sector.
The Wi-Fi Alliance is complicit in the state of play because its certification process is too loose. The FCC adds to the problem by licensing such small chunks of spectrum.
When consumers buy a Wi-Fi product that claims to support the 5 GHz band, they have a right to expect it will function across the whole band. Otherwise, the vendor should prominently display a warning about the product’s limited functionality. The FCC and FTC can enforce this.
Consumers have a right to expect they can change passwords without a factory reset. They also have a right to expect security updates as time goes by. The WFA can and should make these things conditions of certification.
The Wi-Fi sector has probably ignored its issues because it has been too busy growing and making money. Its success shows that it can afford to improve. The whole spectrum ecosystem would be better off if it did.
