"...detects radar burst on radio..." causing really bad throughput

This morning almost all of my AP "detects radar burst on radio..." causing really bad throughput on my network. This has been going on for more than two hours now and, no, no helicopters or similar can be seen (small town). I have noticed this every now and then but never on this level. Could other types of interference cause the same action? (ZD3025 and R500)

Johan Axelsson

5 Posts
0 Reply Likes

Posted 3 years ago

3 years ago

alexf

34 Posts
9 Reply Likes

HI Johan,

We also saw radar detections frequently on ZF7982 and R500.
This behaviour was in buildings with multiple floors and multiple APs hearing each other, together with a lot of wifi clients present. Outside business hours, there were no radar detection.
These were clearly false positives.
The APs interpreted certain type of RF energy as radar pulse and triggered radar detection.
Other vendors have/had this issue too.

What to do?

- upgrade your ZD and test:
check the latest release notes for 10.x:
https://support.ruckuswireless.com/documents/1975-zonedirector-10-0-mr1-release-notes?_ga=2.15628790...
"Resolved Issues in Build 10.0.0.0.1424: Resolved a false radar detection issue for 7982 and R500 APs. "

- open a case
- use 20MHz wide channels for channel reuse
- use non-DFS channels as a workaround

Cheers,
Alex

Comment

2017-10-18T14:07:51+00:00

Todd

65 Posts
17 Reply Likes

Alex,
Your running v. 10.x on your 7982's? Hows that working out for you? Ruckus recommended NOT going to version 10.x as the 7982's may have performance issues (but they are supported). All I have is 7982's (16) (on ZD1200), so maybe that's why is mine are single model ..? Would like to hear about your experience if you don't mind sharing.

2017-10-18T15:28:33+00:00

alexf

34 Posts
9 Reply Likes

Hi Todd,

Still running 9.13.3.0.121.
Haven't tried the 10.x, but I knew it had a fix for the radar detection.
We were not warned about possible performance issues of ZF7982 in 10.x. We have about 100 ZF7982 so it is good to know this info. Thanks!

The 10.0 changes a lot from 9.13, its webUI is similar to SmartZone 3.5.
The ZF7982 has fewer resources than the newer APs (half of the memory of R500) so it might explain future performance issues.

2017-10-18T16:22:05+00:00

Todd

65 Posts
17 Reply Likes

Yea.. I heard about the UI changes. But you just echoed Ruckus support about memory concerns.

3 years ago

Johan Axelsson

5 Posts
0 Reply Likes

Hi Alex,

Thank you very much for your feedback. It makes sense since we are talking about quite a large factory building with lots of APs.

It is a little strange that this problem (which I have noticed earlier but not to the same extend) suddenly arose this morning. One change I actually did yesterday was that I added one AP to the network...

Recommended firmware seems still to be 9.13.3.0.121. Is it really advisable to go for the 10.0.0.0.1424 version?

Best regards
Johan Axelsson

Comment

3 years ago

alexf

34 Posts
9 Reply Likes

@Johan,

I just provided several options in my first reply.
You should still ask support for advice. I did not try the 10.x.
If you have the possibility to test it, go for the latest MR1 10.0.1.0.17, not for the GA.

Comment

3 years ago

Johan Axelsson

5 Posts
0 Reply Likes

From "AP Activities" this morning:

Oct 19 08:34:55 EFGZD01 syslog: eventd_to_syslog():AP[[email protected]:68:4d:28:07:70] detects interference on radio [11a/n] and switches from channel [116] to channel [36].
Oct 19 08:34:38 EFGZD01 syslog: eventd_to_syslog():AP[[email protected]:68:4d:28:07:70] detects radar burst on radio [11a/n/ac] and channel [128] goes into non-occupancy period.
Oct 19 08:34:38 EFGZD01 syslog: eventd_to_syslog():AP[[email protected]:68:4d:28:07:70] detects radar burst on radio [11a/n/ac] and channel [124] goes into non-occupancy period.
Oct 19 08:34:38 EFGZD01 syslog: eventd_to_syslog():AP[[email protected]:68:4d:28:07:70] detects radar burst on radio [11a/n/ac] and channel [120] goes into non-occupancy period.
Oct 19 08:34:38 EFGZD01 syslog: eventd_to_syslog():AP[[email protected]:68:4d:28:07:70] detects radar burst on radio [11a/n/ac] and channel [116] goes into non-occupancy period.
Oct 19 08:32:12 EFGZD01 syslog: eventd_to_syslog():AP[[email protected]:68:4d:29:2b:10] detects interference on radio [11g/n] and switches from channel [11] to channel [1].
Oct 19 08:31:58 EFGZD01 syslog: eventd_to_syslog():AP[[email protected]:68:4d:28:07:70] detects interference on radio [11g/n] and switches from channel [11] to channel [6].
Oct 19 08:31:49 EFGZD01 syslog: eventd_to_syslog():AP[[email protected]:10:7f:25:16:70] detects interference on radio [11g/n] and switches from channel [11] to channel [6].
Oct 19 08:31:49 EFGZD01 syslog: eventd_to_syslog():AP[[email protected]:68:4d:29:2b:10] detects interference on radio [11a/n/ac] and switches from channel [100] to channel [104].
Oct 19 08:31:49 EFGZD01 syslog: eventd_to_syslog():AP[[email protected]:68:4d:28:07:70] detects interference on radio [11a/n/ac] and switches from channel [100] to channel [116].
Oct 19 08:31:31 EFGZD01 syslog: eventd_to_syslog():AP[[email protected]:68:4d:28:07:70] detects radar burst on radio [11a/n/ac] and channel [112] goes into non-occupancy period.
Oct 19 08:31:31 EFGZD01 syslog: eventd_to_syslog():AP[[email protected]:68:4d:28:07:70] detects radar burst on radio [11a/n/ac] and channel [108] goes into non-occupancy period.
Oct 19 08:31:31 EFGZD01 syslog: eventd_to_syslog():AP[[email protected]:68:4d:28:07:70] detects radar burst on radio [11a/n/ac] and channel [104] goes into non-occupancy period.
Oct 19 08:31:31 EFGZD01 syslog: eventd_to_syslog():AP[[email protected]:68:4d:28:07:70] detects radar burst on radio [11a/n/ac] and channel [100] goes into non-occupancy period.

APs consider other APs as interference sources? Should this situation at all occur? Note that this is concerning the 5 GHz band only.

/ Johan Axelsson