radar detected problems

lap · Thu Jul 20, 2017 10:48 pm

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?

MartijnVdS · Fri Jul 21, 2017 8:02 am

In this video, Ron Touw explains why this happens, and what to do to minimize it: https://www.youtube.com/watch?v=ZbrbRUAfpac

pe1chl · Fri Jul 21, 2017 12:09 pm

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.

lap · Sat Jul 22, 2017 8:27 am

In this video, Ron Touw explains why this happens, and what to do to minimize it: https://www.youtube.com/watch?v=ZbrbRUAfpac

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?

pe1chl · Sat Jul 22, 2017 11:29 am

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.

grusu · Sat Jul 22, 2017 12:17 pm

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.

n21roadie · Sat Jul 22, 2017 5:02 pm

False positives are really a big issue with current version of software ?

pe1chl · Sat Jul 22, 2017 6:02 pm

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.

n21roadie · Sat Jul 22, 2017 6:41 pm

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 ?

paams · Mon Jul 24, 2017 8:02 am

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.

Mon Jul 24, 2017 10:08 am

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;

pe1chl · Mon Jul 24, 2017 11:45 am

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.

Mon Jul 24, 2017 11:55 am

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.

pe1chl · Mon Jul 24, 2017 12:08 pm

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.

Mon Jul 24, 2017 12:27 pm

That is certainly not normal. Please contact support with the files and all the details.

Mon Jul 24, 2017 2:48 pm

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?

n21roadie · Mon Jul 24, 2017 6:00 pm

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?

Mon Jul 24, 2017 8:12 pm

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.

lap · Mon Jul 24, 2017 10:41 pm

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.
Code: Select all
*) wireless - fixed false positive DFS radar detection caused by iPhone 6s devices;

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.

Tue Jul 25, 2017 9:18 am

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?

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.

pe1chl · Tue Jul 25, 2017 10:40 am

Is there a way to turn on more detailed logging to see what pattern it is seeing as a reason for channel change and how long it is present?
Or a way to log "detected radar" events when DFS is off? So we can collect info on the running devices without rendering them unusable?

Grickos · Sun Aug 13, 2017 9:57 pm

When selecting the frequency starting "search for radars" it takes 1 minute for 20MHz and Ce 40Mhz.
The Ceee 80MHz takes up to 10 minutes.
Is this expected behavior?

pe1chl · Sun Aug 13, 2017 10:21 pm

It depends on the frequency. Maybe your 80 MHz channel includes a frequency where 10 minutes of checking is required. Check your local regulations.

Odar · Tue Aug 22, 2017 7:45 pm

Hello.

I have similar problem with my Samsung Galaxy A5 2016 running on Android 7.0. If I try to connect it to 5 GHz wifi (I have MikroTik hAP ac), it disconnects my second client (notebook lenovo W520) and I see in log radar detected on 5580000. And the frequency is sometimes changeing (5540000, 5300000, 5660000). I have RouterOS 6.40.1.

It runs OK on 2,4 GHz.

n21roadie · Thu Sep 07, 2017 12:26 pm

Because of ongoing false positives of "Radar Detected" generated by either co-location or/including nearby/distant other operators AP's, moving frequency and replacing AP's with "reduced co-location Interference suppression" sometimes only increases the time between the false positives and re positioning AP's is not a option, we have had no choice but to downgrade and lose wireless improvements available on the latest versions.

el berto · Thu Oct 05, 2017 11:59 am

Avoiding to open new discussions.....
I've been using Alvarion radio for a link (3km) with DFS enabled for several years. It correctly detects radar and founds free frequencies.
After a storm I had to replace Alvarion using a Routerboard (AP and client are RB433 with ROs 6.19): DFS detects radar on all frequencies so I can't find available frequency. (I'm using dame panel antenna for all devices)
As backup I tested Ubiquiti, it correctly detects radar but it still finds free frequencies (the same frequencies used by Alvarion).
Why can't I get free frequencies using Routerboard?
Any idea?
Thanks.

Thu Oct 05, 2017 12:43 pm

6.19 is quite outdated. Maybe actual version can behave in other ways...

n21roadie · Thu Oct 05, 2017 5:55 pm

Just updated to V6.40.4 on some AP's, time will tell if its stable?

Wed Nov 01, 2017 9:52 am

... And what the time told you so far?

n21roadie · Wed Nov 01, 2017 12:22 pm

... And what the time told you so far?

I had to roll back to dfs on/off version to ensure no disruptions of service for customers, the AP's that are currently running 6.40.4 were the ones that did not give problems , so I desided to leave them ,checking an ap on a test circuit is really of no use in this senario.

Wed Nov 01, 2017 1:40 pm

It is really pitty that mikrotik forces the DFS where it is not necessary. But anyway, haven't you tried the superchannel mode? It should be without DFS if I remember well - but haven't tested recent versions for that,so it is just an assumption.

n21roadie · Wed Nov 01, 2017 1:59 pm

It is really pitty that mikrotik forces the DFS where it is not necessary. But anyway, haven't you tried the superchannel mode? It should be without DFS if I remember well - but haven't tested recent versions for that,so it is just an assumption.

Just tested and on superchannel mode freq=5600 - test client re-established wireless connection in less than a minute rather than 10 mins that it usually takes in DFS mode?

Wed Nov 01, 2017 3:58 pm

It is really pitty that mikrotik forces the DFS where it is not necessary.

That's not true. If you are in an area (Country) where this is not necessary, you are free to use the Superchannel wireless mode, and lower 5GHz frequencies (5180-5240) and there will be no radar detection at all.

Wed Nov 01, 2017 4:36 pm

I meant when we use the country regulatory domain setting and we know what weather radars on what frequencies and at which azimuth are in use, it does not make any sense to force DFS on other frequencies or at places or orientations that are fully out of radar reach. Actually false positives are making our links unusable many times so we need to step out of the setting to the superchannel or use older ros versions where DFS was optional parameter.

n21roadie · Wed Nov 01, 2017 4:44 pm

It is really pitty that mikrotik forces the DFS where it is not necessary.
That's not true. If you are in an area (Country) where this is not necessary, you are free to use the Superchannel wireless mode, and lower 5GHz frequencies (5180-5240) and there will be no radar detection at all.

It also a pity we have to learn wireless tweaks from non Mikrotik support staff - Example Radar Detect and DFS on MikroTik https://www.youtube.com/watch?v=ZbrbRUAfpac (Slide 55)
I will quickly add that the presentation was professional and very informative but my point is simply that Mikrotik as wireless vendors, etc should have in house staff doing this type of
presentation unless ????

pe1chl · Wed Nov 01, 2017 4:56 pm

