Standalone Ruckus 7982 Connectivity Issues

  • 1
  • Question
  • Updated 2 years ago
  • Answered
  • (Edited)
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.
Photo of Daniel M

Daniel M

  • 43 Posts
  • 9 Reply Likes

Posted 2 years ago

  • 1
Photo of Jason Hintersteiner

Jason Hintersteiner

  • 10 Posts
  • 4 Reply Likes
Unusual that a Meraki would perform better than a Ruckus under any circumstances.   These types of problems are usually one of configuration.  Make sure you check your settings as follows:

2.4 GHz:
- 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)

5 GHz:
- 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.
Photo of Daniel M

Daniel M

  • 43 Posts
  • 9 Reply Likes
Hey John.  Thanks for the prompt reply.  On 2.4GHz my channels are 20MHz and 40MHz on 5GHz, but I am using SmartSelect and ChannelFly and transmit power is set to max for both radios.  I consider these features desirable—and the Meraki does similar—so I would rather not disable them and I consider not having/using these features a drawback if that’s the case.  Both APs are not overlapping on one another’s channels and I do not use beam steering/have separate SSIDs (though I’m actually using beam steering on the Meraki).
(Edited)
Photo of John D

John D, AlphaDog

  • 497 Posts
  • 137 Reply Likes
If you are using SmartSelect (ChannelFly), particularly in a very RF congested network, your AP's may hop a lot between channels. You can usually check the syslog ("get syslog log") and look for the message "Channelfly ... detects interference ..."

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.
Photo of Daniel M

Daniel M

  • 43 Posts
  • 9 Reply Likes
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.
(Edited)
Photo of John D

John D, AlphaDog

  • 497 Posts
  • 137 Reply Likes
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!
Photo of Eizens Putnins

Eizens Putnins

  • 107 Posts
  • 42 Reply Likes

 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.  

(Edited)
Photo of Daniel M

Daniel M

  • 43 Posts
  • 9 Reply Likes
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.)
Photo of Eizens Putnins

Eizens Putnins

  • 107 Posts
  • 42 Reply Likes

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