Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Community Member

2504 - 1532E - DFS and Radar detection troubleshooting

I have a setup with 2504 and 3x 1532E in the ETSI domain.


I noticed to my surprise that I cannot use dynamic (Auto-RF) for the channel selection on my 1532s

from the WLC GUI (using 7.6.130) I have to manually select channels and power level. Using global for the Mesh APs gives me an error saying

I can only configure channels 100-140 or the extended UNII-2 channels. These are not available in my DCA config

for the indoor APs on the same controller. (they are not enabled)

This works fine in its very basics:


But now for the funny part. Some of the MAPs are disconnecting and the show mesh dfs history

reports radar detection. This happens on most channels I have tested. By changing to 40mhz mode having 2 channels

for example and reducing the power has made it more stable. And now I seem only to have problems with the 3rd MAP bouncing in and out reporting this radar detection. Even now its power level 6 - The APs are rather close so I can afford to lower down the power to have sufficient SNR.

According to this great document the radar detection might be bogus.

As of now I can´t really tell if it is bogus radar detection or not. My major concern is the configuration. Is there no way to use autoRF so I have more dynamic way of fighting potential radar ?

Cisco Employee

Hi ,If you use Auto-rf for

Hi ,

If you use Auto-rf for your back haul connectivity starting from the RAP....even the worst things can happen.

So my Auto-rf runs after some time and thinks that some other channel is best and it switches to that.

Poor MAPs will have to follow the RAP and your complete Mesh N/w will fluctuate. So they force you to configure it manually for back haul only i.e 802.11a.





Community Member

Thanks this makes sense.

Thanks this makes sense. However this makes radars kill my network. Perhaps I can exclude some of the dca channels so I can be available as a test a backhaul  non radar suspectible channel ?

Community Member

Nevermind about that one. I

Nevermind about that one. I tried to exclude some of the lower channels 60 and 64 from DCA selection. Still I have only the extended UNII-3 channels for my mesh configuration.

So how is it, is it common to have bogus radar detection. Perpahs if the MAP is poorly placed getting reflections even from itself or in case the backhaul signal is too strong from the neighbour MAP/RAPs ?

Community Member

OK finally a small progress.

OK finally a small progress. I have been troubleshooting my backhaul 5ghz connection in a 3 AP mesh network installation. It is just small. 1 RAP and 2 MAPs inline. So MAP-01 reaches the RAP and MAP-02 uses MAP-01 as parent.

I haven´t even started to offer any 2,4ghz SSIDs but this setup is meant to be a little hotspot.

My setup is in a small easy town and should be fairly easy. I am using 2504 WLC

and some indoor 2600 on the side. For the mesh part I am using AIR-CAP1532E-E-K9

APs with dual-band omni andtennas. SNR are strong between the APs. Well over 30 and everything looks likeit should work fine.

However I have been dealing with some very frequent radar detection issues. Seeing radar means of course the AP must leave the channel cause of 802.11h regulation.

I have tried to lower the power as much as I can. But on a single channel it doesn´t seem to matter much. MAP-01 is ejecting and its logs say radar detection, channel unusable. I have tried various channels.


After some tests I tried to use 40 mhz channel binding from the RAP. And that made things quite stable form MAP-01. But now my MAP-02 is experiencing the same issue. Always leaving becuase of radar. I know I should probably do some packet sniffing and while preparing to sent someone on site to do that, I did some debugging.

I found out that when debugging debug airewave-director radar enable from the WLC

showed me something alarming:

*RRM-CLNT-5_0: Oct 18 01:01:05.577: Airewave Director: Checking radar Data on 802.11a AP <secret-mac>:C0(1)

(Cisco Controller) >*RRM-CLNT-5_0: Oct 18 01:01:05.577: Airewave Director: active channel 132 customized channel 0 on AP  secret-mac-:C0(1) <-- root AP

*spamApTask6: Oct 18 01:02:19.554: <secret-mac>:d0 MAP-01: *Oct 18 01:02:17.967: ADJ:Child <secret-mac>4f timed out

*spamApTask6: Oct 18 01:02:19.555: <secret-mac>:d0 MAP-01: *Oct 18 01:02:17.967: %MESH-6-LINK_UPDOWN: Mesh station <secret-mac>4f link Down

For me the debug from Airwave Directory is just sayiing a normal periodic check of radars is going down at a certain channel at the time. But at the same time MAP-02 leaves the channel. It sounds to me that all the time this has been happening is a bug and the AP thinks it is radar detection when the RAP is sending this check through the channel.


Has anywone seen this behaviour ? Could it be a software bug related to those fairly new Mesh APs ?

Is it possible that MAP to MAP parenting doesn´support 40 mhz channels and therefore my MAP-02 goes out in the next radar check and thats why MAP-01 stays on (as it has 40mhz towards the RAP directly)


At least I am able to replicate this quite easily and I always see the AP leave shortly after this check from the WLC.


I am running code 7.6.130 btw.

Community Member

Well the head pounding

Well the head pounding against the wall can stop now.

There are some serious radar detection faults with this product.


The DFS detection is CSCuq86274

The DFS channel announcement is CSCur12358


The DFS channel announcement is CSCur12358

that is my main problem will be fixed in next MR 7.6.130 and its coming very soon according to TAC.


The DFS detection is CSCuq86274 unresolved atm. But I have found that enabling channel bonding on the backhaul makes the false radar detection less frequent.

Community Member

The 1532 are serously faulty

The 1532 are serously faulty with regards of radar detection. These bugs don´t affect other types of mesh APs according to Cisco.

CreatePlease to create content