Channel Fly & Background Channel Scan Causing 2.4 GHz Issues

[prez_129784]

Hey All -

A few days into my conversion from another brand to the R600 unleashed and mainly so far so good.

I have noticed something occurring that's impacting my 2.4 GHz Wifi HP printer and 2 EcoBee Wi-fi thermostats.

All 3 devices will connect and will remain connected for about 30 minutes...I notice the printer dropping and reconnecting on its own and then that stops entirely around 30 mins.  The thermostats drop and never recover on their own.  All devices require a full restart and then the same behavior will repeat.  Simply telling the device to reconnect won't work, it must be completed rebooted to reconnect (in the case of the EcoBee it must be removed from its baseplate and reattached).

About an hour with Ruckus technical support determined that the devices appear to be having a hard time with the channel change behavior thats occurring - disabling Channel Fly appeared to slow down the behavior but it would eventually occur again.  Turning off background scanning on 2.4 GHz entirely has apparently resolved the issue (all 3 devices have been up for over 6 hours without issue so far)

Contacting EcoBee didn't go very well - they indicate that since the problem wasn't present on a different access point that the access points are at fault and basically I need to live with it or submit a bug request to Ruckus (naturally, I can't return the thermostats - been several months) and I have a low confidence level that its a Ruckus problem.

HP support netted a little better result in that I was told some 2.4GHz devices have a hard time with channel changes entirely and most "consumer" grade equipment doesn't perform a channel change or evaluation of channel behavior except once, when its rebooted.  I was also notified that the HP printer doesn't support 802.11H so I was also advised to leave any automatic channel change or evaluation behavior on the access point off.


So my questions (I suppose) are:

• Is there anything special or magical with how Ruckus handles channel changing behavior or evaluation?
• Is there a problem with the 3 devices (2 EcoBees and 1 HP printer) several other 2.4Ghz devices don't exhibit this behavior. 
• Is there some incompatibility I'll need to live with or simply live with the channel changing disabled on 2.4G?  Think its a Ruckus issue?

Overall it's a bit odd to me, I have a 6 year old 2.4Ghz USB wifi adapter that works just fine even with channel changes but the Ecobee's and printers that are less than a year old seem to have problems.


Thanks for any comments/help

[john_d]

Just to clarify, was the change you initially mentioned switching from ChannelFly to Background Scanning for "automatically adjust channels with"?

If so, I'm not surprised. Any sort of automatic / frequent channel switching, whether it's done by Background Scanning, or Channelfly, causes issues with certain wifi clients who were not meant to cope with channel changes. I think the EcoBee support person is misguided — these kinds of problems are certainly client problems, and I also have an Ecobee and I've seen the unit go as far as reboot when the 2.4GHz channel changes.

So yeah, I think you are going to have to turn off any form of 2.4GHz automatic channel selection, and fix a selection of a 2.4GHz channel.

[prez_129784]

Yes, correct to the first question above.

Was afraid that was going to be the answer but it sounds like any enterprise AP device would likely have the same "Feature" that would impact certain clients I take it?

Unfortunately there's not a way to get up past the Tier 1 agents at EcoBee so i'd imagine it won't get fixed at all (at least not anytime soon) as most customers likely don't have them connected to enterprise gear.


Thanks again

[john_d]

Yeah, it sounds like any enterprise AP that has a channel optimization feature involving switching channels automatically would aggravate these devices.

And I think you've pieced together most of the rest of the explanation too — on 5GHz, DFS support virtually requires that clients support 802.11h channel switch announcements, so 5GHz auto-switching tends to be tolerated better. But not always.

ChannelFly tends to bring out the worst in noncompliant clients because during the initial learning phase, it can switch channels extremely rapidly as it tries to find the best channel. But still, as you found out, even background scanning's slower switching still eventually ticks off such clients.

[hisham_matni]

I had several connection issues with ios devices.. And it was only solved by disabling background scanning on the WLAN