Reply
Highlighted
New Member
Posts: 12
Registered: ‎06-05-2013
Kudos: 1
Solutions: 1

DFS radar status and channel swapping issue

[ Edited ]

Hello.

 

I've a 45º sector antena with a Rocket M with 6.1.8 XW firmware.

 

At start, having 5505 or 5520 Mhz selected, for example, I can see in Main tab a frequency (with de "DFS Wait" label) jumping between some random channels.

Some time later, maybe 1 minute or so, it stops where it likes. Even in an Indoor channel, despite if "hide indoor channel" is enabled or not. When it stopped, label shows "DFS Radar"

 

At this point, scaning tool doesn't shows anything. As if radio were completely off. I understand the radio must be "silent" for not to interfere the radar... but scanning should not send any signal, isn't it?

 

Furthermore, at this point too, changing frequency doesn't make the Rocket to do anything. It stays at the same random channel it choosed. I must to restart device and the story begins once again.

 

DFS is a pain in the ass. We all know that. But, can we make things some better or are we tied to some weird laws?

If I choose the frequency 5500 and restart device, it keeps with "DFS Wait" for a moment and then goes working fine. Why device doesn't choose this frequency, when it detects a radar, instead of jumping and stopping in a "DFS Radar" state?

Why device cannot scan while in "DFS Radar" status?

Why device doesn't keeps scanning, while in "DFS Radar" status, looking for "non radared" and "usable" channel rather than being in some weird channel? It's a much better solution than waiting for who knows how many time.

Is it possible that "hide indoor channels" make the DFS Radar jumping algorithm to don't use indoor channels? Or must I active the frequency list checkbox and choose the non-indoor channels there?

 

P.D.

Downgrading to 6.0.3, where it was before, at 5520 Mhz, stops detecting radar. In two devices (a rocket and a nanostation)

Are detecting false radars in new firmware or the old firmware don't detects real ones?

 

P.D2.

I've tested many firmwares from 6.0.3 and this radar detections are only on last firmware (6.1.8)

But, cannot see anything about DFS changes here. Neither about the the new frequencies availability for Spain.

 

P.D. 3 (Last one... I hope XD)

This is the log:

Sep 21 17:18:16 system: Start
Sep 21 17:18:16 syslogd started: BusyBox v1.24.2
Sep 21 17:18:16 mcad[938]: Starting mca daemon v1.7
Sep 21 17:18:16 FileSystem: Start check...
Sep 21 17:18:17 wireless: ath0     ieee80211_mark_dfs: Radar found on channel 119 (5595 MHz)
Sep 21 17:18:17 dropbear[935]: Not backgrounding
Sep 21 17:18:18 wireless: ath0     Set Mode:Master
Sep 21 17:18:19 mca-ctrl[964]: Going to create 'FirstPing' reporter url = <URL>
Sep 21 17:18:19 mcad[938]: New reporter created, type = FirstPing, url = <URL>, interval = 10s
Sep 21 17:18:19 mca-ctrl[964]: FirstPing reporter created successfully
Sep 21 17:18:19 mcad[938]: Reporter type = FirstPing, url = <URL> got http response, http_code = 200
Sep 21 17:18:19 mcad[938]: FirstPing reporter success!
Sep 21 17:18:19 mcad[938]: Destroying reporter, type = FirstPing, url = <URL>
Sep 21 17:18:19 dropbear[966]: Child connection from <IP>:50884
Sep 21 17:18:21 wireless: ath0     ieee80211_mark_dfs: Radar found on channel 124 (5620 MHz)
Sep 21 17:18:22 dropbear[966]: Pubkey auth succeeded for 'mcuser' with key md5 xxxxx
Sep 21 17:18:22 mca-ctrl[983]: Going to create 'Heartbeat' reporter version = 0, url = <URL>, interval = 15s, crypted = true, compressed = false
Sep 21 17:18:22 mcad[938]: New reporter created, type = Heartbeat, url = <URL>, interval = 15s
Sep 21 17:18:22 mca-ctrl[983]: Heartbeat reporter created successfully
Sep 21 17:18:22 dropbear[966]: Exit (mcuser): Exited normally
Sep 21 17:18:23 FileSystem: End check.
Sep 21 17:18:30 wireless: ath0     ieee80211_mark_dfs: Radar found on channel 129 (5645 MHz)
Sep 21 17:18:30 wireless: ath0     ieee80211_mark_dfs: Radar found on channel 134 (5670 MHz)
Sep 21 17:18:30 wireless: ath0     ieee80211_mark_dfs: Radar found on channel 139 (5695 MHz)
Sep 21 17:18:36 wireless: ath0     ieee80211_mark_dfs: Radar found on channel 148 (5740 MHz)
Sep 21 17:18:37 wireless: ath0     ieee80211_mark_dfs: Radar found on channel 153 (5765 MHz)
Sep 21 17:18:48 wireless: ath0     ieee80211_mark_dfs: Radar found on channel 158 (5790 MHz)
Sep 21 17:18:48 wireless: ath0     ieee80211_mark_dfs: Radar found on channel 163 (5815 MHz)
Sep 21 17:18:49 wireless: ath0     ieee80211_mark_dfs: Radar found on channel 168 (5840 MHz)
Sep 21 17:18:49 httpd[993]: Password auth succeeded for '<USER>' from <IP>

