I am using hAP ac lite tower for the last few months. Wireless is set to 5GHz only if that matters. Both RouterOS and the firmware are the latest versions as of now (6.39.2 and 3.36). Starting several days ago, several times per day the router started disconnecting all clients, and on all occasions the log showed:
wlan2: radar detected on [frequency]
This causes a lot of connectivity interruptions as the wireless clients are only able to connect after about 2 minutes, which kind of defeats the purpose of having advanced router.
I am probably 10 km away from the closest airport, so I am not sure what kind of radar is detected.
From what I have read here, the radar detection can not be disabled and disconnecting the clients when a radar is detected is expected, but is there any workaround to avoid or reduce these false positives?
In this video, Ron Touw explains why this happens, and what to do to minimize it: https://www.youtube.com/watch?v=ZbrbRUAfpac
Well, it has a lot of talk about why it is and why you should not disable it, but I have not been able to locate any secret info on how to make it workable.
Maybe you can point at it, the video is quite lengthy and verbose.
In our installations at high altitude above ground level, I have so far been unable to make DFS work on MikroTik with recent RouterOS versions.
Continuous hopping between frequencies, never staying on a single frequency longer than 5-30 minutes, then radar detected again.
Not usable because after every hop there is some downtime while the unit is again looking for a clear frequency.
On Ubiquiti equipment at similar locations it works OK.
Hopefully this will sometime be fixed so we can again operate according to regulations.
Thanks for the link, it explains nicely the reasoning for radar detection. However the recommendations seem to be for WISPs and not home users. Moreover the frequency at which the router (possibly incorrectly) detected a radar is nowhere near the range mentioned in the talk. So the question remains - is there anything that I can do?
You already tried setting it to different initial frequencies? It could happen that radar is not detected on all frequencies but
only on some of them. When you can work out which frequencies are not affected (by running it for a while and collecting
the affected frequencies from the log), you might be able to setup a scan list (wireless->channels and scan list in the interface)
to use only unaffected channels.
However, when your situation is like mine: radar detected on ALL channels after some time, even on channels where there
definately is no radar, the only way to work around is is to turn off DFS as long as it is still possible, despite what Ron Touw says.
I hope this problem will be fixed in a firmware update, but as far as I know MikroTik is still in the state of denial about this issue.
I have a client to whom I have built wireles solution with APs from Mikrotik. With new RouterOS versions it was not possible to make a setup that works. The company is in a hall next to which is a tower full of apartments and so many wireless networks.
Mikrotik AOsalways detects radars and trying to change the frequency of high times downtime making my client to go crazy. Even when it works chosen channels are busiest.
I had to downgrade to a version where I can stop DFS.
I have several customers who have installed Mikrotik routers and are working perfectly, but I can not offer them a wireless solution from Mikrotik because of these problems.
False positives are really a big issue with current version of software ?
For me, they are. But they have always been, but in the past you could more easily turn off DFS and not be bothered by it.
In the current version this is still possible but you have to know how.
I am fully prepared to use DFS as a radar avoidance method, but not as a frequency-hopping-for-no-reason function.
So the false positives really have to be eliminated.
I totally agree and when signals from co location AP’s at a site start this “Radar Detected” nonsense and frequency hopping like crazy - is nuts?
How do you disable ?
I have also the same problem of radar detection message on my wlan card and unable to connect my client. Any configuration on Mikrotik router to disable DFS feature? Thanks.
Please tell me what kind of wireless clients are connected when this happens? Or even nearby. Specifically smartphones and their exact models.
We have already fixed a similar issue caused by the iPhone 6s, but we have observed this with a different brand as well, just want to confirm first, before I say which one.
*) wireless - fixed false positive DFS radar detection caused by iPhone 6s devices;
It happens even without any client connected!
And with no smartphones in the neighborhood.
We have access points in broadcast towers and mobile base station masts and they are unstable even without any connection.
On other very similar sites we use Ubiquiti access points without any issue.
On 2 of the sites where the MikroTik AP’s cannot work, we also have Ubiquiti PtP links (Airgrid M5, Powerbeam M5) also no issue.
If there is no wifi client around, it might as well be actual radar.
RouterOS will not detect radar without reason, but some smartphones do send out strange signals that RouterOS interpreted as radar in the case of iPhone 6s.
You don’t have to be near the radar. Weather radar has range even above 250KM!
The detection mostly applies to Weather radars, not airport radars.
I know that, but I also know the frequency of the weather radar and we have already been warned to stay away from there.
The problem is that on a 45m mobile base station or a 220m broadcast tower there is not a single frequency where a MikroTik
router will stay for more than a few minutes before hopping to another channel.
In my opinion, it is just mis-detectiong radar due to one of the following:
- it actually receives a radar on a single frequency but due to receiver overloading it “sees” it on all channels
- it receives something else than radar, e.g. the local mobile station (GSM/UMTS/4G) which is on a different frequency band but still affects the receiver
During another experiment I saw that there is quite strong breakthrough of image frequencies in the MikroTik AP’s.
E.g. we have locations where 4 AP’s are connected to 4 sector antennas facing outwards and placed about 6 meters apart,
when 3 of them are operational and one is doing a scan, I see the other 3 at different channels than where they are transmitting,
much weaker of course but still well detectable. (it looks like 2*IF images)
When the same happens to radar, it will render even more channels unusable due to radar detection.
That is certainly not normal. Please contact support with the files and all the details.
Shouldn’t be the weather radar detected by special pattern it transmits? This pattern should be positively recognised by the radio. If not then no radar detected result is the only acceptable output. Definitely no false positive detection can occur… Is that so?
Ideally yes but all bets are off when as mentioned by pe1chl "…due to receiver overloading it “sees” it on all channels … " I would go further by saying it wouldn’t take a radar signal to trigger this frequency hopping endless cycle?
Sure. But I meant the case when other devices can fool the routerboards. Seeing the same things on wrong frequencies during background scan always looked for me like an error in some code loop rather than physical radio problem.
In my case the device connected was a MacBook Pro. Not sure about the nearby devices as the problem that I am having is with a home router (hap ac lite tower) is in a residential area with a lot of unknown wireless devices around.
Yes, there is a pattern. And for some crazy reason, when Apple updated iOS, the iPhone 6s model started to emit the same pattern when connecting to a MikroTik AP. This only happened after the iPhone 6s was updated to a newer iOS update. It was not a RouterOS detection bug. We are now seeing a similar issue with the Google Pixel devices, but that is still being investigated in more detail. That radar pattern is apparently too short and can sometimes be found in other signals.