Note that in some countries the sale of equipment that can operate without compliance to the local regulations is not allowed, and so it is not always possible to officially document (hidden) features that allow such operation.
In fact, talking too much about it might lead to the removal of the feature, similar to current regulations in the USA where it is no longer possible to tune the radio out of the allowed band (in a model sold in the USA).

Thu Nov 02, 2017 1:17 pm

a manufacturer can't just recomment "great ways to break the law". The standard and the law sets these rules, often they have to be followed, even if you think you know there are no radars.

Thu Nov 02, 2017 1:23 pm

Yep. Unfortunately this is true.

cairduil · Mon Jan 22, 2018 1:41 pm

Hi Anyone resolved problem with DFS? There is any option to disable DFS or bypass? Could I setup different country and this way could I disable DFS?
Somebody already bypass DFS? I have huge problem with !DFS!
What it is a different between radar detected and running app info on the bottom on wireless window?
Thanks for help

elcad · Thu May 17, 2018 11:58 am

After forcing us to new Router OS versions higher then 6.36.3, due to Mikrotik virus affecting the older versions, all bought Mikrotik WiFi hardware became pieces of unusable plastic boxes, usable maximum as toy for dog... Really "funny", but it cost lots of money and finacial lost due loss of customers! ! Will Mikrotik return money for such devices, where is not possible switch off DFS or avoid OS drop by virus infection in same time... ???
Or does exist alternative version of current mikrotik OS, where is possible to switch DFS OFF ? E.g. thru hidden command in terminal window?

pe1chl · Thu May 17, 2018 12:06 pm

I would rather hope that the DFS problem is fixed. False DFS radar detection is a big problem in MikroTik equipment, when using
Ubiquiti equipment the same problem does not occur. That has nothing to do with regulations and laws, it is a matter of fixing
the software that does the false DFS radar detects.

vecernik87 · Fri May 18, 2018 2:31 am

I can imagine it is not that easy to fix something unless you can precisely replicate the issue. DFS is required by certain countries on certain frequencies. I hope mikrotik implemented those correctly so if you select for example country=united states , then DFS should be disabled on 5180-5240 and 5745-5825 . If manufacturer allows you to disable DFS on frequencies which require DFS, their device will get not approved, thus becoming illegal.

If you wish to go illegal and accept full responsibility for your actions, you may obviously choose different region (i think russia has no DFS requirements on any frequency)

Comparison with UBNT doesn't necessary mean anything. If you compare UBNT on 5180 with mikrotik on 5260, then obviously you will see DFS in action on mikrotik but not on UBNT. Often I see people comparing stuff without context and without taking all variables into account.

pe1chl · Fri May 18, 2018 10:28 am

Comparison with UBNT doesn't necessary mean anything. If you compare UBNT on 5180 with mikrotik on 5260, then obviously you will see DFS in action on mikrotik but not on UBNT. Often I see people comparing stuff without context and without taking all variables into account.

Of course I am not comparing like that!
I am comparing putting up a MikroTik and a Ubiquiti access point at a high tower (see photos of towers) and then seeing the MikroTik chasing all around the channels and never staying on a channel for more than a few minutes before detecting radar again and choosing a different channel (with associated DFS wait), and the Ubiquiti finding radar on maybe a couple of channels but staying on other channels just fine without detecting any radar.
And this is not a MikroTik-specific issue either! In the past I used TranZeo equipment as well, and they sold a couple of different hardware designs all under the same TR5a label, where the first design worked absolutely stable under all firmware releases and the second one on the same location after some firmware release just would not link anymore, only radar detected all the time. And those were not so easy to downgrade....
I think it is a matter of combination of hardware and software. Probably the hardware (the radio) has some detection of pulses that results in some interrupt that is associated with a couple of register values like amplitude and duration of the detected pulse, and the software has to evaluate those, apply decision levels and/or do some filtering (ignore a single pulse but act on repeated pulses), and the quality of that software varies between manufacturers and software releases. Maybe they sometimes tweak the software after having some difficulty getting it type-approved in some country, and when the thresholds were lowered the users suffer.
Quality of the radio front-end could also be part of the issue. When the radar is quite local and causes a large signal on the channel where it is operating, this may overwhelm the receiver and cause detected radar pulses on more than one or even on all available channels. Thus the same software algorithm could still behave differently in different AP designs.
Solving the issue is complicated by the lack of debugging tools and tracing information. If only there would be some table of observed radar events and some of the values the hardware has returned and how the software has acted upon them, it could be possible to research what is going on.

honzam · Tue Dec 18, 2018 11:23 pm

Problem with DFS is back with all new versions:

What's new in 6.44beta50 (2018-Dec-17 13:01):
*) wireless - fixed conformity with EU regulatory domain rules;

It is not possible set Superchannel in EU

muetzekoeln · Wed Dec 19, 2018 2:16 pm