Weird, isn't it?

But if I tell you that, as you can see, there is no detection on 5520, where the device is configured to, it is insane! Man Tongue

 

Regards.

Ubiquiti Employee
Posts: 1,435
Registered: ‎02-13-2017
Kudos: 449
Solutions: 147

Re: DFS radar status and channel swapping issue

I suggest downgrading the AP to 6.1.7. I have seen a few reports of false DFS hits on 6.1.8.

Also, its best to not use Auto, you should select a clean channel and leave it there.

UBNT_Alternate_Logo.png
Ubiquiti Networks airMAX Support Team

Check out our ever-evolving Help Center for answers to many common questions!

FREE UBWA Student Guide-Great RF Primer!

Ubiquiti Employee
Posts: 8,674
Registered: ‎04-14-2017
Kudos: 1635
Solutions: 249

Re: DFS radar status and channel swapping issue

We are working on the DFS issues reported in v6.1.8.
Member
Posts: 148
Registered: ‎12-10-2014
Kudos: 61
Solutions: 2

Re: DFS radar status and channel swapping issue

[ Edited ]

we experience the same issues and tried to tackle it down to some specific situation but in our network of about 150 airmax (most are m5 xm and xw) devices it really happens randomly.

we have DFS issues since around the last 2-3 airmax versions, actually with v6.1.8.

upgrading all devices to recent version in the hope its finally fixed now... so downgrade one version does not work out for us, we would have to go several versions back until we see that after at least a week that issue does not happen. cause it happens on devices with 1-2 days uptime as also on devices with 10d+ uptime..

regardless of channel selection, we usually always set a specific channel, but from time to time devices switch to "Channel/Frequency:36 / 5180 MHz" and stay on it. when we check wireless settings, specific channel (e.g. 100 / 5500MHz) is set but not used.

rebooting the device does not help, it stays on channel 36.

changing channel to anything else, waiting for connection, then change back to channel 100 fixes the problem temporarily.

sometimes when changing channel this way back to specific channel, wireless status is "DFS Radar" until selecting another channel. this happens on different channels, for debugging, we tried it even on indoor channels and here its like the same behaviour.

 

what we dont understand, shoudn't DFS (Dynamic Frequency Selection) "dynamically" set another frequency, while a radar is active, then after that change back?

 

and another point is: here in austria, regulatory watches/checks for people not to use 5620/5640mhz because local radar(s) working on these frequencies, so we dont use those channels. but then why is a radar on channel 100 / 5500 mhz detected?

 

and why does it always switch to channel 36? because its the first channel that can be set? its inpractical if several devices on one site change to the same channel, they disturb each other this way..

Reply