I have massive problems with connection loss because of radar detection.
The devices are located ~200m from a Wehrmacht-Base, which I think is
the cause of the problem. No available channel is free from radar at the site.
This might not be too bad, but after “radar detected..” and disconnect, the
device needs 30 minutes to reconnect.
Why does it take so long to reconnect. I would think that switching to a
different channel and reconnecting could be done in ess than a minute.
My customers on a camping site go crazy everytime a warship comes in
and forces WiFi to switch off.
You want to pick a channel that isn’t in the DFS block (radar sensing ones). While you set “skip-dfs-channel=all”, that has no effect since an explicit frequency is set (5280 in your config). And 5280Mhz will be shutdown upon detecting radar.
Using “auto” as frequency would fix it, since the skip-dfs-channel would ensure a non-DFS. Better would be if you can do a channel scan, to pick a non-DFS frequency to use, see this for which frequencies are “DFS”: https://en.wikipedia.org/wiki/List_of_WLAN_channels#5_GHz_(802.11a/h/j/n/ac/ax) for the list of frequencies
MK implementation of the radar detection is big pile of garbage.
Let me explain.
I have two routers - ac2 and ac3. They are in medium sized apartment. If I try to run them at the same time the second one is always stuck in “radar detecting”. The ac2 is in a closed in the center of the apartment. This closed have at least 2 or 3 brick or concrete/rebar walls on each side before the building “ends”. In that closet there is a heating system - there is 3 stainless steel water heaters, washing machine, metal shelf. All these things reflect radio waves - in case somehow a radar penetrated all the surrounding buildings and mine. Another thing is that snooper does not find anything on any channel, except the already running AP.
MK engineers - what I am supposed to do, to run both APs on 5180? Is this some kind of joke you like to read on forums about people struggling with your equipment? When I searched in google this issue goes back to at least 2017. So couldn’t you fixed it for these 5 years?
I understand it is a regulation and a real problem when used outside. But how will my ac2 without antennas will interfere with anything(oh yes I know it have internal antennas)?
Oh no Auto does not fix anything - it just put both on 5180 and you deal with the packet lost. So yeah technically it will work, but wont be usable.
I am going to install OpenWRT on these boxes and will post screenshots on the forum to show the comparison and usability of both.
frequency=auto or 5745-5825
installation=outdoor
guard-interval=long
hide-ssid=no
@pnwise
Setting up multiple access points next to each other can only be done manually. So far there is no software that can make this setting correctly. The software does not have a room plan and radio intelligence data, so it has to be done manually.
I know - I am setting them manually. I was just explaining what the auto option will do.
But then it begs the question - if it is auto and detects another AP with the same SSID at given frequency/channel who decided it is a good idea to use the same frequency? Where is the “auto” in that?
Better suited name for this would be random, default, static-5180 or something along the lines, because it is not auto at all.
Fair enough. I’m in the U.S., there are guns & DFS-free 5Ghz outdoor channels. But yeah that makes it tough given the OP’s situation…
The devices are located ~200m from a Wehrmacht-Base, which I think is the cause of the problem.
If your forced to use DFS & and Mikrotik Wi-Fi… I have no idea if it’s still a good idea to set a fixed channel and hope it has less DFS issues, or use auto so the AP pick a new channel. And DFS doesn’t seem like abstract risk in the OP’s case.
frequency=auto or 5745-5825
installation=outdoor
guard-interval=long
hide-ssid=no
Some weeks ago I tested every single channel and radar-detect came on each one within less than one hour.
Frequency= auto has already been tested. It starts at 5180 detects radar, disconnects and tries again after half an hour on 5180.
There have not been any frequesncy changes by the device, as I expected.
I will try guard-interval and installation=outdoor.
SSID must be hidden, because it is part of a ptp-bridge and I do not want any clients to connect to the AP.
Currently I have Skip DFS channels = disabled and no connection losses. It might not be legal, but it works.
You are not able to use MT legal anyway using max allowed Power. Without ATPC Power is decreased to a unusable level. Just configure correct Antenna gain and ROS reduces power to allowed (low) values.
Setting antenna gain lower might increase sensivity to DFS events …
U… starts to do DFS at CPEs with newest firmware. I guess this will make their gear useless in ETSI while beeing compliant. Their APs suffer from false DFS events (self interference), too.
So regulations in ETSI countries is a pain in the a…
Real PITA is pressure from vendors and general public to (re)use spectrum which was used by professional users since very long time ago. Which is the case in 5GHz spectrum with legacy users being both aviation radars as well as meteorological radars. And the DFS (etc.) is a rotten compromise … if made properly it makes wifi users’ lives miserable[*] but if not made entirely properly it makes legacy users’ lives intolerable. Legacy users can’t move to another part of frequency spectrum either due to high investment (aviation radars) or due to physical constraints (meteorological radars).
[*] The current state is half-proper implementation which makes lives of both groups unhappy, but it can’t be made entirely proper with low-end hardware. With better hardware it would be possible to implement things so that legacy users would be happy and wifi users only slightly unhappy.
And the same thing is happening again and again, latest addition was allocation of 16GHz spectrum for 5G mobile networks … it comes dangerously close to band where water vapour radiates at “normal” temperatures and this is being detected (passively!) by next gen weather satellites. Any interference there means invalid measurements over larger area which in turn hampers the ability to improve weather forecasts. So the mankind will have to make some decission about what’s more important: good weather forecasts (which can save actual lives) or better internet access (which can save some on-line lives).
Be aware of the difference between DFS (channel 52 till 144 ) with 1 minute radar detect) and weather radar frequencies in that range (channel 120-124-128) with 10 minutes of silence/radar detect.
The 10 minute (cac10) frequency channel can be part of your wider channel 40 or 80MHz and as such trigger the 10 minutes, certainly if XX or XXXX is used.
Experienced: A wAP ac can trigger false positive radar detect, eg if in the beam of a SXTsq , even if the wAP ac is using a non-DFS freq (channel 36 till 48). The SXTsq Snooper on the SXTsq showed an extra phantom device with 200+MHz offset frequencies.
It seems if you tweak settings the wifi just breaks on Radar detect, it’s almost like it’s miss detecting it’s own clients attempts at connection as radar, bloody retarded, disabling the interface for 30s to make the channel idle seems to get it working on occasion.
I’ll definitely keep in mind the downgrade option, but Cake is too good to give up just yet.
installed the wifi at the camping site for 2023 with 6 more devices and…
Radar everywhere.
Looks like the downgrade just “accidentally” worked last year.
Fun fact: one bridge that is not removed in winter did not detect any radar from
end of october to the end of march. Just when I put up more MikTiks it detects “radar”.
It looks for me that the detected radar is just my other MT devices, and that should not
be a big problem for firmware developers to fix. Or am I wrong?
I do not know the laws, but when a device that works on 5280MHz detects radar on 5500MHz,
why is it shut down?
Is there, or will there be any solution for this problem from MikroTik in the near future?