Is MTBC broken in 9.7.x for standalone AP?

[jeff_roback]

Since upgrading to 9.7.x on a standalone 7363 it looks like our channelfly problems are back... I verified that MTBC is set to the maximum 1440 for both 2.4 and 5 GHz but we're still seeing channel hops very frequently, and clients that have compatibility problems are getting dropped a lot. We didn't have any problems with this on 9.6 but the problem has now returned with 9.7. (seeing this on 9.7.0 and on 9.7 SR1)

Did the behavior of MTBC change at all with 9.7.x?

is there any way to disable channefly for standalone APs? If not, I'd strongly reccomend this for a future release....

Thanks,
Jeff

[keith_redfield]

Downgrading back to 9.6 (if you are not using 9.7-specific features) would tell us a lot. If the problem persists then we know it is probably un-related to the code, and likely something environment related.

Upgrading reset the stored ChannelFly data and so the AP had to re-learn the environment. It should still settle down on it's own eventually unless you have a lot of dynamic interference.

On a standalone AP, static channels are currently the only workaround. You could let ChannelFly run for a while, then lock it in (see below)

If you grab the AP supportinfo file you can look for "channelfly" and that will tell you the current status of the system and the stats on each channel. At the bottom of that, search for num_chan and that will tell you how many times it's switched.

[jeff_roback]

So this is interesting... I downgraded to 9.6 still saw this behavior. So I tried each individual image all the way down to 9.4.2 and still saw it. I reset the AP to factory defaults and still saw it. It seems to be just ignoring the MTBC settings.

Should the MTBC settings be affecting how long it takes between channel jumps immediately after boot, or do we have to wait a period of time before the MTBC setting takes effect?