@Guntis, should be nice to have a detailed explanation like the last one, also for reselect-interval
@Guntis Thank you for your clear information on my misunderstand of the reprovisioning. Is it okay if I quote/cite your post here into the forum thread I linked to help others stumbling over the same topic? I would then update my configuration and do not do reprovisioning after each config change and check if the issue happens again. Your answer helped a lot. Thank you!
If I didn’t overseen it in the documentation, maybe a warning or information banner could be added, to make clear what the provisioning actually does. I actually can’t find anything about the
/interface/wifi/capsman/remote-cap/provision
command.
it is undocumented.
/interface/wifi/radio/provision
isn’t documented either.
Have this issue all the time. config updates are not applied by the caps unless reprovisioned, it’s highly unreliable.
Do you have examples on what changes you have made that weren’t provisioned?
If there are examples where configuration was changed, but CAPs didn’t reflect the change, please let us know, and share with us supout.rif files from both CAP and CAPsMAN, they should be made before manual “provision” is performed to fix the issue.
If you don’t explicitly configure reselect-interval no automatic rescan will take place, unless interface goes down - CAP-CAPsMAN communication was interrupted, restart, etc. Reselect-interval uses a background scan.
Exactly, I don’t understand why people are doing it. My guess is, for example, on Unify after config change you see status change to “provisioning” (or smth similar), maybe that’s the urge, or I cant rule out some edge case where there can be issue. Otherwise for me all 50+ APs I manage receive changes instantly after config change in capsman.
It literally says “channel switch announcement” in the changelog entry.
*) wifi - send > channel switch announcements > to clients when switching channels at requested re-select intervals;
In other words, “We’re using this standard (802.11h) to ensure smooth[er] channel changes at the reselect interval, instead of just dumping clients when making a change.”
Is it true you don’t have to explicitly configure reselect-interval? Having a reselect interval seems to be required in 7.15.
Thanks @Guntis, so to make more clearer;
- using !reselect-interval no automatic rescan
- using reselect-interval=6h..8h CAPsMAN or standalone AP will scan randomly for alternative channels in the background between 6h - 8h from device restart (and not between 6AM - 8AM) and then inform + disconnect clients (in case of a switch)
- diffrenentrly from the old CAPsMAN, reselect-interval works also if frequency is used and is not possible to set a specific time (12:00:00)
Correct?
In my case (RB5009 + 3 HaP ax2) it does disconnects clients. At least the ones which are on 5Ghz with DFS-10min skip.
It shows DFS 1min pause any all existing connections are dropped.
Am I correct that smooth transition could be possible for NON-dfs channels? If so, it seams usless for me.
It does not seem to be possible to do seamless channel change as there is no dedicated radio to do the scan while current channel is active. Other vendors have this feature even on devices at ~100 $ price point.
Interruptions caused by false “radar detections” have been one of worst problem of Mikrotik wireless hardware for years.
How do I define “false”? How about completely RF isolated room (metal roof and metal lined concrete walls with no windows) containing wireless AP’s as only obvious RF source in them?
Thank you, this was my concern as well. But what does this mean int he chage log?
wifi - send channel switch announcements to clients when switching channels at requested re-select intervals;
To whoom does this announsment will be sent? To the ones who just been disconnected? 
AP announces that it is switching to a new channel before it begins transmitting on that channel.
This allows supported clients to transition to the new channel with minimal downtime (the client must not begin scanning to discover the new channel on which the AP is operating).
jszakmeister -no it is not required to set reselect-interval, you can ignore this parameter if you don’t want to use this functionality
S8T8 - “!reselect-interval no automatic rescan”, yes, if no interval is set then wifi interface will not evaluate for better channels unless interface status changes.
Yes, if a better channel is found, channel switch announcment will be sent, and clients will be disconnected. 6h..8h means that in random interval after 6, but before 8 hours, reselect.interval will perform a background scan to evaluate if there is a better channel available. This does not relate to AM/PM - clock. The interval is started from moment radio got provisioned, it is not related to system uptime.
It is not possible to set specific time when scan should be performed, the parameter is intentionally made as an interval with random element to it, as the intended goal is that in multiple CAP scenario the scans and subsequent channel changes are not done at the same time.
It will still perform background scan for better channel, even if you set just a few frequencies, though we would recommend using “auto” frequency - not setting a frequency on the interface.
I really doubt background. According to what I see in my setup it just kicks off everyove and starts scanning. Which is not exactly in background…
Meanwhile it is clearly stated in the documentaion
reselect-interval (time interval)
Specifies when the interface should rescan channel availability and select the most appropriate one to use. Specifying interval will allow the system to select this interval dynamically and randomly. This helps to avoid a situation when many APs at the same time scan network, select the same channel, and prefer to use it at the same time. reselect-interval > uses a background scan> .
So I belive this documentation is not really correct. Would love to see MT comments on this.
a) Will clients be disconected begore background scan in order to perform it? Or it will be done using the same radio keeping clients connected during the scan happening?
b) If better chennel requires DFS 10 minutes wait. Will all clients be disconnected for 10 minutes?[/list]
It is also what I saw in lab. Just tried it again: used a interval of “1m..2m” so I can see it happen. The interface goes into reselect and scan for channel and even when the frequency stays the same - the clients are all kicked off. I can proof that by log entries that all clients that were connected to the particular interface either connect again once the interface is running state again (so there must have been a disconnect otherwise why should the connect???) or the switch to another CAP in the same second of reselect is running. Coincidence? I guess not. So the “background” scan is clearly not a background one. It is clearly interrupting.
Perhaps it’s intended to be in background but it messes with timing of beacon frames?
The only way of doing background scan with single radio is to transmit what’s essential (beacons) but use the rest of air time to scan other frequencies. So it will clearly affect service to active stations (they won’t get much/any response from AP during that time) and clearly can’t be properly done for DFS channels (which have to be monitored 100% of time - whatever duration required - prior to start of transmission).
The problem is similar even if AP uses dedicated receiver for background scanning (a 4x4 MIMO device could temporarily degrade to 2x2 and use free receivers for background scan) because own transmissions will overwhelm the scanning receiver … and no “digital band filters” can help there due zo the fact that it’s analog pre-amplifier which gets hit. Real analog band pass filters would help, but proper tunable ones are bulky and cost a few cents too much.
So the only benefit of using separate receivers for background scanning is that uplink service is not interrupted during background scans. It’s useless for DFS channels as much as without dedicated receivers.
For 5Ghz interfaces it is 
no background scan. One went into 10min CAC check and was not broadcasting in this time.
Interesting that Mikrotik employees have a different view in this.