Remote CAP in 7.13 using CAPsMan 1 and 2

RouterOS Wireless Networking
1

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

2

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.

3

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

4

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?

5

Not yet.

May be later before New Year

6

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.

7

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.

8

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.

9

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.

10

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.

11

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.

12

I observed similar when I put up this post.

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

13

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.

14

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.

15

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.
16
  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.
17



  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.

18

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.

19

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.

20

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?