MikroTik

Firmware 6.37.1 - 6.38.5 : Country set Czech republic.
If AP detect radar and /or is set to frequency 5600 - 5660. it SOMETIMES broadcast at frequerncy 5775, which is out of Czech norm and violates CTU rules !!! It leads to penalties and severe problems !!!
Country on AP is set to Czech republic. Though setting in folder Interface --> Wireless shows 5600 MHz, Status shows 5775 MHz, same as connected clients !!! It works but at wrong frequency ! Its severe BUG in firmware !!! Plaease correct it ! It leads to punishment from the authorities and the financial penalties !!! SEVERE PROBLEM !!!!

It is not bug. You need use scan list. If mikrotik detect radar, then retune anywhere. If you define scan list 5500-5700 everything will be fine.
Není to chyba. Mikrotik detekuje radar a pak se přeladí kamkoliv kde je "volno". Kam se může přeladit je potřeba nadefinovat ve scan listech 5500-5700

English only please. Rewrite your answer in English. Take this as warning. Thank you for understanding.

It is not bug. You need use scan list. If mikrotik detect radar, then retune anywhere. If you define scan list 5500-5700 everything will be fine.

Of course it s a BUG ! If I set manually any concrete frequency AP ccanot do what it randomly will ! Especially, if I set it to a frequency, where radar cannot occure in Czech republic = 6680 MHz ! Especially, if the new freguency is out of range allowed in Czech republic, if correct country is set in "Country" box! Let it "detect radar" witnout going to AP mode endless time, but CANNOT use frequency not allowed in settings! It behaves like I choosed "auto" in "frequency" box. It is wery wierd behawior if in one folder (Wireless) is set and diplayed 6680 MHz and in other (Status) is displayed (and really broadcasted) 7775 MHz ! Logical nonsense!

Mikrotik please repair this BUG, as otherwise box "Country" has no meaning, if everybody has to create and maintain scan list, instead of simple choosing "Country" ...

This is not a bug. czech republic allows 5725-5875MHz for A/N/AC at up to 14dBm for fixed point-to-point links. It is your responsibility to set the scan list to the range that is legal for your use. If MikroTik blocked that range, then someone would be upset that it was blocked, because they need it for fixed wireless.

Again, it is your responsibility to set the scan list to what is legal for your use, and then if you want a specific channel, you will need to then set that frequency. However, if you DO NOT set the scan range, if it detects an issue on the channel you want, it will use the best available for the legal range, which is 5170-5710 & 5725-5875.

Again, it is your responsibility to set the scan list to what is legal for your use, and then if you want a specific channel, you will need to then set that frequency. However, if you DO NOT set the scan range, if it detects an issue on the channel you want, it will use the best available for the legal range, which is 5170-5710 & 5725-5875.

Again: What you wrote is acceptable, IF I set into freguency field "auto" NOT if I set right on single concrete frequency there ! Do you understand ? In current state the item "auto" in frequency box is obsolete, if Mikrotik uses ramdomly "auto" whenever it want according to wierd algorithm in backgroud ! Even if I shrink in "frequency" list frequencies to 5500-5700, channel jumps as it likes randomly in this range under some (not exacty known) conditions ... After that item Frequency in folders "Wireless" and " Status" are not consistent and user is not able to quarantee on which frequency his AP will broadcast ! I consider it totally wrong, if AP is out of control such way... If i will want automatic channel choice, then let me set "auto" instead of frequency. After that, let frequency jumps in given range and respect "Contry" rules. But in cities with over 150 AP on Scan list is automatic totally unusable and if not switchable OFF, then is Mikrotik obsolete... Whole time is only jumping over frequencies, finding "better" channel but it does not exist or will still change according to automatics on other APs in range... IF all will allow automatic, free frequency space will became totally unusable due cyclic changing frequencies at all APs....

The trouble is, when radar is detected, AP can either stop broadcasting or jump to another channel. Random jumping is bad, but not broadcasting at all is not any better, who would want that? And even if your own AP won't be jumping, other will, so it will suck either way. Forced DFS was not MikroTik's idea, but if it can detect radars on channels where there are none, it's very very bad... Maybe MikroTik could try that Volkswagen thing, i.e. DFS would work only when CTU comes for inspection and not make your life miserable otherwise.

