The practical advice is still worth acting on for people running configurable access points, mesh systems, or several SSIDs: inspect the 2.4 GHz minimum/basic data-rate settings, and remove 802.11b support only after confirming that older smart-home gear will remain connected. This is a legitimate Wi‑Fi tuning tool, not a universal speed switch.
The real setting is the basic-rate set
IEEE ratified 802.11b in 1999 as a 2.4 GHz extension capable of link rates up to 11 Mbps. Its familiar rate set — 1, 2, 5.5, and 11 Mbps — remains exposed in some router interfaces as 802.11b/g/n mixed mode, a legacy-rate list, or a minimum data-rate control.
Those labels describe related but not identical controls. A router can advertise old rates as supported without necessarily sending all management traffic at 1 Mbps. The performance consequence comes when a slow rate is part of the network’s basic-rate set — the rates clients must understand to join and interpret common network traffic.
Cisco’s wireless documentation is unusually explicit on this point: management frames use the lowest mandatory, or basic, rate. Cisco Meraki makes the same distinction in its minimum-bitrate guidance, noting that management, broadcast, and multicast transmissions use the lowest selected rate. That includes beacons, the small announcements an access point sends at regular intervals to tell devices that a network exists.
A 1 Mbps beacon occupies the shared channel much longer than a 12 Mbps beacon. Wi‑Fi is half-duplex: devices on a channel take turns transmitting, and each on-air transmission occupies time that no other client can use. Raising the basic rate therefore reduces the time consumed by recurring network housekeeping — but only on the radio and SSID configuration where that rate change actually applies.
The important correction is that this is a 2.4 GHz airtime issue. It does not directly accelerate a phone or laptop using 5 GHz or 6 GHz, and it does not repair an overloaded broadband connection, a poor mesh backhaul, weak signal, Bluetooth interference, or a crowded apartment building’s channel plan.
Why “most routers” is a claim nobody has demonstrated
MakeUseOf’s September 19 article says 802.11b backward compatibility is enabled on “most home routers.” The reporting does not provide a model survey, vendor default matrix, or packet captures establishing that broad claim. The available vendor documentation shows why the statement is plausible in some cases but cannot be treated as a universal fact.
TP-Link documentation for certain modem-router interfaces recommends an 802.11b/g/n mixed mode for widest compatibility. Netgear documentation also shows products and access points whose 2.4 GHz configuration is described as b/g/n. Asus router documentation still includes b/g protection settings. Those examples confirm that legacy compatibility has persisted in consumer equipment.
But a mode name is not a measurement of the active basic rate, nor does it establish the default behavior of current models across TP-Link, Netgear, Asus, Eero, Google, ISP-supplied gateways, and the growing number of Wi‑Fi 6E and Wi‑Fi 7 routers. Some consumer interfaces hide rate controls entirely; others choose their own default rates or alter behavior based on radio mode. A label such as “up to 600 Mbps” tells the buyer little about the beacon rate in a particular firmware release.
That missing detail matters because the claimed gain varies radically with the network. Cisco uses examples from dense enterprise deployments with multiple SSIDs, where slow beacons can consume a meaningful slice of airtime. A single home SSID with one access point emits far less management traffic than a six-SSID office floor. In many homes, changing a basic rate will be technically sound yet impossible to notice in a speed test.
The article’s strongest claim — that removing legacy rates “cleaned up” an observed drag — is a personal result, not independently reproduced testing. It may be entirely accurate for that UniFi installation, particularly if several access points or SSIDs were involved. It should not be read as evidence that every mixed-mode consumer router is silently bottlenecking its household.
An actual 802.11b client is the larger problem
The case for retiring old rates becomes stronger when a true 802.11b client is active. On an 802.11g-compatible 2.4 GHz network, old and newer modulation methods need coordination so that devices can share the channel without speaking over one another. This is commonly called ERP protection and can add control overhead.
Cisco’s small-business documentation says protection mechanisms are invoked automatically when legacy devices are within range. Its older Aironet material similarly explains that 802.11b clients can trigger protection behavior that reduces throughput for newer clients. In that circumstance, the legacy client is not merely benefiting from compatibility; it is changing how the shared radio operates.
That is different from the beacon-rate issue. Leaving 1 Mbps enabled can create low-rate management overhead even when no 802.11b-only device joins. Associating an actual 802.11b client can impose an additional protection penalty. Both effects exist, but they should not be blended into a promise that one slider will transform every slow Wi‑Fi network.
It is also worth remembering how rare a genuine 802.11b-only client is now. A surviving early-2000s laptop, handheld scanner, industrial controller, or specialty embedded device is more plausible than a current phone, PC, streaming box, or mainstream smart speaker. Modern equipment can still be slow on 2.4 GHz because of weak signal, interference, single-stream radios, or low-power chipsets without being 802.11b-only.
A cautious way to change the configuration
Administrators with access points that expose basic rates can make a reversible change. On UniFi, Meraki, Cisco, Aruba, and similarly advanced products, look for settings named minimum data rate, minimum bitrate, basic rates, legacy rates, or 2.4 GHz data-rate control. Consumer routers may instead offer a 2.4 GHz wireless mode such as b/g/n mixed, g/n mixed, or n/ax-only.
A reasonable sequence is:
- Start by documenting the existing 2.4 GHz mode and taking screenshots before changing it, because vendor interfaces use inconsistent names and a firmware update can move the control.
- If individual data rates are available, disable 1, 2, 5.5, and 11 Mbps only when there is no need to serve 802.11b clients; a 12 Mbps minimum is a common enterprise-style policy.
- Use 6 Mbps rather than 12 Mbps if the network has marginal coverage, distant IoT devices, or uncertain client compatibility, because it removes the 802.11b rates while retaining more reach than a 12 Mbps floor.
- Test every 2.4 GHz-dependent device after the change, including printers, plugs, sensors, cameras, thermostats, garage controllers, and older streaming hardware.
- Revert immediately if a device cannot reconnect, then isolate that device on a separate legacy-capable SSID or consider replacing it rather than weakening the primary network indefinitely.
The “6 Mbps is safer” advice deserves emphasis. Raising a minimum rate is also a coverage policy: it tells a weak-signal client that it must maintain a faster, more demanding connection or leave the network. That can improve roaming and reduce airtime consumed by edge-of-coverage clients, but it can also turn a previously usable garage sensor or backyard camera into a disconnected device.
Fix the higher-probability causes first
For most home networks, the larger 2.4 GHz wins are still mundane. Use 20 MHz channel width, avoid overlapping channels, and select among channels 1, 6, and 11 rather than treating every numbered channel as independent. Ubiquiti’s own optimization guidance recommends those non-overlapping 2.4 GHz channels, and Cisco Meraki cautions that 20 MHz is generally the safer 2.4 GHz choice for reliability and interference avoidance.
Devices capable of using 5 GHz should also be encouraged there, leaving 2.4 GHz for range-oriented and legacy clients. A wired backhaul for mesh nodes, better access-point placement, and fewer unnecessary SSIDs will usually produce a clearer improvement than a rate-policy adjustment alone.
The legacy-rate change belongs in that toolkit, particularly for enthusiasts and administrators who can verify what their access point is actually transmitting. It is not a substitute for diagnosis. Check the active band, signal level, channel utilization, neighboring networks, and client link rate before concluding that a 1 Mbps compatibility rate is the reason streaming buffers or a Windows laptop feels slow.
Removing 802.11b support is sensible housekeeping when the network has outgrown it. The concrete benefit is reclaimed 2.4 GHz airtime and a cleaner compatibility policy — not a guarantee that every Wi‑Fi problem in the house disappears when one old checkbox is cleared.