cancel
Showing results for 
Search instead for 
Did you mean: 

Channelfly incompatible with apple products!?

blaine
New Contributor

Simple question I can't find answered anywhere. Is channelfly incompatible with apple products? I have 3 R710's running 200.11.10.5.195 (previously 200.10.10.5.246) it's always done this regardless of firmware. When channelfly is enabled on 5ghz whenever an apple device (iphone 13 pro max,ipad air 2021, macbook pro 16 2021) starts using any significant amount of bandwidth like a file transfer it seems to trigger channelfly to take action which immediately boots the device from that access point. Even voip calls will sometimes trigger this as well.

Disabling channelfly on 5ghz has solved this problem but I am confused as the documentation indicates channelfly shouldn't cause these issues. My configuration is very simple, only 3 ssid's no major settings changed in a home environment. Thanks for any help!

1 ACCEPTED SOLUTION

john_d
Valued Contributor II

This is unfortunately one downside of using ChannelFly. When a client uses the channel, especially if it’s not capable of the most efficient bitrate, ChannelFly can see it as a capacity drop and will react by changing channels. ChannelFly can’t always predict whether the capacity drop is because the channel has some form of interference that doesn’t show up in background scans, or because a client is far away or has their antennas obstructed. 

Over long periods of time, after most channels have been hopped to, ChannelFly tends to settle down some and won’t run away on every bit of activity. However on a home network this can take a while and be fairly disruptive. On a home network I generally don’t recommend using ChannelFly. It is great for certain kinds of deployments like outdoor or shared space APs in a busy apartment complex where tenants operate their own WiFi. In such an environment, the interference is dynamic and bound to change at any time. 

Some of the controllers like SmartZone have more fine grained ChannelFly settings that let you designate certain hours of less frequent channel changes. There’s also a MTBC value you can tune on the CLI in Unleashed. And ZD (I don’t think Unleashed) also supports a run stop mode where ChannelFly stops changing channels after a certain amount of uptime. 

Personally I don’t find those options to be good workarounds. They all have their flaws and limitations and sidestep the benefit of ChannelFly which is always on, dynamic channel changes when interference changes. 

Unless you’re having difficulty with manual or background scan based channel assignments, I would not turn on ChannelFly. 

View solution in original post

8 REPLIES 8

john_d
Valued Contributor II

This is unfortunately one downside of using ChannelFly. When a client uses the channel, especially if it’s not capable of the most efficient bitrate, ChannelFly can see it as a capacity drop and will react by changing channels. ChannelFly can’t always predict whether the capacity drop is because the channel has some form of interference that doesn’t show up in background scans, or because a client is far away or has their antennas obstructed. 

Over long periods of time, after most channels have been hopped to, ChannelFly tends to settle down some and won’t run away on every bit of activity. However on a home network this can take a while and be fairly disruptive. On a home network I generally don’t recommend using ChannelFly. It is great for certain kinds of deployments like outdoor or shared space APs in a busy apartment complex where tenants operate their own WiFi. In such an environment, the interference is dynamic and bound to change at any time. 

Some of the controllers like SmartZone have more fine grained ChannelFly settings that let you designate certain hours of less frequent channel changes. There’s also a MTBC value you can tune on the CLI in Unleashed. And ZD (I don’t think Unleashed) also supports a run stop mode where ChannelFly stops changing channels after a certain amount of uptime. 

Personally I don’t find those options to be good workarounds. They all have their flaws and limitations and sidestep the benefit of ChannelFly which is always on, dynamic channel changes when interference changes. 

Unless you’re having difficulty with manual or background scan based channel assignments, I would not turn on ChannelFly. 

blaine
New Contributor

@john_d 

Wow, thank you so much for such a thorough explanation. This is extremely helpful. I will leave channelfly off. The documentation and brief description I had read in ruckus documentation I was able to find in the past had me confused to what degree it would impact clients and in my mind implied the impact would be extremely minimal, which for me was not the case.

eizens_putnins
Valued Contributor II

And to add -- Channel Fly doesn't boot clients, it changes channels, unfortunately Apple devices usually understand it as lost WiFi and do not reconnect on new channel, but disconnect totally. Channelfly is a nice idea, but without cooperation from clients it can't be really used   -- as far as Apple devices see channle switch as a lost WiFI, you can't use it with Apple clients.

In principle, Apple devices tend to be the biggest headache on WiFi network -- there is no much you can change in they client configuration, and Apple users see that any fault reason never is they device capability (as it is always flowless), but always -- outside world.     

Apple devices with WiFi 5 or newer support channel switch announcements as required by the spec (802.11h). Switching channels may cause a brief pause in the connection but the AP and Client should reconnect and resume without any major disconnection automatically. You might need 802.11r and k enabled for a better experience.