You can still set superchannel mode or no country set or select any other country that fits your needs better...

Again: What you wrote is acceptable, IF I set into freguency field "auto" NOT if I set right on single concrete frequency there ! Do you understand ? In current state the item "auto" in frequency box is obsolete, if Mikrotik uses ramdomly "auto" whenever it want according to wierd algorithm in backgroud !

While I agree this is weird and undesirable, it is how the AP is supposed to operate within the standard and license conditions. It is not a MikroTik invention, all legal APs do this.
However what you need to clarify is why it is illegal to transmit on 5775. Is this a local convention, are there different license conditions going around, is it your own preference?
When there is incorrect data in the country channel table it of course is a bug and has to be corrected, but I think there has to be evidence e.g. from a CTU website.

You can still set superchannel mode or no country set or select any other country that fits your needs better...

If you read versions changelog, DFS and radar detect is obligatory since some 6.x version. Bug is, when Mikrotik detect radar even at frequencies, where is none. Some strange AP or client can trigger it, i don´t know... Sometimes of course, not regular.
Due to 802.11 protocol, Superchannel is out of play. Background scanning does not support it and it is required as first help in interferrenced space... Other countries is no solution... Its very bad suggest for those, who donť know anythink about CTU rules... What about normally behavior of device, when reguired 5520 MHz at Wireless folder will give output 5520MHz at antenna? And when auto = jumping over in country allowed channels, resp. more shrinked by channel list ? Of course more counry specifications will be needed, for Czech rep.e.g indoor channels, outdoor channels, special services channels... Or best again: Allow manually set one concrete channel, choosed by user, detect radar only at frequencies, that can occur. In Czech rep, it is: 5645 MHz and 5635 MHz.
Then, at some localities, channels 5640 and/or 5660 MHz are unusable and should be aviod. Here is actual online table of radar jammers in Czech republic: http://radar4ctu.bourky.cz/Ruseni.html

..., detect radar only at frequencies, that can occur. In Czech rep, it is: 5645 MHz and 5635 MHz.

It's not so simple. If you're somewhere in the middle of CR, you probably only need to worry about these two. But if you're somewhere closer to border, there are also radars from neighboring countries. And they won't be happy either, if your device makes pretty pictures on their screens.

Sure I do care about ČTÚ. It looks so far my links are working fine even when dfs is in place. I am using regulatory domain everywhere and even setting antenna gain values much higher to lower the tx power at lowest reliably working level. I wish everyone was doing the same...

It's not so simple. If you're somewhere in the middle of CR, you probably only need to worry about these two. But if you're somewhere closer to border, there are also radars from neighboring countries. And they won't be happy either, if your device makes pretty pictures on their screens.

Sob, especially in Czech rep. i do not worry a bout foreign radars, as Czech rep is a nice bowl with mountains on the outskirts, shielded from radar neighboring countries. There are rare places, where could be affected radars eg. in Austria or Slovak rep. If automatic detectin doesn´t work well, then must be ability to switching it off manually as it was before.. Or Mikrotik will became an unusable piece of hardware. Next "solution" could be return to old firmwares, where where DFS could be swithed off... But debugging and new features will be lost.

Sure I do care about ČTÚ. It looks so far my links are working fine even when dfs is in place. I am using regulatory domain everywhere and even setting antenna gain values much higher to lower the tx power at lowest reliably working level. I wish everyone was doing the same...

Sure it works at village ... but not in cities. You probabaly have not such site survey (and this is not complete yet ! )

Nice catch.
I would have the same if I had an omni antenna on top of my house... But I am not doing that. I am using as narrow antennas as much I can in order to be shielded away from this. Also because of that I have only about 20 SSIDs on my 5G antennas at rural places.

Unfortunatelly there are some places in the middle of the big houses (in Prague) where I can scan 50 ssids on hap lite (2G band!). Looks like UPC does not care at all about their "super powerful modems" that they provide to the customers... Five bars - the best internet ever...

If automatic detectin doesn´t work well, then must be ability to switching it off manually as it was before.. Or Mikrotik will became an unusable piece of hardware. Next "solution" could be return to old firmwares, where where DFS could be swithed off... But debugging and new features will be lost.

