When an interface goes down due to a radar signal, how long does it take to get it back up again?
It can take up to 10 minutes
When I raise this interface it says that I have to wait 1 minute on that frequency, when it fell I was waiting for 40 minutes and it did not wake up, I had to disable it and enable it so that it would work again in 1 minute, as it so happened that at that moment it was looking at the logs, but otherwise I would have seen it???
As far as i can see it failed to select channel because radar was detected on 5680 MHz and you set freq.range from 5650 to 5690.
You should set more frequencies. Set for eg. 3 channels or try to set channel that is not DFS channel.
Exactly, I want it to work on that channel, if I put more frequencies it is the router who decides, until today a radar has never appeared, if it goes down due to a false alarm it never gets up on its own?
Whenever AP decides to use some DFC channel, it has to do the listening (some channels 2 minute, some 10 minutes). Only if AP doesn’t detect anything remotely similar to radar it can start using it. If it later detects anything remotely similar to radar, it has to stop transmiting at once and enter the listening phase. So when AP detects a radar, it’s usually better to select a different channel, so it’s a responsibility of AP admin to allow AP to select different channel. If AP is not allowed to use different channel, it’ll keep trying to use the same one, but possibly detecting radar again and again. If a stubborn AP admin insists on using a particular channel, then he has to bear the consequences.
Of course there’s always possibility of false positives and self-inflicted interference (mis-identified as radar), but no AP is perfect in this aspect.
That is the behavior I expected, the interface crashes, it listens for 1 minute and then activates, but in my case I waited 40 minutes and it did not activate, I will follow up in case it happens again
Thank you
Well like the above poster said, radar detection happened already, but the result was, that there is no free channel to use, since radar overlaps the frequencies you selected. So you will have to use some other frequencies, if there is a radar operating nearby. Meaning the radar detection did not take a long time. The issue is there are no free channels to use.
I suffered from radar detections after upgrade from legacy wireless to wifi(wave2) and it looked like I could make them go away by moving the control channel.
I ended up moving to a completely different channel, so I cannot provide long-term experience, but it appeared like switching from e.g. channel 116 Ceee to channel 128 eeeC would prevent faulty radar detections although it covers the same frequency range. Might be worth a try.
I do that trick and it seems to work for me use another Control channel further away.
In such case, I’d be curious to see output of /interface/wifiwave2/actual-configuration/print detail … specifically channel.width . I wouldn’t drop dead if actual channel width would turn out to be less than configured in order to avoid radar detected on the lower channel.
The thing is that AP is forbidden to transmit anything in channel where radar is detected and that includes extension (data-only, no beacons) channels.
[edit] I was wrong about actual-configuration/print … one has to run /interface/wifiwave2/monitor to see running values. My audience has configured frequency=5500,5580 width=20/40/80mhz but looking at wireless interfaces shows comment “changed intended channel to 5680/ac/eC” … which somehow corresponds with log entry saying “radar detected on 5530” (a few days ago), a few minutes preceeded by “radar detected on 5610” (in both cases it wasn’t the C channel if channel layout used was Ceee but it’s impossible to tell what channel layout was used at time of radar detection). It seems that ROS remembers radar detections and tries to avoid them in order to provide stable network access even at cost of reduced throughput.