I updated a customers caps from ros 6.39.1 to 6.40.3. Now I notice that both caps (a hAPac and a wAPac) have selected the same channel for both radios. I didn't notice if they did so before the update. How can they do that for both radios? They are located just 10m from each other. I could understand this if they were located far apart. I could understand this if it was only the 2.4GHz radio (lots of neighbors). But how come they do this for both radios?
The hAPac runs capsman as well as being a caps.

Noone has experienced this?
This is the second time I have this issue. The first time I thought all the wAPac's I had with me was from a defective batch, and replaced them with hAPac's.

As far as I understand, Mikrotik chooses least busy wireless channel only on startup and after that never checks if it is the best (least busy). So, after CAPsMAN restart, if both APs are starting simultaneously, they can choose the same free channel. Starting from version 6.39 it is possible to tell CAPsMAN to periodically check for another free channels.
What's new in 6.39 (2017-Apr-27 10:06):
*) capsman - added support for "background-scan" and channel "reselect-interval";

Thanks. You may be onto something. Restarting the cap makes it select another 2GHz channel, but it keeps using the same 5GHz. There's a lot of unused 5GHz channels in the building, and the the APs are within range of each other (-58dB). Is something wrong with the wAPac channel selection that makes it select the channel of the strongest neighboring AP? (A '<' swapped with a '>' or 'max()' swapped with a 'min()') or something like that in the code?

There is another bug in the wAPac: If country is set to Norway, and channels is set to auto, the 5GHz radio keeps selecting channels that is 5MHz less the actual channel frequency. I wouldn't be surprised if there is another bug in the wAPac as well.

Now I've replicated this issue at home.
Took a brand new hAPac and a new wAPac, ros 6.40.3, copied system identity, capsman, caps, bridge, vlan, switch and IP settings from the customer. They are connected to each other with a 30cm cable, and they select same channel for both radios. I live at at place with no nearby wlans, except for my homewlan. Rebooting units just makes them pick the same channel again, even if I reboot the wAPac after the hAPac has finished booting.

Now I've replicated this issue at home.
Took a brand new hAPac and a new wAPac, ros 6.40.3, copied system identity, capsman, caps, bridge, vlan, switch and IP settings from the customer. They are connected to each other with a 30cm cable, and they select same channel for both radios. I live at at place with no nearby wlans, except for my homewlan. Rebooting units just makes them pick the same channel again, even if I reboot the wAPac after the hAPac has finished booting.

I can confirm that this does happen, i had to manually set separate channels on my CAPs in order to avoid they interfere each other on same freqs.

Also this isnt best solution, as there are also very close surrounding networks and they also keep changing freqs and sometimes they again hit my frequencies which makes problems on network.

Not rly sure how im supposed to deal with this..

I'm currently trying to simplify config as much as possible to isolate the issue. This has revealed two other issues that I think are bugs. Those two are:
1) reset-configuration deletes all files on unit. This is causing problem when I want a script to run after reset - the script file is no longer there!
2) wlan interface controlled by caps are unable to use capsmanager running on the same unit, unless there is a vlan defined for discovery. That is - if vlan is defined on bridge, caps can connect using layer2 to capsman on same unit. If no vlan is defined layer2 will fail, but layer3 will connect - and disconnect within 10 seconds. In order to simplify configuration, my idea was to not use vlan. Turns out it can't be made that simple.

I got to a very minimal config demonstrating the problem. I wrote down all the changes I did to the default config. Resat config, went through all the steps I had written down, and the problem was replicated. Then I connected another wAPac running ros 6.35 - which also got the same frequency. Then I connected another hAPac running ros 6.39.2 as cap, which also the same frequency. SO, I had 4 devices, all selecting the same frequency!

Then I got the idea to see if this also happens if I use the hAPac running ros 6.39 as capsman. I started out changing the cap setting on the hAPac running ros 6.40.3, just because I had that winbox window in front of the others, even though I had not configured capsman on the other hAPac yet. Then I, by accident, pressed the switch that disables the power outlet where they all were powered. When they got the power back, the problem was gone. All three remote caps selected different channels. Then I changed the local cap back to using the local capsman, and it also selected a different channel.

So, is the way to solve this issue to set the wlan running on same device as the capsman to use a capsman on a device not running capsman, and then change it back to the local capsman?

