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.

[jason_hinterste]

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.

[zhou_xing]

it works

[daniel_m]

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

[john_d]

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.