We’ve been testing the CAPsMAN module and we’ve found some features missing. One of them in my opinion it’s that the channel could be set to auto-frequency. Other Ap management systems (unifi, bintec or cisco lapp) set the frequencies automatically to avoid interference between neighbour APs. Most of them use a separation of at least one empty channel between nearest radios, if possible.
I know that this is a beta release and lot has to be done.
Thanks for your product and hope that the CAPsMAN module will be another great feature (and long waited also).
“channel.frequency (integer [0..4294967295]; Default: ) Channel frequency value in MHz on which AP will operate. If left blank, CAPsMAN will automatically determine the best frequency that is least occupied.”
I have a question about the capsman auto frequency feature. Does the capsman have the ability to change the AP’s channel frequency when the conditions are changing, without disabling/enabling it? Or the capsman selects the best channel ONLY when an AP starts?
Auto select doesn’t work. It did seem to sort of work in 6.19 Capsman. But not when the device first came up. Only if you disable/reenabled the interface after it rebooted. Then it would work. On 6.21 and 6.22, it seems about as useless as a box of rocks.
But when are you going to (re)support TRUE DFS modes with radar detect? Right now, If I reboot all 3 of my home APs at one time, They will pop up on 5180mhz with 80mhz channel width and just sit there. Forever.
Each time when a CAP interface is provisioned the frequency is selected - you can see the status of the CAP interface it will show selecting frequency.
If all your HomeAPs are near to each other and are added in the CAPsMAN then they will try to use different frequency.
I haven’t tried v2 but it works for me on v1. Did you try it on v1, and did it work for you on v1, too?
One thing that I have noticed is that if I boot up all of my CAPs at the same time, then even with auto frequency, they all end up on the same channel. But if I stagger the order in which they boot up, then they all pick different frequencies. I suspect that what is going on is that when they all boot up at the same time, they are all scanning at the same time when none of them are broadcasting, so they all think that channel 1 is clear and so they all pick it. The CAP will not pick a new channel until the interface has been disabled and re-enabled, which makes sense: if they were continually listening for a better channel to switch to while operating, they would have to kick all associated clients off every time they did a sweep because one radio cannot tune into 2 channels at the same time. The only way to implement active, continual channel scanning would be to have a second radio that is always in listen-only mode.
One possible solution that MikroTik might look into is having each CAP add a random delay to turning on the radio every time it boots up. Actually, I might be able to do this with a startup script on each CAP, now that I think about it. I will have to do some experimentation.
Each time when a CAP interface is provisioned the frequency is selected - you can see the status of the CAP interface it will show selecting frequency.
On CAPsMAN v2 this does not work. Tested. It worked on CAPsMAN v1.
It makes no sense. It is supposed to be able to continuously monitor in order to use the DFS spectrum. Not having that spectrum cuts the available channels in 1/2. Its non-functional the way it operates now.. I might even venture to say the software is breaking the hardwares FCC compliance.
EDIT: You don’t need to have the device in scanning mode to listen for interference. Thats how radar detect works. It detects something on ITS channel, then changes the channel to avoid interference.
We aren’t talking about the DFS requirement for certain 5GHz bands for outdoor use. CAPsMAN is for deploying, configuring, and maintaining APs for indoor use in an 802.11 LAN.
The CAPsMAN auto frequency basically just instructs the CAP to use “frequency=auto” on the wireless interface. And “frequency=auto” is equivalent to “dfs-mode=no-radar-detect”, as Normis clarifies for us here: http://forum.mikrotik.com/t/v6-11-released/75450/22 – so, yeah, it isn’t listening for radar on the current channel.
I wasn’t talking about having the device in scanning mode to find interference on the current channel. I was talking about having the device in scanning mode in order to find other channels to switch to if interference is detected on the current one, or to actively look for a better channel to switch to even if no other distinct system is detected on the current one or if local RF conditions change since the last time it picked a channel.
RADAR detect is only looking for a specific type of wireless transmission, in order to avoid channels where RADAR transmission is taking place. As far as I know, it does not look for general noise, or for other 802.11 systems (except by accident, if a transmission from a neighboring 802.11 system on the same channel happens to match what it would interpret to be a RADAR pattern). The purpose of RADAR detect is not to have automatic channel co-ordination between 802.11 APs.
If radar-detect is enabled and RADAR is detected, my understanding is that the AP has to vacate the channel as soon as possible. This means that either the AP shuts down for a while while it performs another lengthy scan of the entire spectrum in order to pick a new channel, or that in order to avoid downtime, it picks a different channel at random and hopes there is no other system running on it. Neither is ideal. If there was a second radio in listen-only mode, then the AP would always have an up-to-date list of the possible good channels in the local vicinity that it could immediately hop to.
