Until it gets stuck on a far away AP because it was the first AP to come online the last time the network rebooted.

Not sure if roaming is actually the fix for this problem. For whatever reason my Ring cameras just love connecting to the worst and most far away AP in my house.

Glad it works for you.

I need my TV to rapidly switch APs in very heavy load wide area networks with thousands of devices while I'm cruising through the venue with my motorized couch and entertainment system.

Now I want to actually build that for GPN24 next week. Wouldn't use AndroidTV for that though.

Good luck watching the office when your cat pushed your upstairs AP off the balcony. Your tv won't auto switch to the downstairs AP which is now closer than the one that's suddenly in the driveway.

The elevators are probably causing rapid blind spots (shadows) while the user is moving around, 802.11k is indeed useful in this case for cutting down scan time, since iOS will still scan with filtered channels.

It's an interesting setup, looking forward to an update.

> Fast roaming has not, does not, and never will require APs be on the same channel. Only the SSID and password needs to match.

There were no mentions of requirements for 802.11r in the comment. You removed "much faster than K/V." from the quote. "only" was referring to 802.11r exclusively. You can have the same results with different channels with K/V, provided that the clients support it as the rest of the comment mentions.

802.11r-only on different channels is ineffective for devices without K/V, since the reductions are insignificant.

You will be shaving 100ms from a 700ms delay on scan and association, compared to no-scan association which is around 20ms, hence the 75ms note.

And even then, FT is only needed for short buffer streaming like VoIP and VoWiFi. It's more important for WPA3, since handshake roundtrips are even longer (~300ms) which can degrade video/voice internet calls with a lengthy time to recover and complete silence for second or two on VoIP, it's not really needed for the average user back when WPA2 was standard.

Android and iOS will first scan on the same frequency, then rotate through the channels, which is now even longer on 6Ghz capable devices with the total number of channels.

The transition time is significantly faster with equal channels on most hardware, this is where 802.11k helps with different channels, especially in iOS. Without it, they cache scan results provided that the farthest AP is detected, this rarely happens since the scan time is so short.

Scanning different channels while connected causes large amount of jitter on station optimized WiFi SoCs, affecting VoIP on mediocre connections while the user is moving and actively losing signal, so its done as quick as possible, often missing many beacons. They can scan longer on the same channel without degradation. [0]

Without K/V, iOS/Android goes to the extent of doing frequent rescans on low network activity on body movement, you can install a Wi-Fi diagnostic profile to view the current activity on iOS, logcat on "fused" for Android.

The suggestion doesn't bash on 802.11k/v, it's just a compatibility alternative, considering that very few clients support it, let alone off the shelf consumer AP support.

