I have been using CAPsMan 1 for my local and remote AP. I know I need to allow UDP 5246, 5247 for traffic

When I upgrade to 7.13, I wish to try CAPsMan 2. I know it can be used on the same main routeros device. But seems it does not allow remote APs to come it when both CAPsMan 1 and 2 are on

I tried run together WIFI Capsman and old Capsman at hap ac but after enabled a WIFI CAPSMAN all cap registered to old CAPSMAN disappeared.
The old capsman have own certificates, the WIFI Capsman have a new genearated with WiFi prefix in name.

Yes, I noted this

But not sure how to have two CAPsMANs work in the same devices and how different APs can find its own CAPsMAN and work properly

At least Mikrotik said this is a supported scenario when I understand the Youtube video and the threads about 7.13.

Anyone opened a support ticket/bug yet?

Not yet.

May be later before New Year

I'm now at a stage running into the same (or rather small different) issue.

As soon as I enable wave2 capsman on my controller (RB4011 with wifi) my hap ac2 (running still wireless package until I'm ready with new capsman) stayed connected to legacy capsman.
But I lost the local wifi interfaces of the RB4011 only.
As soon as I disable wave2 capsman the local wifi interfaces are coming back.

I played a bit with different interfaces but struggling to find a good combination.
E.g. tried to make sure that the local wifi is connecting to 127.0.0.1 via a bridge which is not a listen interface for wave2 capsman but to no avail.

...
As soon as I enable wave2 capsman on my controller (RB4011 with wifi) my hap ac2 (running still wireless package until I'm ready with new capsman) stayed connected to legacy capsman.
But I lost the local wifi interfaces of the RB4011 only.
As soon as I disable wave2 capsman the local wifi interfaces are coming back.
...

Please read and heed the warning of the documentation's Compatibility section:

Compatibility[:] Incompatible
Devices[:] RB4011iGS+5HacQ2HnD-IN (no support for the 2.4GHz interface)...

At the very beginning of the Wireless documentation in the RouterOS package type section there are two tables describing what package(s) is/are required to achieve certain features on a given device.

By the way it is useful to return to the WiFi part of the documentation from time to time as it seems it got some updates since its first publication when 7.13beta3 was released.

Please read and heed the warning of the documentation's Compatibility section:

Compatibility[:] Incompatible
Devices[:] RB4011iGS+5HacQ2HnD-IN (no support for the 2.4GHz interface)...

At the very beginning of the Wireless documentation in the RouterOS package type section there are two tables describing what package(s) is/are required to achieve certain features on a given device.

I've read all this several times before and after and still believe that my understanding is correct.

I have routeros and wireless installed on the RB4011 which according to the documentation allows me to achieve what I want:
- manage wave2 devices via capsman (ac2 with wifi-qcom-ac and ax3)
- manage non-wave2 devices (including the RB4011 interfaces) via legacy capsman (from the wireless package)

I have no intentions to upgrade RB4011 to wifi-qcom-ac with the existing limitation.

How are you provisioning local wireless interfaces in RB4011? If you're trying to do it via (legacy) capsman (run on same device), which was possible with legacy wireless and capsman, try to configure them "manually". Using local capsman with new wifi drivers is not possible anymore and it is possible that trying to use such setup on "dual capsman" device breaks something.

Sorry, don't understand the questions/statements.
I could provision the RB4011 wireless interfaces locally because I have the "wireless" package. But I prefer to keep them managed via the legacy capsman on the same device as it is as of today.

And yes, using local wifi capsman I cannot manage them but that is not what I'm trying to do.

Just to repeat again


RB4011 (routeros+wireless) (wifi and legacy capsman available)
cap1: local RB4011 wifi interfaces <- managed by legacy capsman
cap2: ax3 <- managed by wifi capsman
cap3: ac2 (with wifi-qcom-ac drivers) <- managed by wifi capsman
cap4: ac2 (with wireless (for now) <- managed by legacy capsman

The above is the scenario i'm trying to set up and still I believe that is supposed to work.
And the roadblock I currently have is that cap1 interfaces are disconnected as soon as I enable wifi capsman while cap4 stays happily connected.

cap1: local RB4011 wifi interfaces <- managed by legacy capsman

I'm asking you to try to configure local interfaces directly without trying to use local capsman. I wrote the reasons for my suspicions that this might be a problem in my previous post.

Sorry, don't understand the questions/statements.
I could provision the RB4011 wireless interfaces locally because I have the "wireless" package. But I prefer to keep them managed via the legacy capsman on the same device as it is as of today.

And yes, using local wifi capsman I cannot manage them but that is not what I'm trying to do.

Just to repeat again


RB4011 (routeros+wireless) (wifi and legacy capsman available)
cap1: local RB4011 wifi interfaces <- managed by legacy capsman
cap2: ax3 <- managed by wifi capsman
cap3: ac2 (with wifi-qcom-ac drivers) <- managed by wifi capsman
cap4: ac2 (with wireless (for now) <- managed by legacy capsman

The above is the scenario i'm trying to set up and still I believe that is supposed to work.
And the roadblock I currently have is that cap1 interfaces are disconnected as soon as I enable wifi capsman while cap4 stays happily connected.

I observed similar when I put up this post.

My ultimate goal is to have a x86/chr to have both capsman.

cap1: local RB4011 wifi interfaces <- managed by legacy capsman

I'm asking you to try to configure local interfaces directly without trying to use local capsman. I wrote the reasons for my suspicions that this might be a problem in my previous post.

Ok, so you are basically telling me to use that as a workaround because something might cause problems?
Yes, I could. But I'm not in a hurry to have to use workarounds which cause extra efforts for me unless MT says that this scenario is either expected (and not a bug) or can be solved by doing this and that.
Obviously I could configure interfaces locally in addition. That means that I' going from a scenario where I use ONE capsman for all my wifi interfaces in the network to THREE places where I need to configure wifi interfaces. I already have to accept TWO with the different capsman versions but I really would like to avoid the third. That is the point of my post.

... unless MT says ...
That is the point of my post.

This forum is not official support channel of Mikrotik, it's user to user communication channel (and MT staffers show around from time to time). So if you want MT to say something, you'll have to officially open support ticket (either via email or via web interface). Around here you can only expect to get (more or less) educated guesses and possible workarounds. And when you're opening support tickets, it's good to tell them exactly what doesn't work and why it should work (according to documentation). My advice about trying to configure things locally were meant in this direction: to determine whether something fails in certain use case but doesn't otherwise. If you don't want to go this path, then it's fine with me.

...
And yes, using local wifi capsman I cannot manage them but that is not what I'm trying to do.
...
RB4011 (routeros+wireless) (wifi and legacy capsman available)
cap1: local RB4011 wifi interfaces <- managed by legacy capsman
cap2: ax3 <- managed by wifi capsman
cap3: ac2 (with wifi-qcom-ac drivers) <- managed by wifi capsman
cap4: ac2 (with wireless (for now) <- managed by legacy capsman

The above is the scenario i'm trying to set up and still I believe that is supposed to work.
And the roadblock I currently have is that cap1 interfaces are disconnected as soon as I enable wifi capsman while cap4 stays happily connected.

Before believing read the (extended) documentation first as while 7.13 made it possible to run both CAPsMANs on the same device at the same time there are certain limitations:

1. Wireless part of the documentation RouterOS package type pay special attention to the notes.
2. Compatibility section of the WiFi part of the documentation.
3. The dedicated announcement 7.13 wireless package split question topic.

Before believing read the (extended) documentation first as while 7.13 made it possible to run both CAPsMANs on the same device at the same time there are certain limitations:

1. Wireless part of the documentation RouterOS package type pay special attention to the notes.
2. Compatibility section of the WiFi part of the documentation.
3. The dedicated announcement 7.13 wireless package split question topic.

1. just read it "Built-in cards can only work with legacy drivers" - what have the drivers to do with the fact if they are configured via old capsman or via local configuration. That is no contraindicator.
2. now I've read it the 20th time. Still nothing in there which would explain the issue I'm seeing. Instead of pointing multiple times to the same documentation it would be helpful to get a direct pointer to the information which says that my issue is "expected"?
3. thanks for that pointer because this post exactly describes my problem. The problem just is that there is no reply, no explanation, not a solution dedicated to this. So a pointer to the same question is interesting because information could be consolidated but unfortunately no solution.

1. just read it "Built-in cards can only work with legacy drivers" - what have the drivers to do with the fact if they are configured via old capsman or via local configuration. That is no contraindicator.
2. now I've read it the 20th time. Still nothing in there which would explain the issue I'm seeing. Instead of pointing multiple times to the same documentation it would be helpful to get a direct pointer to the information which says that my issue is "expected"?
3. thanks for that pointer because this post exactly describes my problem. The problem just is that there is no reply, no explanation, not a solution dedicated to this. So a pointer to the same question is interesting because information could be consolidated but unfortunately no solution.

1. Actually the restriction is "Old 802.11ac ARM CPU devices* ... * wifi-qcom-ac: Audience, Audience LTE kit, Chateau (all variants of D53), hAP ac^2, hAP ac^3, cAP ac, cAP XL ac, LDF 5 ac, LHG XL 5 ac, LHG XL 52 ac, NetMetal ac^2, mANTBox 52 15s, wAP ac (RBwAPG-5HacD2HnD), SXTsq 5 ac" : the RB4011iGS+5HacQ2HnD-IN is not on the list of supported devices. Also the writing is on the wall "New 802.11ax devices ... Old CapsmanOld Capsman [:] routeros + wireless [;] Actually old = dual. Loses built-in cards ; Running both capsmans at the same time [:] routeros + wireless [;] Loses built-in cards". I do know that RB4011iGS+5HacQ2HnD-IN is not a 802.11ax device however it is quite a special snowflake therefore it would not be that surprising if it turned out that it is a bit more special and act as the 802.11ax devices do in this scenario. Nevertheless I do hope that the issue will be sorted out sooner rather than later, however I would not have my hopes up (considering the still sad state of routing protocols in v7 - documentation included).

On a personal note, when I started to use MikroTik I intentionally separated the wired and wireless (at the cost of higher initial CAPEX) in order to avoid the pitfalls of all in one solutions.

I agree that I'm not surprised that something might no be working as expected with this "first" release. That is the point.

The lines I'm looking at from the table are:

Feature Needed packages Notes
Legacy drivers (Nstreme, Nv2) routeros + wireless
Running both capsmans at the same time routeros + wireless Built-in cards can only work with legacy drivers

Those are the feature sets I'm looking for. Both require the same packages and the notes confirm that the built-in cards still work (they do actually). It still does not explain why their capsman (client) disconnects as soon as I start the second capsman instance.
I do not even see a reason besides a bug why it would be a conceptual problem.
In any case I opened a ticket a few days ago. Just not super confident someone seriously looks at it.

I have been using CAPsMan 1 for my local and remote AP. I know I need to allow UDP 5246, 5247 for traffic

When I upgrade to 7.13, I wish to try CAPsMan 2. I know it can be used on the same main routeros device. But seems it does not allow remote APs to come it when both CAPsMan 1 and 2 are on

I had the same issue and found that on my access points I was discovering CAPsMAN via an ip address. Once I removed that and discovered CAPsMAN using a discovery interface then the access points could join back in with both CAPsMANs enabled.

I had the same issue and found that on my access points I was discovering CAPsMAN via an ip address. Once I removed that and discovered CAPsMAN using a discovery interface then the access points could join back in with both CAPsMANs enabled.

Interesting. My local interfaces on the capsman host are configured to use 127.0.0.1 which works (as long as I don't enable new capsman in parallel).
When I remove the IP and change to discovery interface "bridge-local" where capsman is explicitely bound to as well no capsman is found.
Log says
"CAP did not find suitable CAPsMAN"

This even happens without new capsman enabled. Does discovery in general not work on the same device?

Does discovery in general not work on the same device?

New capsman explicitly doesn't support provisioning local devices (MT is very clear on that). Old capsman apparently did[*] support that but MT (AFAIK) never really advertised this as a feature ... so it might be an unsupported glitch they just let working all these years.

[*] MT probably had to touch the old capsman code in order to allow old and new capsman coexist on same device. Which may have broken the previously undocumented "feature". Anyone concerned by this "breakage" should open a support ticket with mikrotik support and their responses should then clear these dilemmas. Either MT will fix the legacy capsman or they'll say it wasn't supposed to work like this in the first place.

New capsman explicitly doesn't support provisioning local devices (MT is very clear on that).

This was actually very much unclear to me when I was setting up new CAPsMAN for the first time. I can't even find a mention of local interfaces with regards to CAPsMAN in the docs.

Old capsman apparently did[*] support that but MT (AFAIK) never really advertised this as a feature ... so it might be an unsupported glitch they just let working all these years.

MikroTik may have never advertised this as a feature, but they did put a firewall entry into default config seemingly just for local CAPsMAN to work, the one with the comment "defconf: accept to local loopback (for CAPsMAN)". They may have done this to dissuade unwary forum users from just turning off "drop all input not from LAN" rule. But still.

I found this table helpful when trying to figure out the situation with new/old CAPsMANs..

viewtopic.php?t=202578&sid=0fd3f9928cda ... 4#p1043068

Unfortunately I have got the same like issue:
setup:
- RB4011iGS+5HacQ2HnD with wireless package for old 2.4Gz
- CAP AC with qcom-ac
- CAP AX.

During the setup adjustments old capsman (127.0.0.1) was switched off and new CAPsMAN worked well and even CAP AX was provisioned, then old was switched on, and at certain point of new capsman adjustments something broke.

Now both CAPs (AC and AX) report that their interfaces are managed by new CAPsMAN, new CAPsMAN lists CAPs correctly via L2, but the "Wifi" for new wave2 CAPs view at RB4011iGS+5HacQ2HnD says "no connection to CAPsMAN" and provisioning does not work anymore , although all information about Radio and other settings displayed correctly.

More than that, if I touch new CAPsMAn configuration the old stops provisioning and I have to change something in settings of old capsman in order to make it working again.
Both CAPsMans have certificates, and I tried to lock CAPs to corresponding CAPsMANs - it does not help.

Do both CAPsMANs have conflict somewhere? Any idea how to check if needed services are running correctly?

After some months, I still cannot make it work.

Any successful story to share? Remote CAP means CAP is connected via internet/WAN not LAN

Remote CAP means "CAP is other device". "Local CAP" = CAPsMan and CAP on same device.

Remote CAP means outside LAN and connects via internet.

CAP in other devices connected via LAN works in CAPsMan 2

In legacy CAPsMan, I have made it work but never shows up as remote radio

Your CAPS that can't connect try to reach your CAPsMAN server via WAN? Then check your firewall rules?

Your CAPS that can't connect try to reach your CAPsMAN server via WAN? Then check your firewall rules?

I try two routerOS device on the same network - one with legacy wifi; connect and work with CAPsMan 1; the other is a AX3 could not connect

Both point to the same IP address and I open up UDP ports 5246 and 5247

If issue persists while 7.14.2 is installed on CAPs and CAPsMAN, please create supout.rif files on involved devices and share the files with us support@mikrotik.com
This issue should be resolved in latest versions.

If issue persists while 7.14.2 is installed on CAPs and CAPsMAN, please create supout.rif files on involved devices and share the files with us support@mikrotik.com
This issue should be resolved in latest versions.

I use both 7.15.beta9 in my x86 as CAPsMan 1 + 2 and AX3 as CAP. From the AX3 log, it shows timeout. Firewall allows both UDP ports 5246 and 5247 in and out.

In the same remote network, another CAP connecting to x86 CAPsMan 1 works. I just put one device in the remote network

An update,

I brought the AX3 back and installed in the LAN, it worked with the x86 device that has both CAPsMAN 1 and 2. Configuration was not that difficult.

Now wait to see if the same AX3 works again in remote site

Now at remote side, AX3 reports timeout or No suitable CAPsMan found

How is connection from remote site to network where capsman controller is located ?
Ideally it should be in the same L2-segment. If that's not the case, you need to specify the IP address where it needs to look for the controller.

If IP connection is possible, have you tried to specify controller ip directly in that cap device ?
You could also try to put an EOIP connection over remote/local environments, connect that EOIP on both bridges and hence mimicking an L2 connection.

What I do is on different public IPs for CAPsMan and CAP

In CAPsMan 1, it can be done as specifying the CAPsMan public IP in the CAP menu of AP and the firewall of CAPsMan allows UDP 5246, 5247. It works well all along including in the same city and overseas via internet.

In my case, CAPsMan 2, I prepare the same information in the CAP menu of the AX3 AP. What I can see in AX3 log, it can locate the CAPsMan via public IP, but error in connection due to timeout.

Anyway, I raise a support ticket as suggested by Guntis

If issue persists while 7.14.2 is installed on CAPs and CAPsMAN, please create supout.rif files on involved devices and share the files with us support@mikrotik.com
This issue should be resolved in latest versions.