I had to test this. I logged onto my customers network. Changed the hAPac to use a not existing capsman. Then I restarted both access points. The wAPac started up fine, using another channel than before. Then I changed the local interface on the hAPac to use the capsman in same device, and it also worked - all though it did select the same channel as before. So this seems to be a workaround. Problem seems to be related to cap on same device as capsman connecting to capsman before other devices.

So, what happens if power goes down and devices restarts? I rebooted the devices at customer site - problem did not reappear. I rebooted my test devices at home - problem did not reappear here either.

Time will show if this process is a working workaround next time I run into this issue.

Attached are two screenshots of capsman and caps while they were on my desk at home

This has revealed two other issues that I think are bugs. Those two are:
1) reset-configuration deletes all files on unit. This is causing problem when I want a script to run after reset - the script file is no longer there!

This not a bug.
Place files inside flash directory and they will be there after reboot.
viewtopic.php?t=120795

Thanks for making me aware of that

New customer - same problem. What appeared to solve the problem last time, does not work now.
This setup differs in the way that I put the wAPac as capsman, and hAPac as cap (last time it was the other way around). Both selects 5180MHz for 5GHz. For 2GHz the select different channels.

Apparently a few others have ran into this as well. What are you guys doing when you run into this?

New customer - same problem. What appeared to solve the problem last time, does not work now.
This setup differs in the way that I put the wAPac as capsman, and hAPac as cap (last time it was the other way around). Both selects 5180MHz for 5GHz. For 2GHz the select different channels.

Apparently a few others have ran into this as well. What are you guys doing when you run into this?

What country setting are you using for 5ghz? Can you scan the AP to see how many APs there are on different channels?

Country tested with norway (frequency list know to be incorrect for wAPac models), france and UK. There are no other 5GHz networks in range at this customers site. The same goes at my house where I replicated the issue. For the two previous customers where I ran into this, there were some other 5ghz in range.

whats your channel configuration and routeros version?

i only have 2.4ghz implementation

i have configured channel this way and cAP are jumping between the 3 channels specified without issue selecting the channel with neighboring network with less signal level, routeros 6.40.5

I have a crowded environment with 40+ neighboring bssid's on any ap, my own ap are not the strongest ones

I have not configured channels. Hence the caps should use the country dependent frequency list.

whats your channel configuration and routeros version?

i only have 2.4ghz implementation

i have configured channel this way and cAP are jumping between the 3 channels specified without issue selecting the channel with neighboring network with less signal level, routeros 6.40.5

I have a crowded environment with 40+ neighboring bssid's on any ap, my own ap are not the strongest ones

in further testing i have found that when a Cap stays on "old" channel after a scan, never scan again, that is "reselect interval" setting does nothing after a scan without channel change.

i remove "reselect interval" setting and make a scheduler to make Cap reselect channel every interval i want

I have not configured channels. Hence the caps should use the country dependent frequency list.

i always have used myself defined channels in capsmanager

I ran into this issue again. What was the solution this time was to downgrade firmware, and upgrade firmware again. No config changed - problem gone.
I wonder if that's going to be the solution next time as well.

I am also seeing this, after reboot both AP come up on same channel on 40MHz... unless i have screwed up the channel selection list - either way, hitting Reselect Channel it will then pick a separate channel.

It is OK on 20MHz though.

Having the same issue in bugfix latest (6.40.6)
Not real fun in a 33 strong CAPsMAN deployment

I have the same issue on my hAP AC Lite's. 2.4Ghz - everything ok, always different channels for next-door AP's. For 5Ghz always the same 5180/20-Ceee/ac(20dBm). Disabling the CAP for one of them and enabling ap bridge mode always leads to different frequency. Enabling CAP back sets the channel back to the same on all of them. Latest stable firmware on CAPs (6.42.1) and 6.42 on CAPsMAN. Country set to Russia.
Made some reconfigurations. Looks like it's because of Skip DFS setting.