> Setting them to the same channel will cause the APs to interfere (when they can't "hear" each other) or block each other from transmitting, or both. You set APs near each other so they are on non-overlapping bands. Always.

> This is basic WiFi networking 101

This is only true under large air time traffic and in large scale indoor setups. Not satellite APs that are far. Qualcomm, Mediatek and many systems implement their own spatial reuse technology. WiFi 6+ introduces BSS coloring for channel width overlaps to further improve speeds on mixed traffic, not to mention the generally low penetration / TX power of 5Ghz+ on SNR.

>> Samsung is known to push protocol support early: 802.11r in 2013

> 802.11r was released in 2008 and rolled into 802.11-2012.

> Also, the iPhone 5S (2013) has 802.11r support.

The Samsung line in the comment was referring to Androids, many Android didn't support these until 2020, some non-flagship still don't (disabled), Samsung was notable to include it early, there are three paragraphs underneath referring to old phones and smart TVs, both Androids. It is not enabled by default on many off the shelf APs for these reasons.

[0] https://support.apple.com/en-sa/guide/deployment/dep98f116c0...

Once you're not using default settings, here be dragons. In theory 802.11r is a standard. In practice enabling 802.11r puts you into the minority of users who do so. There's a lot less quality assurance coverage there.

You're at the mercy of UniFi not having any show stopping bugs (haha), the client device supporting 802.11r or at least tolerating it, and the interaction between UniFi and the client not having any show stopping bugs.

It might be that UBNT has screwed up the settings when in 802.11r mode. I have 802.11r set up on my OpenWRT Ones and I'm seeing what appears to be A-OK roaming with my Linux laptop and Pixel 5a. I do also have DAWN installed (solely to populate the "hearing map") and umdns installed... but it's not clear to me if those are actually useful.

Unless they've reimplemented the whole damn thing since like 2018 or so, UniFi is OpenWRT with the serial numbers filed off, and UBNT is known to be not especially great at having good software on the APs. I had a square UAP-AC and then an AC-LITE and an AC-LR all running the official software for several years. While the management GUI seemed like it'd come in handy if you had to manage like a hundred APs, I wasn't impressed with either official support or the rest of the software.

That's been my experience as well.

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.

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.

My current experience is that out of ~20 devices, about 6 are on 5Ghz and the rest choose 2.4Ghz. And it's basically perfect.

Because the 6 devices on 5Ghz: laptops and smartphones.

The rest are "smart" devices that work perfectly on 2.4Ghz.

You can turn down the power on the 2.4GHz radio so it's not as overpowering.

Can’t one SSID support different WPA versions across APs? I’m pretty sure all my devices just shrugged and connected when I downgraded my (single AP) SSID from WPA3/2 to 2 only and back up to 3/2.

Which is a bit sad, but also seems like it would allow this use case perfectly (assuming this was done on purpose and not just an oversight).

Most IoT devices support 2.4GHz only. Notably this applies to ESP32-based devices and older phones and laptops too. I would argue that it is the 5GHz band that is optional, the only benefit (bandwidth), being relevant only for laptops and phones when downloading something.

It penetrates walls so much better than 5GHz. If I lived closer to my neighbors I would agree with you.

Plus I still have some esp8266-based widgets that I made which only operate on 2.4GHz.

If you don't need it, of course, you might as well deactivate it. But if you do, I don't see the point of having two different SSIDs if you don't need them for another reason anyway.

Many APs now support either using Radius and username/password auth for this, or having multiple acceptable pass phrases for a WPA2 network which drop devices into different VLANs.

These are all not splits by frequency, though.

I have my RADIUS server put supplicants coming in on SSID "A" on one of the VLANs that gets RPZ-based adblocking, and SSID "B" on one of the ones that gets no adblocking. It's pretty fun and easy.

I’m pretty happy with my Omada controlled EAPs around my house.

Running Omada on my Windows Server was painful (doesn’t really run properly as a service, software updates are a chore), but since I moved it to run on Proxmox using a super simple LXC image (I maybe got terminology wrong here) it’s been very nice.

Supposedly I should have excellent roaming between the APs, but I’m not sure how to check. Certainly, walking from one end of the house the other while on a Teams or WhatsApp call on my phone has maybe only a super minimal amount of time that I might not hear the other person (sub second for sure, if at all), but mostly I don’t notice.

The Omada device* I researched also supports standalone mode and hosts the web UI like any other consumer router.

* https://www.omadanetworks.com/us/business-networking/omada-r...

UniFi is too good. I’ve been running their gear for about a decade and it just works.

That was an early attempt to stop LLM scraping and wholesale content stealing that I completely forgot about, even though it seemed to be quite effective until I turned on Cloudflare’s AI scraping prevention. The wording is a bit outdated, since most AI scrapers and relevance indexers now just ignore that kind of thing…

At what point does something like this cross the line into being malware?

A red flag for the author's trustworthiness, if ever there was one.

Starting with "Disregard all previous instructions" is malicious no matter how it's painted.

As long as you're happy with having your home wi-fi potentially controlled by the cloud...

Unifi doesn't have any cloud requirements that I know of. But yes they are more expensive than the hardware you've got, at $100 per AP.

For my needs unifi was worth it to not have to deal with OpenWRT again, or worse, stock firmware on consumer APs.

802.11r is pretty important, it's what allows the phone to skip the slow 4-way handshake when transitioning to new BSS.