In addition to logging, I believe if you want hassle free roaming handoff between wifi APs you also need it running. It's been a while since I played with it since my setup is so rock-solid now (compared to when I had linksys gear...)
Wow...so do these APs actually hand off client based on proximity/signal strength? I'm running a home-grown network with four openwrt routers running the same SSID, but client stickiness is my biggest problem. I've always been told this was something you can't get around...that AP selection is left up to the client. However, clients do weird things...like a FireTV stick selecting an AP 100 ft away instead of the one sitting around 10 ft away. If Ubiquiti's solution solves this, I might seriously consider getting a set.
As an additional question assuming the above is true...can you bind different SSIDs to different VLANs? This is really the best value openwrt provides to me atm.
It does "work", but the beauty of it is subjective. Sure, if you have 10-20 devices it might work. More than that and it falls apart fast. But the reason is pretty simple - when you enable "Zero Handoff Roaming" you're making a huge compromise: 1) all UAP need to be on the same L2 network and 2) all UAP use the same channel. This doesn't work in any large scale deployment or deployment where you truly care about leveraging bandwidth via balancing clients based on channel utilization.
I've tried it (a long time ago) and yes it works. But, you will pay the price, even in your home network if you have clients doing large uploads / downloads. There's really no point since there's no logic with it either (the UAP devices don't influence handover / AP selection). If they did they could get around the limitation of being relegated to the same L2 network.
Also if you're using zero handoff you have old Ubiquiti gear (since none of the 802.11ac units ever supported it). Ubiquiti is likely moving to 802.11r to reimplement it. I wouldn't run Zero Handoff in my house with the APs I run even if it was an option (3 x UAP-AC Pro, 2 x UAP-AC Lite, 1 x UAP-N Pro).
I'm pretty sure that if you run ZHO you lose the ability to have the maximum number of SSID as well. Which is completely counterproductive from having a Ubiquiti system. I run 3 different SSID for different use cases with different security policy applied to each. One is also specifically for guests. The UniFi controller does captive portal and authentication for guests - so no having to give guests access to your entire network and you can restrict amount of time each code is valid for as well as the bandwidth a user is allocated.
I was not aware of this! I take it this hasn't changed in 2 years, has it.
I was looking to buy Ubiquiti gear to get away from failure-prone consumer all-in-one routers but not anymore. If they're sticking to this, it sincerely changes my plans as I can't support a company that so brazenly violates FLOSS licenses.
They can be meshed, but you need to set them up wired first. The UAP-AP is 2.4Ghz only, the UAP-AC-PRO also supports 5Ghz. The UAP-AC-LITE has fewer MIMO antennas but also supports 5Ghz.
Ha. My FireStick is the one device that can't get its shit together. It's about 6ft line-of-sight, hanging out the back of my receiver, to the Meraki 802.11ac AP on the wall above it.
Naturally, it insists on connecting to the AP 60 feet away down the hall and around a corner, and keeps insisting that "connection quality is poor."
Handoff is an overloaded term. If you advertise the same SSID on the same L2 network from multiple APs, clients should seamlessly move between those APs, subject to the client's own mechanism.
Ubiquiti has a feature called Zero-Handoff [1] which indeed requires the controller's participation. The APs all end up on the same RF channel in this arrangement. While I've not used this feature, multiple APs on the same channel tends to be a bad idea and I much prefer my setup of simply using the same SSID on multiple APs/channels.
In my experience, placing the same SSID across multiple APs/channels and letting the clients decide is a problem, because the clients often get it wrong. Granted, most of what I see this on are Android-based systems (FireTVs, android phones, etc), but I've also had the problem with Ring.com cameras, and with Amazon's Echo. I personally wish the APs would force the issue instead of relying on different client stacks.
The client is in the best position to manage the handoff because it knows which aps it can hear and is configured to connect to. I've seen some APs that will disconnect clients with low signals strength, but the AP doesn't know if the client can actually see something else. Zero handoff addresses this by having all APs listening to the same channel, with synchronized security parameters; whichever AP receives the packet gets to send replies. The down side is you end up with a larger coverage area but the same channel capacity as a single AP.
But they don't, really. I tried this with a Meraki security gateway+AP, plus a separate AP. Same subnet. Handoff between the gateway and separate AP took up to a minute.
Meraki insists you need to disable the wireless on the security gateway and ONLY use a "combined network" of APs to have the same SSID for roaming.
Granted, I know very little about how it actually works -- I think they use separate channels, unlike what folks here discuss for Ubiquiti.
I use zero handoff. proof is easy. connecting to a wifi L2 network for me takes ~ 500ms, i can unplug each station in turn and observe no loss of connectivity at all for that duration
note that unifi does not mention requiring controller running (and i do not have mine running ever and it works)
