A lot of people seem to be overlooking or are completely unaware of the primary flaw of AIMesh. While the loss of the second radio is infuriating and what brought me here as I run a 5300 for my primary and a RT68U as my secondary theirs no high-band radio for the secondary to use for a backhaul, so yes. Immediate loss of the 2nd 5Ghz on the 5300. WTF!?
However, the primary flaw is that in a good meshed roam-able network (like those you'd find in enterprises) NONE of the APs within range of each other use the same channel, there are several reasons for this.
* 2 APs on the same channel cause interference reducing performance, so partly they want to give as much bandwidth for as much clients as possible and the central controller assigns different channels either by manual config from the network engineer, or by automated config measuring signal levels.
* your devices have roaming algorithms that determine when to roam, sometimes assisted by the network sending specific control frames to trigger it and say "I think you'd be better served elsewhere" which causes the device to re-search for and join another AP (assisted roaming) and this happens really fast when a central controller is involved which is what AIMesh is attempting to do. However, in normal cases the signal gets to a specific threshold and your device looks for a closer AP on it's own. "Smart Connect" is essentially "Band Steering" and assists in pushing clients where the control system wants them to go using the assisted roaming.
In large systems that also have self-healing meshs they will use the second radio like ASUS is trying to do, but only if supported by all of the close by APs. And of course this is configurable, if you have a really reliable ethernet backhaul that also supplies POE to the AP, typically the signal itself is not going to drop if the AP has power, more than likely the whole AP gets cut/unplugged/no power. Therefore I usually to squeeze as much bandwidth as possible enable both 5Ghz radios and let them sort out which channel they want and you end up with non-channel overlapped aps, its not uncommon to be in a spot and see the Same SSID on 3 or 4 different 2.4Ghz channels and 6 to 8 5Ghz depending on the density. Then the channels get overlapped and re-used further away where the AP's cant see each other.
When enabled these mesh's will use a common channel to talk to each other for the backhaul. sometimes multiple APs will use the same channel. sometimes they will channel hop to talk to each neighbor independently. But 9 times out of 10, the wired backhaul is up on these APs and the mesh links are completely unused although some can be used for heavy traffic overflow when the ethernet is saturated in a busy area. And some of these APs have bonded ethernet or multi-gig ethernet (2.5Gb links are fairly new, not sure why they didnt go to 10Gb)
Anyway, whats my point? In any of those networks the client access radios are all on separate channels away from each other for smoother operation. What ASUS has done with AIMesh is created a half single-AP, half controller-based implementation that uses the multiple APs all on the same channel. Your device sends out a packet, it may be received by multiple APs in the mesh, so multiple copies can saturate your switches. Then the controller goes, "Oh, that devices is strongest on AP 2, I'm going to send responses there" but then the other AP's hear the response and have to discard the packet to not cause loops. Essentially a multi-receive single transmit type of system. Also if its local ant not going out one of your routers as a gateway, or you're using this as AP only and have a firewall. Your switch may be flapping back and forth with your devices MAC on your AP ports when it receives multiple copies, so the return traffic can be completely inconsistent as from what I can tell sniffing the network the traffic is not tunneled to the primary router (which is another method of enterprise wifi)
Roaming doesn't work very well in this setup at least in my experience as in a normal system you associate with an AP and only talk to that AP. The wired switch then learns your MAC address's port and by that what AP is talking to you and routes the packets appropriately. I have a switch in my garage and a 20Gbps backbone to my office where my primary router is... There have been numerous times that I turn on my phone, associate to the 5300 in my office, walk to the other end of the house where I should immediately hand off to my garage router, but because my phone still has enough signal to hold on to the 5300 it doesn't roam. But alas I'm too far away for good SNR and before it decides to roam, the traffic is being picked up by the garage, sent across the network, and the replies are still being broadcast from the 5300. How do I fix this? Remove the enterprise grade switch from the equation and run a dedicated wire between the 5300 and the 68U so that the switch doesnt get confused about where my device is. But if they would just let the 5300 and the 68U operate on independent channels, it'd likely fix this! And as others have said, where we don't have a tri-band secondary AP, but connected with Ethernet, just give us back our other band for client use! it's in the center of my house where most of my devices are!
By the way some poorly written device roaming algorithms don't use the signal level of the specific MAC you're connected to, but only the signal level of anything broadcasting that SSID on the same channel. I've had to correct manually configured enterprise networks to fix their channel layouts because of this.
I haven't played with any of the other new consumer mesh's out there, do they all use the same channel for access?
Man, I wish I could afford a real controller-based solution. Or even just UniFi, I just hate running Java for anything. This AIMesh has never worked properly and may just not be worth having as most of the time my secondary router just doesn't work and I have to reset my devices connection.