The non-mainstream devices, such as Windows 10 and BSD-based operating systems, routinely get disconnected from the Ruckus AP and also have a very hard time reestablishing their connections. On the other hand, I have zero issues with these same devices with the Meraki.
Since this is for home use, I have no support contract on the Ruckus and am looking to the community for support. I guess even if I did have a support contract Ruckus would simply say they don’t support these operating systems and move on. I also happen to abhor Ruckus’s policy of hiding extremely useful articles behind a paywall (see "Why would you see Island-SSIDs on Standalone APs" at https://forums.ruckuswireless.com/ruckuswireless/topics/why-would-you-see-island-ssids-on-standalone... for one of many examples where simple documentation is hidden behind a paywall), but it’s clear Ruckus favors recurring revenue over making certain their customers can effectively use their existing Ruckus hardware investments—so I’m not expecting this thread to get far, but I figured I’d try anyway. If you feel you can help, please let me know what information I can provide.
I would much rather prefer to keep the Ruckus—its beamforming does give it an edge—but if it doesn’t work when I need it to work, I can always give it to someone who requires less robust hardware and keep the Meraki.
- Channel width set to 20 MHz only
- Channel set static to 1, 6, or 11, and different from your other AP
- Transmit power set static (not auto)
- Channel width set to 20 MHz or 40 MHz
- Channel set static, and different from your other AP
- Transmit power set static (not auto)
Since you indicate that the problems tend to be with new OS devices like Windows 10, the Wi-Fi drivers on those devices may be buggy as well. One other thing you can try for stability is to disable beam steering on the Ruckus, have your SSIDs be different on the 2.4 GHz and 5 GHz band, and see if your devices maintain their connection.
This is normal behavior for ChannelFly, and while the amount of channel hopping does settle down after a few days, it will still happen. This is normal behavior for ChannelFly -- whenever a channel dynamically deteriorates, the AP will select a better channel. In a noisy/crowded environment, there's no such thing as a static optimal channel. The best channel depends on what the current situation looks like -- ChannelFly just picks channels that have statistically performed well until it finds one that it verifies to perform well.
Some clients (especially ones without support for 802.11h Channel Switch Announcements) will time out, disconnect, and reconnect on every hop, which can be very disruptive and explain the behavior you are seeing. Also, they tend to attempt to reconnect to the AP on the wrong channel, or by the time they scan and try to associate, the AP has hopped away again. There are a few mitigations to this:
If you really want to keep ChannelFly, you can try tweaking the MTBC (mean time between change) with the "set channelfly mtbc" command. I find that the name is a bit of a misnomer -- even with MTBC settings of 1000 minutes, I can still see hopping on the order of once per hour.
If this is still no good, then you can manually run channelfly in start-stop mode -- Leave it on for an hour or two upon reboot or upon having RF issues, and then statically assign the best channel it has picked.
If only one band is bad, you can try using ChannelFly on, say, 2.4 and leave 5GHz alone. Generally the DFS channels in 5GHz are pretty clean.
I would suggest looking for recent ChannelFly changes when clients have connectivity issues, or try just running a few days without it. It's also worth looking for re associations after a channel change and whether or not more than a few seconds pass after a channel change before your problematic client connect back.
I find that when ChannelFly does the rapid A -> B -> A transitions is when my clients struggle. Even ones advertised with CSA support.
Good luck with your investigations and keep us posted!
If you have reasonable connectivity with Meraki AP (which are failing meserably in case of any busy RF conditions), you obviosly have rather clean RF conditions.
And even more as you are happy with Meraki, you are not using a lot of bandwidth too (as throughput with Meraki is at the best 2x lower than with Ruckus in most conditions).
So the only issue to fix is client disconnects, as if clients stay connected to ZF7982 performance will be better than with Meraki anyway.
Reason of disconnections is most probably ChannelFly -- channel changes result in often clients reconnect, it provides improvement for clients which are happy to use it, but I have found that some clients fail with it with same behaviour you described: disconnect and remain disconnected until you reset Wi-Fi adapter.
So I would recommend to disable ChannelFly (in clean RF conditions you actually don't need it anyway).
After disabling Channelfly you'll probably don't have this disconnection issues, standard background scanning will be used (same as for example Meraki uses), so you don't need to do anything manually, and, of cause, you'll see that there is a anyway diference between the best Wi-Fi AP and Meraki.
If after this you still have problems, next thing is to enable only channels 1/6/11 -- I have found that some devices (including not updated iOS devices, some non-mainstream phones and some USA origin devices between others) have problems connecting to AP working on different than 1/6/11 channels. Test both changes separately, and you'll know what your devices can't tolerate. Usually there are 1-5% clients having such issues on the network, so for public network they are often sactrificed to get more bandwidth for others. But sometimes it is not the option, that you have to disable or tune features in question.
Sometimes some client devices have wrong country settings and this can affect connectivity too.
Ruckus (as other entreprise solutions) has a lot of additional features to improve performance, same unfortunately advanced improvements never can be compatible with everything om market, so in some cases you have to disable some features (enabled by default) to support buggy clients you have (and can't replace).
In such cases you may see that basic equipment, having no such improvements, in some cases cases client may work better with tp-Link UP than with neterprise AP in default config.
Also you comments about "paywall" and Ruckus support service sound a bit surprising -- you like Meraki so much, but without paid subscription Meraki AP is just a brick or paperweight. And support from Ruckus is actually excellent, as well as community support is closely backed by Ruckus engineers.
You actually have received this 2 answers already from John, but instead of testing proposed solutions you try to demonstrate how you don't like Ruckus service policy. But if you don't want to change configuration of AP to make system work with your clients, nobody will be able to help you.
It does appear ChannelFly is the culprit—what a shame—and most of my ChannelFly transitions are of the A -> B -> A variety and this tends to happen in less than 30 seconds. I will see what I can do to my non-mainstream devices as I’d rather not disable ChannelFly if possible. Thanks again.
I appreciate you taking the time to chime in. While I haven’t seen issues with the various 2.4GHz channels, I have seen issues with the 5GHz ones with some clients (for example, some clients hate DFS channels) and have blacklisted several of them for quite some time. As for Meraki, I clearly mentioned I preferred the Ruckus hardware, but I still feel Ruckus’s policy of hiding much of their simple articles/documentation is detrimental to their product (for what it’s worth, it appears Ruckus pulled the article I referenced in my original post shortly after I referenced it.)
It is normal practice for enterprise vendors to provide documentation only for registered users. It is same for Cisco, HP, Alcatel-Lucent and more. It is different for SOHO market vendors, but they have not much documentation ro provide anyway. If you have any Ruckus hardware, you can register for free and have access to the most things, even to software for standalone APs.
It is also logical that paying customers must have some benefits - if you would pay for support, you probably would feel same way.
Also, I never undesratood why people like to enable enhanced features, even if they don't need them in they instalation, and they create problems for them...
As you have clear RF situation, and light traffic, you can disable Channell-fly without loosing ay performance really. So I would do it and not waist any time configuring clients (which probably will not be successfull anyway).