Enabling DFS is required to comply with legal regulations, which is usually a requirement to import equipment legally.
You see this in all recently released equipment and software, and in the USA the requirements are even stricter than here.
(which indicates that it could change here as well when ignorant people keep jamming weather radar)

On the other hand, the detection of radar, which is partly a hardware function, is not working well, not in current and not in past firmware.
This weekend I have updated some outdoor AP's from 6.29.1 and 6.32.1 to 6.37.5 and in all cases I had to go to superchannel mode because they would jump to indoor channels when selecting the regulatory-domain mode and country netherlands. Before, they had DFS disabled for the same reason but now that is no longer possible.

There's definitely a bug with DFS in recent versions, Apple devices in particular cause spurious radar detections. The RC is supposed to fix this, after upgrading I've had one more radar detect (I used to never get any - indoor use) so it improved but it's not perfect.

There's definitely a bug with DFS in recent versions, Apple devices in particular cause spurious radar detections. The RC is supposed to fix this, after upgrading I've had one more radar detect (I used to never get any - indoor use) so it improved but it's not perfect.

Probably it is now back to the state it has been in for years? I can try it later, preferably when the version is released, but I guess it will not work at our site.
No version has ever worked there. It always has been randomly hopping. The radar (which is clearly visible on the spectrum view of a Ubiquiti AP) is very
strong and it is wrongly detected on all but the low indoor-only channels, where we cannot legally transmit outdoor.
(there should be an indoor/outdoor selection option somewhere...)

It is not possible to setup Mikrotik with country Czech republic and regulatory domain and then access point after radar detection will tune outside 5500-5700 Mhz - this is outdoor range allowed in CZ... many ISP are not aware of it and after upgrade could pay fines, because of indoor range frequencies will be in use.

many ISP are not aware of it and after upgrade could pay fines

They should read ChangeLogs and do some testing before upgrade. It's their own fault if they don't do that.

What's new in 6.37 (2016-Sep-23 08:20):

...

--- IMPORTANT! DFS CHANGES:

DFS configuration in RouterOS has been redesigned, now device looks at specified country settings (/interface wireless info country-info), and applies corresponding DFS mode for each frequency range automatically, making dfs-mode setting unnecessary.

Please, check that your frequencies work with corresponding DFS settings before upgrade.

We were able to detect the false radar detection - iPhone 6s were triggering the DFS. We were able to fix it. Current RC version (v6.39rc58) contains a fix for that.
And in the next RC version which we will release soon we have finetuned that detection even better.

We were able to detect the false radar detection - iPhone 6s were triggering the DFS. We were able to fix it. Current RC version (v6.39rc58) contains a fix for that.
And in the next RC version which we will release soon we have finetuned that detection even better.

Note that there are two other issues mentioned:
- DFS making the AP hop from a DFS to a non-DFS (indoor) channel. Has it been fixed?
- DFS detecting radar that is on another channel (not an iPhone but a real radar). This is a problem that has existed at least since 6.29 and probably before that.

- DFS making the AP hop from a DFS to a non-DFS (indoor) channel. Has it been fixed?

DFS only hops to other channels in the scan-list. If you don't set up your scan-list correctly for indoor or outdoor use, you're going to have a bad time.

There are also some special country codes you can use to get "only outdoor" channels, for example "etsi 5.5-5.7 outdoor" (Europe).

You can get all the necessary information about these country settings on the CLI: '/interface wireless info country-list' and '/interface wireless info country-info "some-country-from-that-list"'

Those are all workarounds for firmware bugs or omissions.
A compliant AP has an indoor/outdoor setting and hops only between DFS channels.
In fact, limiting the DFS scan range using a scan list is explicitly disallowed in the regulations.

In fact, limiting the DFS scan range using a scan list is explicitly disallowed in the regulations.

Do you mean "4.2.6.2.7 Uniform Spreading" in Final draft ETSI EN 301 893 V2.1.0 (2017-03)?

We were able to detect the false radar detection - iPhone 6s were triggering the DFS. We were able to fix it. Current RC version (v6.39rc58) contains a fix for that.
And in the next RC version which we will release soon we have finetuned that detection even better.

