I have a few problems last days. I have 2 PtMP sites, one with rb433 + r52h (6.47.1) and second rb metal (645.7)…the both with 16dB sectors.
The both sites have been working together over 7-8 years without any problems only I have to use nv2 because 802.11 was not stable and every client (about 15 clients) were randomly disconnecting.
Scenario of issues.
AP detected radar and clients are disconnected but they never connect again. I have to change channel and they will connect after 10 minutes all (why 10minutes?).
I change channel, or restarting radio and clients aren`t connecting imediatelly but in 10 minutes again…a several days ago they connect in the few seconds.
Some clients stop working (no internet) but I can see them in AP all the time with good TX/RX and CCQ. I have to kick client from AP, it is reconnecting in few seconds and working properly next few days.
There are strange radar detect (I know it can be from another AP) and 10min gap after channel changing, or disconnecting after radar detect with no reconnecting…Btw I was in nearest client and his SXT dont see AP in the scan so this is probably reason why clients cant connect after radar detect. I tried to change cables, pigtails, cards in RB433…with the same results.
Channel 120-124-128 are weather radar channels. The mandatory wait time is 10 minutes for any connection that includes one of those.
The other DFS channels have 1 minute delay (listening for radar) as mandatory wait time. During wait time the AP radio is silent/dead.
The wait times are triggered at wifi startup and at every change in the wifi setting or DFS channel switch.
A station (not AP or bridge) does not wait, only the AP (and bridge) are responsible for DFS channel switching and radar detection.
I already known it but they wait 10min (or rather AP wait 10min) if I want change simply channel e.g…there is no radar detected in log then. Sometimes I had to change channel because interferences but clients always connect in few seconds.
This is new for me.
10 minutes because of how weather radars are operating: they periodically perform volume (i.e. whole space around and above radar station) scan and period can be up to 10 minutes. When they do scan, they usually start with setting antenna elevation to 0 degrees (±, depending on horizon, if they are located on high mountain, starting elevation might even be negative), scan one whole 360 degree turn, increase elevation by certain amount and do another 360 degree turn … and so forth until some steep elevation, usually around 60 degrees. Usual weather radars have a 1-degree beam width (and height) antenna, hence elevation step is something between 1 and 2 degrees. So for full scan they need to perform anything between 30 and 60+ full turns. Depending on range prooerty of radar it can take up to 10 seconds for one full turn .. hence periodicity of full scans up to 10 minutes. Even if radar does volume scan in shorter time, they are usually performing scans at set intervals, hence they may be idle (not transmitting) for extended periods of time (could be more than half of time).
Note that weather radars are different from usual aviation radars, those have narrow but high beam - they scan whole space in one turn and periodicity is around 10 seconds. And they rely on data, transmitted by airplane transponders to determine precise location of airplanes. This locating strategy doesn’t work for meteorological radars because rain drops and hail stones come without transponders out of production line.
Guys again I know it, the question is not about meteo radars.
Question are why clients dont reconnect after radar detection (I have to change channel or disable/enable radio) and why they connected after 10 min if I make any change in APs wifi and I haven`t no radar detected in log.
Example from today:
07:49:17 wireless,info wlan1: radar detected on 5640000
08:04:57 system,info device changed by admin
08:05:05 system,info device changed by admin
08:15:07 wireless,info C4:AD:34:52:74:D5@wlan1: connected, s
You can see the clients didnt reconnected in 10 minutes after radars detection…I have to change channel (new and back to old) and then they start connecting (but why for 10 min?).
I think my AP is in neverending loop after radar detect. so clients can`t see it and after “reset” it check radar firt 10min and then it start broadcasting.
I explained why 10 minutes (it takes that much time to verify channel to be radar-free). If radar is detected sooner than that, AP will (or should) move on to another channel right after it detects radar.
As to why clients don’t reconnect after 10 minutes … that’s another issue. Are you entirely sure AP starts to transmit after 10 minutes?
Told you before, didn’t I, its not only with radar detected, it is is with EVERY change, that the 10 minutes wait time must be respected.
“The wait times are triggered at wifi startup and at every change in the wifi setting or DFS channel switch.”
If the channel selection loops then your radio will never transmit. I have no explanation why the clients do not reconnect.
Enable “wireless” logging in Ap and client, and there might be a clue. Maybe the clients cannot handle the other DFS frequencies. (e.g. channel 144)
It seems there is some misunderstanding.
Forget for radar now.
I cant make any change in radio because there is 10min gap. Only in one AP. Another APs are ok. I had this problem in secondary AP a few days ago. This problem was fixed with power of universer or whatever...it is just disappear.but now I have the same problem in another AP. Its like a virus;o).
ANd now let`s take radar back…why AP stop transmiting after radar detect not only for 10 or 15min but forever…there is secondary issue.
Hold it here. You did not post your configuration. You could have left the frequency on “auto”, or missed some other mandatory setting. Then you have no control whatsoever on the DFS channels, and on the 1 versus 10 minutes behavior, nor the possibility to improve the finding of usable DFS channels for the frequency+bandwidth you have set.
“Forget for radar now”? … you started by telling there were some radar detections … even if they are false, they will take out that whole bandwidth for some time. Depending on your setting and region , there is just only one usable selection, maybe 2. Easy to lose them both, and then the AP cannot transmit. Anything that radiates in your beam can generate false radar patterns, even a client.. The fact that the clients do not associate when the DFS is switched to the next available frequency can be caused by a mismatch in settings in the clients, or by a second radar detection. Manually setting the channel back to the original selection will, as any other change to the WLAN , trigger again the full mandatory wait time.(And it is 10 minutes when there is a weather radar channel in that frequency+bandwidth chosen)
It’s not a Mikrotik thing, it’s just the 802.11 standard. Every AP sees a different part of the world, so behaves differently on this matter, and that changes over time.
Cisco’s recommendation on DFS: “In general, if using DFS channels with dense client populations, one should be prepared to handle up to four false DFS events per AP radio, as well as, of course, real radar events.”