When Skip DFS Channels is not checked this messages appears in logs and wi-fi interface setup is delayed for one minute:
capfive-MikroTik ST-hAP-AC-Lite3-1: do radar detect for 60 seconds on 5260/20-Ceee/ac/DP(20dBm)
capfive-MikroTik ST-hAP-AC-Lite3-1: radar not detected on channel 5260/20-Ceee/ac/DP(20dBm)
This way one of the APs selects a channel different from 5180 (it's always 5260 in my case).

When Skip DFS Channels is checked it always sets 5180 emmediately without any scan an all APs
capfive-MikroTik ST-hAP-AC-Lite3-1: selected channel 5180/20-Ceee/ac/P(20dBm)capfive

Why this happens? I mean why it always set 5180/20-Ceee when is set to Avoid DFS? Looks like this setting completely disables free channel scan/select process.

I'm having this issue too. I have a pair of hAP AC2s and CAPsMAN running on my hEX, and today on 6.42.2 both are choosing the same channels for 2.4G and 5G. Forcing a reselect on the 2.4G fixes it temporarily, but on 5G both APs just take the first available channel since there is no other 5G around and they cannot see each other in the scan. The problem is if I stand halfway between them I can see both on the same channel - not a good situation. Surely with CAPsMAN managing frequency selection this should not happen?

should / should not ... This is dilemma:
Mikrotik cannot possibly know location of each device so it cannot do some clever optimization before each frequency is known. Only way is then scanning one by one: One AP scans, select best channel. Then second AP scans, detects first AP and selects another channel. That might work. Right? Well, nope - capsman must take into account large networks where tens or even hundreds of caps are deployed. You cannot possibly provision them one by one because it would take ages.
Despite trying hard, I was unable to come up with some ingenious algorithm which would do this properly. I am afraid we have specify frequencies manually.

Well if all APs are managed by CAPsMAN and all airspace is clear, why shouldn't it 'fill up' the available spectrum within the location before doubling up on frequencies? A simple round-robin would do that. If a foreign network appears, then do something about it, but otherwise use as much as is available. Failing that, make it easier to override channel selection from within the controller interface.

Anything new on this topic? CAPSMAN still uses the same frequency for all 5 GHz radios on my hap AC devices regardless of any configuration I might try. There is only one setup that works: in case I DON'T set any frequencies AND uncheck "skip DFS channels" I end up having different channels on my radios. Problem is non of my devices supports the frequencies selected (e.g. 5600).

Anything new on this topic? CAPSMAN still uses the same frequency for all 5 GHz radios on my hap AC devices regardless of any configuration I might try. There is only one setup that works: in case I DON'T set any frequencies AND uncheck "skip DFS channels" I end up having different channels on my radios. Problem is non of my devices supports the frequencies selected (e.g. 5600).

I have same issue, 13x WAP ACs, 2ghz interfaces select each differnet channel, but 5ghz all gets set to 5180 chan.
@uldis can we get some support on this?

edit:Seams country related problem.If i remove Wireless configuration Country it works fine, every 5ghz AP selects different chan.If i set it to Croatia, or any other Country they all select first 5180 chan.

ON 2ghz i have country selected and works fine.

Is this issue solved ? I have same issue - all caps ac are on same channel

Just updated to 6.42.6, nothing has changed. AC radios are still selecting the same channel, this is quite annoying. I wish it was possible to just manually select my own channels in capsman, punt some radios off to a preferred channel.

I wish it was possible to just manually select my own channels in capsman, punt some radios off to a preferred channel.

Use action=create-enabled instead of action=create-dynamic-enabled in your capsman provisioning profile and you can set frequency on each interface.

Just updated to 6.42.6, nothing has changed. AC radios are still selecting the same channel, this is quite annoying. I wish it was possible to just manually select my own channels in capsman, punt some radios off to a preferred channel.

Yes I had 10 CAPs all select the same 2 channels last week (no DFS channels were chosen). Annoying! Maybe "auto" is very conservative if it doesn't have much information supplied by the user.

In the profile I then set 5 non-overlapping 80MHz channels in Ceee mode - the CAPs then selected from all 5 of those channels. That was better.

I decided to statically assigned each radio a frequency.

You can statically assign channels to individual CAPs radios by:

• Make a CAP profile for each channel/frequency.
  In provisioning
  * use the regexp feature to select the name by identity. If you have some devices named WAP1, WAP2 and WAP3 you'd put in "(WAP1)" for one device or "(WAP1)|(WAP3)" for 2 devices.
  * use supported modes to choose the radio type like "ac" and "an".

Dynamic provisioning is fine.

Those 10 CAPs are now statically assigned on 5 non overlapping 80MHz channels. I used a 5 colour map to assign which unit used which channel.

Have a read of the link in the post I made the other day about "Understanding 5GHz Channels" and look at the table to work out what frequencies to use for various 802.11ac bandwidths and try stick with Ceee for 80MHz and Ce for 40MHz.

I had the same issue. I resorted to figuring out the best channels for the devices manually (by labeling the rooms with appropriate channels on the floor plan) and then, just as @UpRunTech, using the identity to specify the channels.

Here is the critical part: Sidenote: the slash before the $ sign is generated by the export command to make the $ sign literal (and not start of a variable in the script). When using Winbox, remove the slash before the dollar. The dollar matches the end. In this case it is not needed but if you decided to use ch1 and ch11 then you will need the dollar because without it 211-ch1 and 211-ch11 will both match .*-ch1

So basically I name my devices {roomnumber}-low or {roomnumber}-med or {roomnumber}-high and then they get either a low (1), medium (6) or a high (11) channel. For example 211-low is a device in the room 211 using channel 1.

You could also extend my example by having separate parts of the identity referring to 2G and 5G channels: for example to get 211-ch1-ch36 to match, you can use ".*-ch1-ch\d+$" for 2G and ".*-ch\d+-ch36$" for 5G. Those examples are for entering in Winbox, for terminal you need to escape the dollar (at least).

I had the same issue. I resorted to figuring out the best channels for the devices manually (by labeling the rooms with appropriate channels on the floor plan) and then, just as @UpRunTech, using the identity to specify the channels.

Here is the critical part:

Code: Select all

/caps-man channel
add extension-channel=Ce frequency=5180 name=5g-low
add extension-channel=Ce frequency=5220 name=5g-med
add extension-channel=Ce frequency=5260 name=5g-high
add extension-channel=disabled frequency=2412 name=2g-low tx-power=10
add extension-channel=disabled frequency=2437 name=2g-med tx-power=10
add extension-channel=disabled frequency=2462 name=2g-high tx-power=10
/caps-man configuration
add channel=2g-low datapath.bridge=bridge1 name=conf-2g-low security=security1 ssid=WiFi
add channel=2g-med datapath.bridge=bridge1 name=conf-2g-med security=security1 ssid=WiFi
add channel=2g-high datapath.bridge=bridge1 name=conf-2g-high security=security1 ssid=WiFi
add channel=5g-low datapath.bridge=bridge1 name=conf-5g-low security=security1 ssid=WiFi_5G
add channel=5g-med datapath.bridge=bridge1 name=conf-5g-med security=security1 ssid=WiFi_5G
add channel=5g-high datapath.bridge=bridge1 name=conf-5g-high security=security1 ssid=WiFi_5G
/caps-man provisioning
add action=create-dynamic-enabled hw-supported-modes=gn identity-regexp=".*-low\$" master-configuration=conf-2g-low name-format=prefix-identity name-prefix=2G
add action=create-dynamic-enabled hw-supported-modes=gn identity-regexp=".*-med\$" master-configuration=conf-2g-med name-format=prefix-identity name-prefix=2G
add action=create-dynamic-enabled hw-supported-modes=gn identity-regexp=".*-high\$" master-configuration=conf-2g-high name-format=prefix-identity name-prefix=2G
add action=create-dynamic-enabled hw-supported-modes=ac identity-regexp=".*-low\$" master-configuration=conf-5g-low name-format=prefix-identity name-prefix=5G
add action=create-dynamic-enabled hw-supported-modes=ac identity-regexp=".*-med\$" master-configuration=conf-5g-med name-format=prefix-identity name-prefix=5G
add action=create-dynamic-enabled hw-supported-modes=ac identity-regexp=".*-high\$" master-configuration=conf-5g-high name-format=prefix-identity name-prefix=5G

Sidenote: the slash before the $ sign is generated by the export command to make the $ sign literal (and not start of a variable in the script). When using Winbox, remove the slash before the dollar. The dollar matches the end. In this case it is not needed but if you decided to use ch1 and ch11 then you will need the dollar because without it 211-ch1 and 211-ch11 will both match .*-ch1

So basically I name my devices {roomnumber}-low or {roomnumber}-med or {roomnumber}-high and then they get either a low (1), medium (6) or a high (11) channel. For example 211-low is a device in the room 211 using channel 1.

You could also extend my example by having separate parts of the identity referring to 2G and 5G channels: for example to get 211-ch1-ch36 to match, you can use ".*-ch1-ch\d+$" for 2G and ".*-ch\d+-ch36$" for 5G. Those examples are for entering in Winbox, for terminal you need to escape the dollar (at least).

In case when one CAP is itself (localhost) identity-regex is clearly not working, it's not provisioning. But works with remote CAP. BUG!