Note that there are two other issues mentioned:
- DFS making the AP hop from a DFS to a non-DFS (indoor) channel. Has it been fixed?
- DFS detecting radar that is on another channel (not an iPhone but a real radar). This is a problem that has existed at least since 6.29 and probably before that.

The first issue happened to me also. After creating a new scanlist this was solved. Since the installation is outdoor, I've made a scanlist with only the allowed channels for outdoor usage.

Now I have sometimes a DFS hit and the AP doesn't find any available channel.. -> AP gone. Switching back to the default scan list at least re-establishes the link, but as mentioned.. sometimes jumping back to indoor channels.

The false radar detections... I'm definitely going to test that. If it was in Austria or similar, radar should be less of a concern due to the mountains and so, but in the most flat part of the Netherlands (Flevoland), on an airport with weather radar systems on site.. that's quite another situation

I reserched, that workaround DFS bugs can particulary help, but do not solve all problems.. :
Regardless Country setting (it have to be correct - Czech republic in my case) - Define exactly "Scan list" by shrinking to intervals with allowed frequencies, excluding known radar frequencies, divide it in several intervals, if more radars exists. I have only single radar in cca 60 km distance at 5645 MHz, other is at 5635 MHz 200 km far in other direction hidden behind hills. Therefore setting in picture decline jumping outside of allowed outdoor frequencies and on radar frequency... But, unfortunately... "radars" are sometimes detected also at frequencies where it cannot occure and causes drop-outs in connections several times daily...! With this hand-made settings can be automatic DFS switched OFF, but it is not possible after release 6.37... Now i have to returm to Firmware 6.36.3. where DFS coulfd be switched OFF and accept all other bugs fixed in later releases... : And wait till and if correction will occure in "stable" version update.

Because now Log looks like: random jokes and drop-outs occures several times daily...

Nice catch.
I would have the same if I had an omni antenna on top of my house... But I am not doing that. I am using as narrow antennas as much I can in order to be shielded away from this. Also because of that I have only about 20 SSIDs on my 5G antennas at rural places.
..

Unfortunately, this picture seing 117 AP´s was from 24 dBi parabollic antenna on side wall of house (window mounted), not from Omni at top of house... Remember that every AP has connected several stations, that are not visible, but are interferring as well... then count about 500 interferred points in Cities at 12 Channels together, where UPC "supermodems" take 4 channels at OUTDOOR frequency 5560ac MHz ( /Ceee = using 5500, 5520, 5540 and 5560 MHz ) at power 1 Watt (30dBi) for each flat !!! Radars are 6635 and 6645 MHz, so what remains for others? 5580, 6000, 6200, 6600, 6800 and 7000 MHz. Only 6 Channels, that are not in countinuous range! Forget use of /ac technology outside buildings and for /n remains 4 channel posiibilities, where each couple interferres... Without interference with self you can make only 2 independent /n (2-channels/40 MHz/300 Mbit) connections or 6 classic (1-channel/20 MHz/150 Mbit) . And in this environment Mikrotik implemented forced DFS that works bad and considers as "radar" what radar is not! ... Sad, isn´t it? It becames unusable... :/

Did you try to write to MikroTik support and ask them about these erroneous detections? I'd expect them to be interested in some debug logs from your device (since you're in such radar-rich environment - just kidding, sorry ). Because I can imagine that DFS is not popular amongst their customers, so it's in their best interest to get rid of as many false detections as possible.

It seems a bit silly to (have to) provide debug logs time after time again as the problem is acknowledged by so many users.
This weekend another MikroTik AP with sector antenna was installed at 40m AGL and as an experiment I tried with 6.38.5
but it again is hopping all the time just like so many previous versions that were tried (also as old as 6.29.1).
Only setting the superchannel mode, which apparently now has to be done via the CLI as it has disappeared from WebFig,
solves the problem. But of course that is illegal.

To be honest, I have no idea how this radar detection works, if it's just purely software thing or some blackbox in wireless chipset with limited tuning options or something, or what are even possibilities what can be done. But clearly, it's not easy to get it right. My hope is that more real-life data could help. Otherwise, if this would be as good as it gets, it would make whole wifi unusable. I mean, not that a little extra motivation for ISPs to bring cables to people would be bad, but unfortunately it's not so simple.