13.3 Error - Radar Detected - DFS Failure - Zero Customer Issue

So for the last few months we have been noticing an interesting bug with some PMP450 APS running 13.3

We will find an access point with 0 of 100 customers online.

The access point does not indicate radar detected.

The access point does not show a loss of sync.

We reboot the access point and all customers register just fine.

After going back and forth with support they have decided that this was a failure with DFS attempting to switch to an alternate frequency after radar has been detected. Since no alternate frequences are set, no frequences are selected and the access point gets stuck and loses timing.

The front status page still indicates its original frequency, it shows in service, full power, and that it is receiving sync.

Here is the funny thing. We have only seen this error with 13.3 and only see it on "some" access points randomly while other access points throw the "radar detected" message just fine.

Has anyone else seen this type of error in the wild yet?

We are running about 150 PMP450 aps with 13.3 while the rest remain at 13.2 until this issue is solved and have only seen this error in limited areas.

I have not heard of this issue occurring anywhere, and based on the lack of response, maybe not too many others see it either...

Have you tried upgrading to the latest R13.4 Beta?

It may help. There have been several bug fixes since the R13.3 build, though I can't say anything specifically related to this behavior.  Please let us know how it goes.

Also, if the case is still open or you believe it requires more attention, please let me know.


@VTX wrote:

So for the last few months we have been noticing an interesting bug with some PMP450 APS running 13.3

We will find an access point with 0 of 100 customers online.

The access point does not indicate radar detected.

The access point does not show a loss of sync.

We reboot the access point and all customers register just fine.

After going back and forth with support they have decided that this was a failure with DFS attempting to switch to an alternate frequency after radar has been detected. Since no alternate frequences are set, no frequences are selected and the access point gets stuck and loses timing.

The front status page still indicates its original frequency, it shows in service, full power, and that it is receiving sync.

Here is the funny thing. We have only seen this error with 13.3 and only see it on "some" access points randomly while other access points throw the "radar detected" message just fine.

Has anyone else seen this type of error in the wild yet?

We are running about 150 PMP450 aps with 13.3 while the rest remain at 13.2 until this issue is solved and have only seen this error in limited areas.


VTX,

Yes thi s in fact a bug with 13.3. Sorry about that. :(

Good news is we have already fixed in in 13.4 beta that is available. I suggest trying 13.4 (Build 10) when it comes available.
The other option like you stated is going back to 13.2.X release.

Sorry for the inconvenience,

Charlie

Charlie

Just giving you a heads up we have seen this event occur twice in the last week on two different access points both running 13.4

We have been running 13.4 since release and 13.4 beta since late May with no issues.


@VTX wrote:

Charlie

Just giving you a heads up we have seen this event occur twice in the last week on two different access points both running 13.4

We have been running 13.4 since release and 13.4 beta since late May with no issues.


VTX,

Which error exactly? Radar Detections can happen, even false ones on occasion. Did the AP properly switch to an alternate frequency? 

-Charlie

According to support they are saying the DFS alternate frequency was not configured so the AP could not switch over when radar was detected

If you look at the Alternate RF carrier frequencies we dont have them set for any of our pmp450 access points yet this failure only seems to occur in a very select group of radios that are on the 5.4 frequency range

This is an issue that is supposed to have been corrected in 13.4

What specifically we are seeing is we find an Access Point with 0 of 50 customers registered. No radar detected notification, no other visible error messages.

We have to manually reboot the access point because it is stuck and all of the customers magically re-register.


@VTX wrote:

According to support they are saying the DFS alternate frequency was not configured so the AP could not switch over when radar was detected

If you look at the Alternate RF carrier frequencies we dont have them set for any of our pmp450 access points yet this failure only seems to occur in a very select group of radios that are on the 5.4 frequency range

This is an issue that is supposed to have been corrected in 13.4

What specifically we are seeing is we find an Access Point with 0 of 50 customers registered. No radar detected notification, no other visible error messages.

We have to manually reboot the access point because it is stuck and all of the customers magically re-register.


PTX,

Due to a known bug in our FPGA you may get false radar detections on 13.4 caused by the SM. The work around is to set your SM Receive Target Level setting on the AP down until you do not get any more false radar detections. This is resolved in 14.0 and forward.

As far as not having an alternate frequency configured and getting a radar detection that is something we will have to investigate.

-Charlie

Charlie...

Thank you again for replying to me or whomever PTX is :D

Its interesting you bring this up. The issue you describe I can see being a problem when people lie about their antenna gain (set it to zero) to boost their transmit power. This is something one of your support engineers (vernon is the bomb) pointed out to us when we questioned him as to why we were being blown off our frequencies by competitors in the areas. Radar detection becomes an issue with signal processing in this case because the equipment isnt reducing the signal threshold to account for the antenna.

In this case it seems like we are doing everything bass-ackwards. If we set a target level of -68 and we have a radio so close to the tower its coming in hot at -58, should we throw intentionally misalign it to prevent this issue? I really dont want to have this talk with my installers as I can see the chaos.

Thank you again for sharing your information and taking the time to reply in detail.

i dont want to be a spoiler but we just upgraded to 13.1.2 on a system that has been running in a community for 4 years and we are just now getting some "radar detected " red flag on the DFS and the AP is shut down until we reboot and good to go, and yes the AP'S have an alternate frequency to them. This just started and was not an issue ever

Y


@ymaynard wrote:

i dont want to be a spoiler but we just upgraded to 13.1.2 on a system that has been running in a community for 4 years and we are just now getting some "radar detected " red flag on the DFS and the AP is shut down until we reboot and good to go, and yes the AP'S have an alternate frequency to them. This just started and was not an issue ever

Y


I assume you mean 13.2.1. I see the same issue on a couple 450 sectors running in the 5.4 band. Two alternate frequencies defined, yet all three go into radar detected and unavailable. I've tried moving channels around and it got a little better, but it's still happening at least 3-4 times per week. These are very short range sectors though, <1 mile to all SMs, AP max range is 2 miles. SM uplink being bounced off of trees and houses nearby is my suspicion.

There's a note somewhere, I forget exactly where. You can try setting the SM receive target power level on the AP to -62 and see what that does. I've backed mine off to -65 and it helped bit, but then SM uplink rates started to suffer. I might try increasing max range and see if that makes a difference.

I am currently having this issue with a Cyclone AP. Came across this from a good friend. List of WLAN channels - Wikipedia
https://en.m.wikipedia.org/wiki/List_of_WLAN_channels