15.1.1 DFS hits and stack dumps - Totally unstable release!!!

starting the see lots of DFS hits across ~90 APs and now getting stack dumps on some.  mixture of 450 and 450i.

gonna downgrade our entire network and wait for a stable release :-(

Sean - I am told the guys reached out to you to find out what's going on here... we will post results as we obtain them.  If you get sorted, and want to share, feel free to update this thread also.

Is there a conclusion or an update on this? Kinda curious....

Still under investigation.  As I have stated in a few threads on this topic, DFS is always a balancing act.  We (as the manufacturer) are required to meet all the regulations, but avoid going too far in detecting so as to cause false detects... it's really tough to get it right.

But rest assured, we have really smart folks working on it...

hi matt -

yes your team has reached out to me and we are investigating...will post the results once we know more.



I wanted to post that this issues seems to be resolved.  

In regards to DFS hits:  After working with the cambium team we found that our 5.7GHz FSK system was slightly out of sync with our 5.4GHz 450 system.  They weren't out of sync enough to cause other issues (like slow speeds or high re-reg counts) and they've been this way for years. But it seems that with the new tighter DFS limits imposed by the FCC that the slightly out of sync systems triggered false DFS hits.  So instead of following the advice of keeping your systems within 100-300 bit times of each other the advice should be "make sure your FSK AP stops transmitting before the 450 AP stops and also make sure the 450 AP starts receiving before the FSK AP starts receiving.

In regards to the stack dumps: There were two things causing stack dumps.  The first was the DFS hits mentioned above.  When one AP in a cluster (or nearby tower) would register a false DFS hit that would sometimes cause a nearby AP to stack dump.  Fixing the DFS hits fixed most of the stack dumps.  The other reason for the stack dumps was related to cnMaestro.  If the on-premises cnMaestro server got hung up or re-booted for any reason then APs would stack dump and reboot.  the new version of cnMaestro seems to be better about this but not enough time has passed for me to say it's fully solved (it's pretty rare that the cnMaestro server hangs so there's not enough data for me to say it's fixed...and i'm not going to purposefully reboot the server to test it out lol).


1 Like

Thanks for reporting back Sean.  We are working through this and some other issues related to timing.  Every time the rules become tighter, the system needs tweaking.  It's a sad reality I am afraid, but we are beholden to the regulations.