I don't quite understand the benefit of the setup. If there are legacy IoT devices that need unique named 2.4G network, just broadcast another SSID for them. So each router broadcasts main 5G (common name, fast roam etc), main 2.4G (same as above) and legacy IoT 2.4G (with a different name for each AP, and possibly worse encryption and maybe even TKIP). That wouldn't hold back the network for legacy devices.
I run a single ssid dual band network ... what tends to happen is 5Ghz is effectively ignored. 2.4Ghz has better coverage, so everything wants to live there. At least wifi 6 brought improved encoding to 2.4Ghz.
I haven't had luck with the roaming extensions; when I run them, some of my devices won't connect or won't stay connected and it's a pain to monitor. I guess I could run a different SSID with roaming enhancement, but effort.
My workaround for part of that is using many SSIDs.
A. The SSID that covers both bands, in all areas
B. Two more SSIDs, one for each band -- again, used in all areas
C. Another SSID just for the AP in the garage (which also has A and B SSIDs)
It has some advantages: I like being able to set a portable device to SSID A. These things usually figure it out well-enough while moving around. When someone visits and asks for wifi access, I give them SSID A. It works; it's just not always perfectly ideal.
It also prevents fixed devices in the garage from deciding to use APs in the house; it never works well for them when that happens. (The opposite problem hasn't been observed to be an issue yet.)
And it lets me decide whether any device is able to use 2.4 or 5GHz, in the usual way of having per-band SSIDs. If my TV streamer weren't plugged in with ethernet, then I'd set it to use the 5GHz-only SSID.
---
A big downside is that it's ugly. Another is that the per-device config is spread out amongst all of the devices instead of centralized, but that's not so bad: I just make the SSID decision at initial device setup and forget about it.
Previously, I've never thought much about the airtime required for beacon transmission, nor that it increases as SSIDs are added.
Thinking about it now, I can see some ways to improve the cost of these SSIDs.
Like, increasing the minimum speed/excise old protocols (I probably don't need 1Mbps 802.11b at all in 2026 and can't think of any strictly 802.11b-only device that I've ever owned) to decrease the time that beacons use.
That seems like one obvious improvement that should be is free of other tradeoffs.
There's a few other things I can think of, but I'm not done thinking about it yet. :)
This used to be pretty common on at least Linux and Android clients some years ago.
Not sure if they finally got around to making the BSSID selection algorithm a bit smarter or whether all my access points just support active steering at this point, but I haven't seen this in the past couple of years.
> I run a single ssid dual band network ... what tends to happen is 5Ghz is effectively ignored. 2.4Ghz has better coverage, so everything wants to live there.
That hasn't been my experience at all. Checking my current network status, I've got 24 devices connected to 5GHz and only two devices (my two Nest Doorbells, for whatever reason) connected to 2.4GHz that also supports 5GHz.
Yeah, though the anecdotes are a bit different... N=1 of a network not working was already provided by the parent, N=1 of bands working shows that it's at least possible for it to work more nicely.
