Standalone Ruckus 7982 Connectivity Issues

[daniel_m]

For home use I have a single Ruckus 7982 AP running in standalone mode on firmware 100.1.0.0.194.  I also have a single Meraki MR18 AP.  Connectivity to the Meraki is generally more reliable than the Ruckus—on rare occasions some of my mainstream devices will have issues connecting—but I do have some non-mainstream devices that have a horrible time maintaining their connectivity to the Ruckus AP.

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.

Thank you.

[daniel_m]

Appreciate you taking the time to chime in John.  The RF environment in my home is not very congested.  While this might be reason alone not to use ChannelFly, I do like knowing that when the RF environment does change, it is dealt with and not something I need to do manually.  As for the channel hopping, it doesn’t happen often and/or aggressively and the log confirms this.  While I agree with you on 802.11h support, and many consumer class devices, particularly older ones, don’t support this, I haven’t seen them have much issue with rescanning and reconnecting.  That said, I’ll review this in greater detail and report back.

[john_d]

Yeah, I really like Channelfly too and also would rather not use it as a scapegoat for every connectivity issue.

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!

[eizens_putnins]

 Hello, Daniel,

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.  

[daniel_m]

Hey John,

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.

Hey Eizens,

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.)

[eizens_putnins]

Hi, Daniel,

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).