How does RouterOS handle DFS radar detections? Is there something like "zero wait DFS" (https://avm.de/fritz-labor/fritz-labor- ... -wait-dfs/)?

RouterOS could do continuous background scanning to find "available" and "unavailable" channels (https://www.etsi.org/deliver/etsi_en/30 ... 20007a.pdf). On radar detection it could (randomly) choose a new channel from the available channels and inform clients of the frequency change (802.11v ??) before shutting down current operational channel and switch to the new channel.

How is it done in 6.43 resp. 6.44?

mistry7 · Wed Dec 19, 2018 2:27 pm

How does RouterOS handle DFS radar detections? Is there something like "zero wait DFS" (https://avm.de/fritz-labor/fritz-labor- ... -wait-dfs/)?

RouterOS could do continuous background scanning to find "available" and "unavailable" channels (https://www.etsi.org/deliver/etsi_en/30 ... 20007a.pdf). On radar detection it could (randomly) choose a new channel from the available channels and inform clients of the frequency change (802.11v ??) before shutting down current operational channel and switch to the new channel.

How is it done in 6.43 resp. 6.44?

Not supported in ROS

pe1chl · Wed Dec 19, 2018 3:24 pm

The issue is probably caused by communication with authorities about DFS detection thresholds.
Above I mentioned a couple of times that Ubiquiti does not suffer from this issue. However, that is no longer correct.
The latest firmware from Ubiquiti has the same problem as MikroTik has had for quite some time: spurious detection of radar on channels where it isn't present.
On both their old 802.11n line and their current 802.11ac line of products the issue arised in the latest version.
"Engineers are looking into it" but they are doing that already for ~3 months and no new release that fixes it has appeared yet.

muetzekoeln · Wed Dec 19, 2018 4:26 pm

authorities about DFS detection thresholds

I found some interesting information about this:
https://mentor.ieee.org/802.18/dcn/08/1 ... ch2008.ppt
https://www.nts.com/resources/Dynamic%2 ... 20Band.pdf
https://mentor.ieee.org/802.11/dcn/09/1 ... epaper.pdf

janos66 · Thu Feb 13, 2020 11:40 pm

I still have similar issues to this day with my two SXT 5nD r2 P2P lines (currently running RoS 6.46.3):
The known relevant weather radars (according to the official local website) are at 5625, 5610, 5640 MHz
My current scan list is 5480-5600-20 and 5660-5720-20
And this is a sample log from one of the SXTs (the other SXT is on the same pole but looking into a very different direction and behaves similarly):

feb/12 18:08:01 wireless,info wlan1: radar detected on 5540000
feb/12 18:08:22 wireless,info wlan1: radar detected on 5580000
feb/12 18:36:39 wireless,info wlan1: radar detected on 5520000
feb/12 18:53:23 wireless,info wlan1: radar detected on 5700000
feb/12 19:58:31 wireless,info wlan1: radar detected on 5540000
feb/12 20:03:01 wireless,info wlan1: radar detected on 5580000
feb/12 20:27:33 wireless,info wlan1: radar detected on 5520000
feb/12 20:39:40 wireless,info wlan1: radar detected on 5660000
feb/12 21:12:36 wireless,info wlan1: radar detected on 5540000
feb/12 21:15:20 wireless,info wlan1: radar detected on 5580000
feb/12 22:16:07 wireless,info wlan1: radar detected on 5500000
10:11:08 wireless,info wlan1: radar detected on 5540000
10:11:13 wireless,info wlan1: radar detected on 5580000
10:24:47 wireless,info wlan1: radar detected on 5500000
10:29:54 wireless,info wlan1: radar detected on 5660000
3:50:02 wireless,info wlan1: radar detected on 5700000
20:03:43 wireless,info wlan1: radar detected on 5540000
21:11:03 wireless,info wlan1: radar detected on 5520000
22:00:01 wireless,info wlan1: radar detected on 5540000

I cared to collect a longer log (I just recently updated, that's why this one is so short) some time ago and plotted the dots in excel. Basically all the legally possible frequencies showed a radar at some point within ~24 hours. There are no airports, military bases or other such facilities around (at least which I could know of). It's a small town in a region consisting of small towns separated by big farming lands and a few small cities. According to SSID scans, there is relatively little wireless communication going on in this airspace (coax cable based internet is readily available and cheap as well as mobile LTE, so there is not a big market for 5GHz wireless internet. This is my personal wireless LAN and the other SSID names indicate similar 'mates' in the air [I recognize the company names, those are probably lines between home and remote offices or homes and farms...]).

mikrotikedoff · Thu Feb 13, 2020 11:56 pm

@janos66

Have you tried taking a spectrum analyzer to the site and see if you can detect interfering transmissions that coincide with your drops? Could also then use it to hunt the source of the interference with a directional antenna.

janos66 · Thu Mar 12, 2020 3:06 am

@janos66

Have you tried taking a spectrum analyzer to the site and see if you can detect interfering transmissions that coincide with your drops? Could also then use it to hunt the source of the interference with a directional antenna.

No. As I stated earlier these two PtP links are only for personal use and pretty much all the outdoor radio equipment I have, so I don't have an analyzer and I don't even have an idea where I could borrow one for a reasonable price.
I wonder if some radios using proprietary protocols (like TDMA, etc) could trigger this (might even deliberately to make room for themself in the air). I don't think it's illegal to simulate fake radar patterns (and even then, some people wouldn't care).
Adaptive noise immunity (ap and client mode) and RTS/CTS (with threshold 0) doesn't seem to make any difference. May be I will try switching to NV2. The last time I tested it (a few years ago), it seemed inferior in all aspects (synthetic throughput tests, average latency, link stability [higher txpower was needed to bring and keep the link up], etc). But may be it's less prone to this kind of noise (compared to it's average performance).

Edit: No, NV2 makes no difference in this regard.

twilight · Wed Apr 22, 2020 10:54 pm

I can see the current state of "detecting-radar" but am not able to see this info in the logs. Why is that? Using Mikrotik Caps.

usmany · Mon Aug 10, 2020 11:13 am

Hi All,

I can see this problem is old news without a solution to all, even Normis and Mikrotik.

I got the problem solved on my own and my own way as you see on attached file. Since I made the country change, i stop getting the radar detection and the link is running nicely and smoothly fine.

Guys, try change the country okay!

CZFan · Mon Aug 10, 2020 1:12 pm

Hi All,

I can see this problem is old news without a solution to all, even Normis and Mikrotik.

I got the problem solved on my own and my own way as you see on attached file. Since I made the country change, i stop getting the radar detection and the link is running nicely and smoothly fine.

Guys, try change the country okay!

Hmmm, when the authorities shut your link down, then you should revisit your post above

pe1chl · Mon Aug 10, 2020 2:24 pm

There is no reason to believe that country "belgium" would avoid any DFS issues. Belgium has DFS requirement the same as everywhere in Europe.
I was surprised that this topic became active today but not from northwest Europe. Lately we have warm weather and this usually means increased DFS
problems, and indeed this morning some links failed in our network (using Ubiquiti equipment, not MikroTIk) because they detect radar on frequencies
where that normally never happens. This is caused by tropospheric propagation that is common for a high pressure area with warm weather, it will also
affect VHF/UHF TV and Radio reception.

ivicask · Mon Aug 10, 2020 3:25 pm

Radar detection on mikrotik is bullshit i have to change country also in order to avoid it, i even had radar detection in basements where no signal can even penetrate or places where not even remotely radars exists to be detect at first place..Even setting all properly, setting skip DFS or setting "non" radar freqs manually it would still detect radar and disrupt links..

usmany · Mon Aug 10, 2020 11:33 pm

Hi,

My site still work well without any radar detect error message since i changed country. I have a proof of it as attached.

If any out there has same error of radar, why not give it a try and see if it will work for you as well... just try change it to any country not just Belgium

bpwl · Tue Aug 11, 2020 1:05 am

I can repeat. Belgium has the standard ETSI regulation from Europe. And I did also receive "false positive" radar detects, but found the source as other Mikrotik routers (hAP ac2, wAP ac) where closeby and on a none-DFS frequency. They caused radar detect on higher channels, and those radar detect channels moved up with the set channel. (Harmonics in electronics are well known, and devices do emit radiation on offset frequencies.) They where all laying switched on on a table, while preparing for an installation.

For this post and the screenshots. If the frequency selection is on "Auto", you don't know what you are testing. At least in Belgium/ETSI, ALL outdoor frequencies are DFS.

pe1chl · Tue Aug 11, 2020 10:35 am

And I did also receive "false positive" radar detects, but found the source as other Mikrotik routers (hAP ac2, wAP ac) where closeby and on a none-DFS frequency. They caused radar detect on higher channels, and those radar detect channels moved up with the set channel. (Harmonics in electronics are well known, and devices do emit radiation on offset frequencies.) They where all laying switched on on a table, while preparing for an installation.

I can confirm that when MikroTik AP receive a strong signal from nearby, they will "mirror" the signal on another channel. It possibly is IF mirror or other overdriving.
E.g. on one of our accesspoints where we have 4 times 912UAG-5PHnD with 4 sector antennas, on a scan we receive the other 3 AP at -27dBm and there are mirrors at -75dBm
e.g. the AP transmitting on 5580 is also received at 5500. That could in radio world mean that the IF is 40 MHz. But that likely is not the case. It could also be there
is a 40 MHz product (e.g. a crystal oscillator) that somehow mixes in the frontend.
This issue makes the false detection of radar more likely, at least when it is a strong signal locally.

To indicate the issues caused by tropo: at the moment (temperature 27deg and pressure 1015 hPa) I see another AP in the scan that is 158km away...
(my AP at 220m and the other one at 30m altitude above terrain. profile calc shows that this is very much not a direct sight path, but with this weather the radio waves just bend across the horizon)

bpwl · Tue Aug 11, 2020 11:30 am

I can confirm that when MikroTik AP receive a strong signal from nearby, they will "mirror" the signal on another channel. It possibly is IF mirror or other overdriving.
E.g. on one of our accesspoints where we have 4 times 912UAG-5PHnD with 4 sector antennas, on a scan we receive the other 3 AP at -27dBm and there are mirrors at -75dBm
e.g. the AP transmitting on 5580 is also received at 5500. That could in radio world mean that the IF is 40 MHz. But that likely is not the case. It could also be there
is a 40 MHz product (e.g. a crystal oscillator) that somehow mixes in the frontend.
This issue makes the false detection of radar more likely, at least when it is a strong signal locally.

To indicate the issues caused by tropo: at the moment (temperature 27deg and pressure 1015 hPa) I see another AP in the scan that is 158km away...
(my AP at 220m and the other one at 30m altitude above terrain. profile calc shows that this is very much not a direct sight path, but with this weather the radio waves just bend across the horizon)

Yes. And I remember i could see those extra frequencies with Snooper, with the same MAC address as the original. (Finding the source was easy that way.)

xt22 · Tue Sep 01, 2020 10:41 pm

any luck with this topic?

according to Mikrotik SXT, Duga is probably back online, as I have "radars" on all available frequencies :-/

aug/31 04:04:52 wireless,info wlan1: radar detected on 5580000 
aug/31 06:03:58 wireless,info wlan1: radar detected on 5640000 
aug/31 06:05:00 wireless,info wlan1: radar detected on 5580000 
aug/31 06:05:03 wireless,info wlan1: radar detected on 5700000 
aug/31 06:05:13 wireless,info wlan1: radar detected on 5600000 
aug/31 06:09:44 wireless,info wlan1: radar detected on 5660000 
aug/31 06:12:15 wireless,info wlan1: radar detected on 5680000 
aug/31 06:12:21 wireless,info wlan1: radar detected on 5620000 
aug/31 07:08:37 wireless,info wlan1: radar detected on 5560000 
aug/31 08:14:01 wireless,info wlan1: radar detected on 5640000 
aug/31 08:14:13 wireless,info wlan1: radar detected on 5600000 
aug/31 10:26:37 wireless,info wlan1: radar detected on 5580000 
aug/31 10:28:57 wireless,info wlan1: radar detected on 5640000 
aug/31 10:29:01 wireless,info wlan1: radar detected on 5700000 
aug/31 10:29:31 wireless,info wlan1: radar detected on 5600000 
aug/31 10:33:51 wireless,info wlan1: radar detected on 5660000 
aug/31 10:33:57 wireless,info wlan1: radar detected on 5620000 
aug/31 10:34:05 wireless,info wlan1: radar detected on 5680000 
aug/31 10:48:06 wireless,info wlan1: radar detected on 5560000 
aug/31 10:48:15 wireless,info wlan1: radar detected on 5540000 
aug/31 10:53:54 wireless,info wlan1: radar detected on 5520000 
aug/31 10:53:57 wireless,info wlan1: radar detected on 5500000 
aug/31 11:03:25 wireless,info wlan1: radar detected on 5580000 
aug/31 11:37:58 wireless,info wlan1: radar detected on 5640000 
aug/31 12:32:16 wireless,info wlan1: radar detected on 5580000 
aug/31 12:39:11 wireless,info wlan1: radar detected on 5640000 
aug/31 12:39:16 wireless,info wlan1: radar detected on 5620000 
aug/31 12:39:48 wireless,info wlan1: radar detected on 5700000 
aug/31 12:40:04 wireless,info wlan1: radar detected on 5600000 
aug/31 14:13:15 wireless,info wlan1: radar detected on 5660000 
aug/31 14:14:12 wireless,info wlan1: radar detected on 5640000 
08:12:18 wireless,info wlan1: radar detected on 5580000 
08:22:57 wireless,info wlan1: radar detected on 5640000 
08:23:01 wireless,info wlan1: radar detected on 5600000 
08:23:05 wireless,info wlan1: radar detected on 5700000 
08:23:09 wireless,info wlan1: radar detected on 5620000 
13:41:23 wireless,info wlan1: radar detected on 5660000 
14:03:42 wireless,info wlan1: radar detected on 5640000 
15:32:38 wireless,info wlan1: radar detected on 5580000 
15:34:00 wireless,info wlan1: radar detected on 5640000 
15:35:19 wireless,info wlan1: radar detected on 5600000 
15:35:23 wireless,info wlan1: radar detected on 5620000 
15:35:28 wireless,info wlan1: radar detected on 5700000 
16:19:29 wireless,info wlan1: radar detected on 5660000 
16:22:56 wireless,info wlan1: radar detected on 5640000 
16:26:02 wireless,info wlan1: radar detected on 5600000

this behavior is so annoying and unusable, it is not just changing channels all the time, but every change triggers the stupid 10 min radar detection with the link offline :-/

Knu1 · Mon Mar 15, 2021 2:00 pm

I found this topic while investigating an issue we have with an p2p link between 2 Sxt lite 5.
Since a recent upgrade (I couldn't tell which version we had prior to that) to Ros 6.45.9, we now have multiple deconnections/connections on this link per day. Before that we never had any issues.
While searching in the logs I found this :

mar/11 12:23:59 wireless,info wlan1: radar detected on 5580000 
mar/11 12:23:59 wireless,info E4:8D:8C:B8:09:A3@wlan1: disconnected, disabling 
mar/11 12:25:04 wireless,info E4:8D:8C:B8:09:A3@wlan1: connected, signal strength -39, wants bridge 
mar/11 13:15:23 wireless,info wlan1: radar detected on 5500000 
mar/11 13:15:23 wireless,info E4:8D:8C:B8:09:A3@wlan1: disconnected, disabling 
mar/11 13:16:27 wireless,info E4:8D:8C:B8:09:A3@wlan1: connected, signal strength -41, wants bridge 
mar/11 16:31:16 wireless,info wlan1: radar detected on 5660000 
mar/11 16:31:16 wireless,info E4:8D:8C:B8:09:A3@wlan1: disconnected, disabling 
mar/11 16:32:21 wireless,info E4:8D:8C:B8:09:A3@wlan1: connected, signal strength -39, wants bridge 
mar/11 16:37:48 wireless,info wlan1: radar detected on 5500000 
mar/11 16:37:48 wireless,info E4:8D:8C:B8:09:A3@wlan1: disconnected, disabling 
mar/11 16:47:52 wireless,info E4:8D:8C:B8:09:A3@wlan1: connected, signal strength -43, wants bridge 
mar/11 19:19:33 wireless,info wlan1: radar detected on 5580000 
mar/11 19:19:33 wireless,info E4:8D:8C:B8:09:A3@wlan1: disconnected, disabling 
mar/11 19:20:39 wireless,info E4:8D:8C:B8:09:A3@wlan1: connected, signal strength -39, wants bridge 
mar/12 09:19:39 wireless,info wlan1: radar detected on 5500000 
mar/12 09:19:39 wireless,info E4:8D:8C:B8:09:A3@wlan1: disconnected, disabling 
mar/12 09:29:44 wireless,info E4:8D:8C:B8:09:A3@wlan1: connected, signal strength -42, wants bridge 
mar/12 13:00:40 wireless,info wlan1: radar detected on 5580000 
mar/12 13:00:40 wireless,info E4:8D:8C:B8:09:A3@wlan1: disconnected, disabling 
mar/12 13:01:45 wireless,info E4:8D:8C:B8:09:A3@wlan1: connected, signal strength -39, wants bridge 
mar/12 13:53:34 wireless,info wlan1: radar detected on 5500000 
mar/12 13:53:34 wireless,info E4:8D:8C:B8:09:A3@wlan1: disconnected, disabling 
mar/12 14:03:38 wireless,info E4:8D:8C:B8:09:A3@wlan1: connected, signal strength -39, wants bridge 
mar/12 15:08:12 wireless,info wlan1: radar detected on 5620000 
mar/12 15:08:12 wireless,info E4:8D:8C:B8:09:A3@wlan1: disconnected, disabling 
mar/12 15:09:18 wireless,info E4:8D:8C:B8:09:A3@wlan1: connected, signal strength -40, wants bridge

What puzzles me is that we have a second p2p link, 100 meters from there that does not have this issue.
If that really was an radar, this would affect all links in the area no ?
Both p2p links use the same hardware and same configuration (regulatory-domain etc.).

We changed the channel and will monitor the situation, but after reading all the reports here, I fear this will not fix our issue.

bpwl · Tue Mar 16, 2021 2:22 pm

100m is enough for having false positive radar detects or not.
Even swapping the role: AP versus client can mitigate the false positive radar detect in a P2P. (Only the AP does the radar detect check)
The SXT is directional, so a different direction will influence the radar detection.
The signal received is rather strong (-39 dBm). Maybe reducing the transmit power at the other end will help. Start with al least 20 dBm reduction, and then gradually increment.
Be aware of any other AP or client in the directional view of the SXT.
(I had a wAP and SXT close to each other, and the SXT pointing forward, but slightly in the direction of the wAP. Swapping the 2 devices solved the problem)

xt22 · Tue Jun 22, 2021 1:14 pm

tried to change channel width to 5 and 10MHz, this radar-detection crap is going crazy today :-/

Small powerbridge M5 works well here, I became Russian for a while and problems instantly stopped..

03:23:30 wireless,info wlan1: radar detected on 5575000
03:23:42 wireless,info wlan1: radar detected on 5690000
03:23:56 wireless,info wlan1: radar detected on 5495000
03:25:39 wireless,info wlan1: radar detected on 5505000
03:25:50 wireless,info wlan1: radar detected on 5515000
03:26:06 wireless,info wlan1: radar detected on 5525000
03:26:18 wireless,info wlan1: radar detected on 5535000
03:26:33 wireless,info wlan1: radar detected on 5545000
03:27:29 wireless,info wlan1: radar detected on 5555000
03:29:07 wireless,info wlan1: radar detected on 5565000
03:29:20 wireless,info wlan1: radar detected on 5585000
03:29:33 wireless,info wlan1: radar detected on 5595000
03:29:45 wireless,info wlan1: radar detected on 5605000
03:30:00 wireless,info wlan1: radar detected on 5615000
03:30:18 wireless,info wlan1: radar detected on 5625000
03:46:42 wireless,info wlan1: radar detected on 5635000
03:47:45 wireless,info wlan1: radar detected on 5645000
04:59:37 wireless,info wlan1: radar detected on 5655000
04:59:51 wireless,info wlan1: radar detected on 5690000
05:00:11 wireless,info wlan1: radar detected on 5495000
05:00:36 wireless,info wlan1: radar detected on 5505000
05:00:48 wireless,info wlan1: radar detected on 5515000
05:01:00 wireless,info wlan1: radar detected on 5525000
05:01:12 wireless,info wlan1: radar detected on 5535000
05:01:29 wireless,info wlan1: radar detected on 5545000
05:01:55 wireless,info wlan1: radar detected on 5555000
05:05:04 wireless,info wlan1: radar detected on 5565000
05:05:22 wireless,info wlan1: radar detected on 5575000
05:06:09 wireless,info wlan1: radar detected on 5585000
05:06:22 wireless,info wlan1: radar detected on 5595000
05:06:33 wireless,info wlan1: radar detected on 5605000
05:06:46 wireless,info wlan1: radar detected on 5615000
05:07:00 wireless,info wlan1: radar detected on 5625000
05:13:51 wireless,info wlan1: radar detected on 5635000
05:14:10 wireless,info wlan1: radar detected on 5645000
06:48:27 wireless,info wlan1: radar detected on 5665000
06:49:11 wireless,info wlan1: radar detected on 5690000
06:49:26 wireless,info wlan1: radar detected on 5495000
06:54:45 wireless,info wlan1: radar detected on 5505000
06:54:59 wireless,info wlan1: radar detected on 5515000
06:55:10 wireless,info wlan1: radar detected on 5525000
06:55:23 wireless,info wlan1: radar detected on 5535000
06:55:34 wireless,info wlan1: radar detected on 5545000
06:56:53 wireless,info wlan1: radar detected on 5555000
06:57:56 wireless,info wlan1: radar detected on 5565000
06:58:13 wireless,info wlan1: radar detected on 5575000
06:58:29 wireless,info wlan1: radar detected on 5585000
06:58:40 wireless,info wlan1: radar detected on 5595000
06:58:54 wireless,info wlan1: radar detected on 5605000
06:59:06 wireless,info wlan1: radar detected on 5615000
06:59:17 wireless,info wlan1: radar detected on 5625000
07:07:44 wireless,info wlan1: radar detected on 5635000
07:08:06 wireless,info wlan1: radar detected on 5645000
07:08:19 wireless,info wlan1: radar detected on 5655000
07:08:38 wireless,info wlan1: radar detected on 5675000
08:09:53 wireless,info wlan1: radar detected on 5700000
08:10:05 wireless,info wlan1: radar detected on 5690000
08:10:52 wireless,info wlan1: radar detected on 5495000
08:11:33 wireless,info wlan1: radar detected on 5505000
08:11:46 wireless,info wlan1: radar detected on 5515000
08:11:58 wireless,info wlan1: radar detected on 5525000
08:12:41 wireless,info wlan1: radar detected on 5535000
08:13:11 wireless,info wlan1: radar detected on 5545000
08:13:24 wireless,info wlan1: radar detected on 5555000
08:14:12 wireless,info wlan1: radar detected on 5565000
08:14:28 wireless,info wlan1: radar detected on 5575000
08:15:06 wireless,info wlan1: radar detected on 5585000
08:15:20 wireless,info wlan1: radar detected on 5595000
08:15:33 wireless,info wlan1: radar detected on 5605000
08:15:46 wireless,info wlan1: radar detected on 5615000
08:15:59 wireless,info wlan1: radar detected on 5625000
09:28:56 wireless,info wlan1: radar detected on 5635000
09:29:12 wireless,info wlan1: radar detected on 5690000
09:29:33 wireless,info wlan1: radar detected on 5495000
09:46:38 wireless,info wlan1: radar detected on 5505000
09:46:51 wireless,info wlan1: radar detected on 5515000
09:47:03 wireless,info wlan1: radar detected on 5525000
09:47:17 wireless,info wlan1: radar detected on 5535000
09:47:31 wireless,info wlan1: radar detected on 5545000
09:47:53 wireless,info wlan1: radar detected on 5555000
09:49:07 wireless,info wlan1: radar detected on 5565000
09:51:18 wireless,info wlan1: radar detected on 5575000
09:51:40 wireless,info wlan1: radar detected on 5585000
09:51:53 wireless,info wlan1: radar detected on 5595000
09:52:05 wireless,info wlan1: radar detected on 5605000
09:52:17 wireless,info wlan1: radar detected on 5615000
09:52:31 wireless,info wlan1: radar detected on 5625000
09:53:51 wireless,info wlan1: radar detected on 5645000
10:33:28 wireless,info wlan1: radar detected on 5655000
10:33:41 wireless,info wlan1: radar detected on 5690000
10:33:57 wireless,info wlan1: radar detected on 5495000
10:42:52 wireless,info wlan1: radar detected on 5505000
10:43:06 wireless,info wlan1: radar detected on 5515000
10:43:17 wireless,info wlan1: radar detected on 5525000
10:43:29 wireless,info wlan1: radar detected on 5535000
10:43:46 wireless,info wlan1: radar detected on 5545000
10:43:58 wireless,info wlan1: radar detected on 5555000
10:45:01 wireless,info wlan1: radar detected on 5565000
10:45:28 wireless,info wlan1: radar detected on 5575000
11:10:49 wireless,info wlan1: radar detected on 5585000
11:11:08 wireless,info wlan1: radar detected on 5690000
11:11:32 wireless,info wlan1: radar detected on 5495000
11:11:45 wireless,info wlan1: radar detected on 5595000
11:11:57 wireless,info wlan1: radar detected on 5605000
11:12:09 wireless,info wlan1: radar detected on 5615000
11:12:28 wireless,info wlan1: radar detected on 5625000
11:13:57 wireless,info wlan1: radar detected on 5635000
11:17:08 wireless,info wlan1: radar detected on 5505000
11:17:19 wireless,info wlan1: radar detected on 5515000
11:17:31 wireless,info wlan1: radar detected on 5525000
11:17:43 wireless,info wlan1: radar detected on 5535000
11:17:57 wireless,info wlan1: radar detected on 5545000
11:18:33 wireless,info wlan1: radar detected on 5555000
11:20:26 wireless,info wlan1: radar detected on 5565000
11:21:09 wireless,info wlan1: radar detected on 5575000

xt22 · Fri Nov 12, 2021 12:48 am

ok, so I had to move the SXT 20km from the location it was - I still thought it was a problem of that location.
Well, it wasn't. I have updated to 6.48.5, updated the setup and... yes, stupid radar detections every 2-5 mins resulting to disconnections.

So I have to go Russian again, before I get there with some working hardware and jump on that SXT crap.

xt22 · Thu Jun 30, 2022 5:16 pm

damn.. I hate this stupid behavior, but I could somehow live with the fact that this happens on my p2p outdoor links and use other vendors, we have only a few of those.

But now, this stupid radar detection started on my indoor RBcAP using indoor channel 5260 too :-/ The nearest radar is 100km from here.
I have the latest longterm 6.48.6. Going russian does not work, "no country set" cannot be selected.

Anyone has any working solution? i don't care about selecting different country, disabling the whole DFS crap, whatever,
we have hundreds of RBcAPs and if they will work as bad as SXTs do, I'll have to replace all of those for a different vendor,
every radar detection disabled the 5GHz wifi for ~10 mins, this will be a serious problem for us

erlinden · Thu Jun 30, 2022 5:23 pm

Why don't you use non DFS channels?
You might want to check newer RouterOS version.

bpwl · Thu Jun 30, 2022 9:16 pm

The nearest radar is 100km from here.

In 99% of my cases the "radar detected" had nothing to do with any radar. It were false positives (the wifi signal has a radar signature somehow, due too receiver saturation or other non-linearities in the processing?) Reflection of own signal or other wifi signal had to be removed. It also often occurs at power-on of some AP's in the environment.

5180 till 5240 are non DFS (but indoor only). In some regions the 5745 and higher freq are non-dfs. (and outdoor, and high EIRP, but not allowed in Europe)

Never tought that using smaller bandwith than 20 MHz could be any good on radar (signature) detect avoidance, and test time spent.
10 minutes mute is only for the wheater rader freq : 5600-5620 and 5640. Avoid those channels!

SXTs are very directional, and do amplify the received signal with 16dBi. Use the directional characteristic to avoid other transmitters nearby being in focus.
Swapping bridge and station mode in the SXT-SXT link can help avoid false-positive radar detection.

xt22 · Fri Jul 01, 2022 12:56 am

erlinden: I will try, I could not experiment much as there was a meeting running, it was just a very unpleasant surprise on a indoor ap with integrated low-gain antennas,
I have never seen this on a RBcAP

bpwl: yes, it is indoor ap running on indoor freqs, this one https://mikrotik.com/product/cap_ac
I will try the lower non-DFS, hopefully they'll be free and it will work. I haven't seen any effect while changing bandwidth too.

I gave up using SXTs and threw them away, I have some old Powerbridge M5s and those work everywhere Mikrotik had constant radar detects.
A customer showed me some old home crap TP-Link ptp link and guess what? Worked like a charm too. Where I really needed Mikrotik, I used 60GHz
that works ok, but I don't want to see any 5GHz ptp from Mikrotik ever again.

I'll try the lower non-DFS channels for now, thanks

bpwl · Fri Jul 01, 2022 1:40 am

Why don't you use non DFS channels?
You might want to check newer RouterOS version.

Or maybe just older versions.
viewtopic.php?t=186707#p939311

Mandatory radar detect capability tends to be more restrictive over time. Device builders get more requirements to have their new devices certified.

So indeed some "old" devices, or just old firmware releases might have no "Radar detected" problems, or even have the possibility to suppress DFS requirements.

xt22 · Fri Jul 01, 2022 12:25 pm

Or maybe just older versions.

I'm using longterm on all devices except chateaus, currently 6.48.6.
i remember there was an option to use "No country set" in some really old longterm version (6.37.10?),
then there was a possibility to select different country (russia) later that worked, bud since around 6.43,
real problems started.

It's a shame that stupid DFS law does not force radars to include some beacon, containing id, position and frequency :-/
Anyway, Mikrotik has worse issues with radars than others, as far as I can tell

pe1chl · Fri Jul 01, 2022 2:06 pm

Anyway, Mikrotik has worse issues with radars than others, as far as I can tell

That for sure is true. But others are not free from issues either, and a basic principle for outdoor wifi certainly is: when it works, never update the firmware.
I have seen several occasions with at least 3 other brands of equipment where it worked fine before and got in trouble after an upgrade. In one of them, downgrading was not easy.
It has happened with UBNT stuff as well, but fortunately you can downgrade that.

The problem of course is that the manufacturers receive nasty letters from local regulators telling them to fix their DFS. They send those letters after receiving complaints about interference from the weather institutions.
Manufacturers have to do something or they lose access to the market. But unfortunately, it leaves their customers in despair.

The problem is usually worse in summer when there is tropospheric ducting and far more chance to receive spurious transmissions from far away.

xt22 · Fri Jul 01, 2022 4:46 pm

Agreed. I don't know, what is the law ordering vendors to do and if it is technically specific or lets vendors just fulfill what it says by their solution, but I definitely know it should not work like this and I'm nearly certain there are not radars on all available frequencies (the nearest one is ~100km away btw), leaving none for the ptp link to live - I have posted the log from my SXT before:

aug/31 04:04:52 wireless,info wlan1: radar detected on 5580000 
aug/31 06:03:58 wireless,info wlan1: radar detected on 5640000 
aug/31 06:05:00 wireless,info wlan1: radar detected on 5580000 
aug/31 06:05:03 wireless,info wlan1: radar detected on 5700000 
aug/31 06:05:13 wireless,info wlan1: radar detected on 5600000 
aug/31 06:09:44 wireless,info wlan1: radar detected on 5660000 
aug/31 06:12:15 wireless,info wlan1: radar detected on 5680000 
aug/31 06:12:21 wireless,info wlan1: radar detected on 5620000 
aug/31 07:08:37 wireless,info wlan1: radar detected on 5560000 
aug/31 08:14:01 wireless,info wlan1: radar detected on 5640000 
aug/31 08:14:13 wireless,info wlan1: radar detected on 5600000 
aug/31 10:26:37 wireless,info wlan1: radar detected on 5580000 
aug/31 10:28:57 wireless,info wlan1: radar detected on 5640000 
aug/31 10:29:01 wireless,info wlan1: radar detected on 5700000 
aug/31 10:29:31 wireless,info wlan1: radar detected on 5600000 
aug/31 10:33:51 wireless,info wlan1: radar detected on 5660000 
aug/31 10:33:57 wireless,info wlan1: radar detected on 5620000 
aug/31 10:34:05 wireless,info wlan1: radar detected on 5680000 
aug/31 10:48:06 wireless,info wlan1: radar detected on 5560000 
aug/31 10:48:15 wireless,info wlan1: radar detected on 5540000 
aug/31 10:53:54 wireless,info wlan1: radar detected on 5520000 
aug/31 10:53:57 wireless,info wlan1: radar detected on 5500000 
aug/31 11:03:25 wireless,info wlan1: radar detected on 5580000 
aug/31 11:37:58 wireless,info wlan1: radar detected on 5640000 
aug/31 12:32:16 wireless,info wlan1: radar detected on 5580000 
aug/31 12:39:11 wireless,info wlan1: radar detected on 5640000 
aug/31 12:39:16 wireless,info wlan1: radar detected on 5620000 
aug/31 12:39:48 wireless,info wlan1: radar detected on 5700000 
aug/31 12:40:04 wireless,info wlan1: radar detected on 5600000 
aug/31 14:13:15 wireless,info wlan1: radar detected on 5660000 
aug/31 14:14:12 wireless,info wlan1: radar detected on 5640000 
08:12:18 wireless,info wlan1: radar detected on 5580000 
08:22:57 wireless,info wlan1: radar detected on 5640000 
08:23:01 wireless,info wlan1: radar detected on 5600000 
08:23:05 wireless,info wlan1: radar detected on 5700000 
08:23:09 wireless,info wlan1: radar detected on 5620000 
13:41:23 wireless,info wlan1: radar detected on 5660000 
14:03:42 wireless,info wlan1: radar detected on 5640000 
15:32:38 wireless,info wlan1: radar detected on 5580000 
15:34:00 wireless,info wlan1: radar detected on 5640000 
15:35:19 wireless,info wlan1: radar detected on 5600000 
15:35:23 wireless,info wlan1: radar detected on 5620000 
15:35:28 wireless,info wlan1: radar detected on 5700000 
16:19:29 wireless,info wlan1: radar detected on 5660000 
16:22:56 wireless,info wlan1: radar detected on 5640000 
16:26:02 wireless,info wlan1: radar detected on 5600000

mkx · Sat Jul 02, 2022 4:09 pm

The problems started when FCC allowed to use radar frequencies for anything else. The regulation (DFS and what not) was similar from day one, it's only that WiFi vendors did shitty job implementing them, result of which upset "legitimate" users of those frequencies ... and it took a while before FCC (and the rest of regulators) started to send out those letters. Not because legitimate users didn't complain but because FCC works like MT: they waited too long so that problem became a big one, only then they reacted.

And no, radar "fingerprints" are not possible most of times and crappy devices that typical APs are wouldn't be able to pick them up anyway.

So stop complaining and make sure your devices run on non-DFS channels only. That's the only solution.

pe1chl · Sat Jul 02, 2022 4:36 pm

So stop complaining and make sure your devices run on non-DFS channels only. That's the only solution.

But on non-DFS channels we (outside FCC territory) are allowed only 1/5th of the power. So for outdoor use you normally don't want to use those.

bpwl · Sat Jul 02, 2022 5:24 pm

"etsi" (Europe) does not allow for non-DFS outdoor. Only the first 4 channels (36-40-44-48) are non-DFS and those are allowed indoor only.

Etsi is 1/10th of FCC TX Power for most of the frequencies. (20dBm versus 30 dBm). And 27dBm for DFS channel 100 and up.

Problem is also that local client (station) device is using the ETSI frequencies. So setting ETSI2 as country, as it ''sounds' correct, is strickly speaking illegal, and does not have the original ETSI frequencies.

Some homework to be done. "/interface wireless info country-list". e.g. Country 'debug' is low power only.

anav · Sat Jul 02, 2022 5:28 pm

I never see this issue on my non-mt business APs??? Not that I have ever noticed it on my capacs either though!!
Perhaps moving to Canada would be best.

mkx · Mon Jul 04, 2022 3:14 pm

So stop complaining and make sure your devices run on non-DFS channels only. That's the only solution.
But on non-DFS channels we (outside FCC territory) are allowed only 1/5th of the power. So for outdoor use you normally don't want to use those.

Well, life sucks and home wifi users are not the most important RF spectrum users in the known universe. As I said, it's take it or leave it, either way don't complain.

jbl42 · Mon Jul 04, 2022 9:47 pm

Anyway, Mikrotik has worse issues with radars than others, as far as I can tell

Absolutely. In noisy environments, MikroTik APs tend to "detect" radars all over the place and constantly jump DFS channels. There are many complaints about this in the forum.
If non-DFS schannels are not an option, there is currently no other way than to use other brand business APs in such places.

infabo · Sun Mar 26, 2023 1:52 am

I haved wondered about "radar detected on (frequency)" that occured in the log. Now I have found out the reason: when I turn off wifi on my Huawei Mediapad M5 tablet and in the same second I turn wifi on again - I see the log entry about detected radar. Quite unreliable this DFS stuff. This behaviour is reproducible. I am unsure whether I should report to support or not.

pe1chl · Sun Mar 26, 2023 12:08 pm

It is a common problem, with all manufacturers. I explained in reply #72 the situation the manufacturers find themselves in.

r00t · Sun Mar 26, 2023 5:40 pm

Main problem is that the radar detection is by definition completely unreliable and prone for false positives. There is no definite ID that would identify signal as radar. It's something as simple as "if there's 10 pulses of signal on the frequency spaced X ms apart, radar is detected". That's why it keeps being triggered by other non-wifi devices that use same ISM band. You can google the exact criteria for testing of radar detection feature for compliance, they are pretty strict and it's possible some regulator forced Mikrotik to be even more strict (we will never know).
Situation will be better in like 10 years when all devices will likely have WIFI6E, but right now only fix is to choose non-DFS channels that are usually too full and there's not many of them... or run WIFI in non-compliant way.

David2X · Mon Jan 08, 2024 10:40 pm

I'm having the same problem. Mikrotik logs following message:

19:37:32 wireless,info wlan1: radar detected on 5640000

and disconnect every device on 5Ghz WiFi.

I'm not sure if it is false positive or not. But I'm using Frequency 5180Mhz with Channel Width 80Mhz and in Europe this range even shouldn't be considered as DFS channel.

Why is this happening and what can I do about it?

bpwl · Tue Jan 09, 2024 11:17 am

19:37:32 wireless,info wlan1: radar detected on 5640000
and disconnect every device on 5Ghz WiFi.
But I'm using Frequency 5180Mhz with Channel Width 80Mhz

Well the log says you are using the 5640MHz channel . What is reported in the interface "status" ?
5180MHz is for indoor use only. (Set installation to "any" or "indoor".)
Did the device not accept your 5180MHz setting? (outdoor only devices like SXTsq, SXT SA5, Omnitik ac, LHG and other) , or config with "installation" set to outdoor

5180MHz is non-DFS, so the MT should not change the freq on its own, looking for another channel.

David2X · Wed Jan 10, 2024 10:37 pm

19:37:32 wireless,info wlan1: radar detected on 5640000
and disconnect every device on 5Ghz WiFi.
But I'm using Frequency 5180Mhz with Channel Width 80Mhz
Well the log says you are using the 5640MHz channel . What is reported in the interface "status" ?
5180MHz is for indoor use only. (Set installation to "any" or "indoor".)
Did the device not accept your 5180MHz setting? (outdoor only devices like SXTsq, SXT SA5, Omnitik ac, LHG and other) , or config with "installation" set to outdoor

5180MHz is non-DFS, so the MT should not change the freq on its own, looking for another channel.

Thanks for response.

It is used indoors so installation is set to "indoor".

ok ... status is: 5180/20-Ceee/ac/P(20dBm)+5670/80/DP(24dBm)

Looks like I've set frequency to 5180MHz but secondary channel was set to auto. So that looks to be reason why it could be using 5640MHz channel.

mkx · Thu Jan 11, 2024 8:17 am

Looks like I've set frequency to 5180MHz but secondary channel was set to auto. So that looks to be reason why it could be using 5640MHz channel.

I'd unset secondary frequency ... it's only used for non-contiguous 80+80 MHz channel width ... not many clients support that kind of channel layout so it's likely you're only wasting Tx power. And since secondary frequency is on DFS channel, it can happen that AP is turning it off occasionally (or frequently), not sure if that affects primary (main) frequency as well.

Who is online