The (current?) default for the manager property, on the CAP it has to be set correctly (either capsman or capsman-or-local):
|manager ( capsman | capsman-or-local | local; default: local )|capsman - the interface will act as CAP only, this option should not be passed via provisioning rules to the CAP
capsman-or-local - the interface will get configuration via CAPsMAN or use its own, if /interface/wifi/cap is not enabled.
local - interface won't contact CAPsMAN in order to get configuration.
Just to consolidate advice from a few previous posts:
Rationale: manager property is always applied only to device where set, it's not part of parameter set sent out by CAPsMAN to CAP devices (it would be chichen&egg paradox: how is CAP device supposed to know that its wifi interface is supposed to be provisioned by CAPsMAN unless it's configured appropriately before conecting to CAPsMAN).
It was an egg, last time I checked, how time passes by .... 
Right ...
"Guys,
Thanks for all the insights. I was actually planning to run a comprehensive test this weekend, covering all possible constellations of the different configuration layers. I had the automated script scheduled for a run tonight.
However, I have arrived at the same conclusion as @mkx even without the full test results, with one lingering doubt. While this multi-layered setup is elegant in theory, I don't see the justification for having one specific parameter definable at every single level, and that is the manager.
In my view, this is a parameter that should be decided at the lowest possible level. It is either 'local' or 'capsman', and that choice clearly defines where the interface should expect its configuration from. I cannot think of a single use case where it would be necessary for this specific parameter to originate from a configuration profile.
I probably made the mistake of setting the manager value in the config profile initially, expecting the CAPs to receive it. When that didn't work, I simply forgot that it was still defined there, which led to the confusion.
Thanks again for helping me clear this up!"
The issue was caused by setting /interface wifi configuration manager strictly to capsman. This can prevent some CAP-side operations even if provisioning seems correct, leading to āno connection to CAPsMANā and no SSID broadcast. Changing it to capsman-or-local allows the CAP to fully register and broadcast the SSID while still being managed. Toggle the CAP afterward, and everything runs normally.
"Hello all,
thanks again for all the help. I have localized the error and brought the system into a state consistent with the advice received. It has raised the question of whether it makes sense for certain parameters to appear at multiple levels of the configuration structure; based on my experience, I believe it does not.
Thanks again."
I believe - but I may be wrong - that the rationale is that (normally) in an AP you have two radios/wlans, the 2.4 GHz and the 5 GHz that are simply two paths that the wifi clients can choose leading to the same place (availability of internet).
In this case it makes sense to set the manager in the one and only configuration.
On the other hand more complex setups (like - say - setting the AP as extender or using additional virtual radios for IoT, etc.) might need the "granularity" of setting the manager on the single radios.
This gives more "frredom" in configuration, what is missing (IMHO) is a warning when the setting is in two places (and it is not the same) and it is not clear, in this case, which one has higher priority and it is actually the one used.
Could you repost your now working configuration?
So someone else with similar problems might be able to use it as comparison base.
Hi guys,
I have finally resolved the issue. Everything is working correctly now. Iāve localized the error and brought the system into a state consistent with the advice I received here.
Regarding the defined precedence rules, I believe they are not always implemented clearly or consistently. In my case, for example, the manager setting at the interface level should have completely overridden the profile-level rule, yet having it defined in the profile still caused unexpected behavior and confusion.
Based on this experience, I still question the necessity of having certain parameters, like the manager, available at multiple levels of the configuration structure. It seems more robust to define it only at the lowest possible level.
As requested, here is the simplified logic of my working configuration (on hAP ax2 as CAPsMAN and hAP ax lite as CAP):
On the CAP (ax lite): The manager is set directly on the interface so it knows how to initiate the connection.
/interface wifi
managed by CAPsMAN
set [ find default-name=wifi1 ] configuration.manager=capsman datapath=capdp disabled=no
/interface wifi cap
set certificate=request discovery-interfaces=bridgeLocal enabled=yes
/interface wifi datapath
add bridge=bridgeLocal comment=defconf disabled=no name=capdp
On the CAPsMAN (ax2): The manager is set to 'local' for its own radios, and I have explicitly unset the manager property in the configuration profiles to avoid any ambiguity.
/interface wifi security
add authentication-types=wpa2-psk,wpa3-psk disabled=no name=sec1
/interface wifi steering
add name=st1 neighbor-group=dynamic
/interface wifi
set [ find default-name=wifi1 ] configuration=conf1 configuration.manager=local .mode=ap disabled=no
set [ find default-name=wifi2 ] configuration=conf1 configuration.manager=local .mode=ap disabled=no
/interface wifi capsman
set ca-certificate=auto certificate=auto enabled=yes require-peer-certificate=yes
/interface wifi configuration
add country=Hungary datapath=dp1 disabled=no name=conf1 security=sec1 ssid=my_wifi steering=st1
/interface wifi datapath
add bridge=bridge disabled=no name=dp1
/interface wifi provisioning
add action=create-dynamic-enabled disabled=no master-configuration=conf1
Thanks again for the great discussion and for helping me clear this up!"
I still believe that the "right" way (generically) is to set the manager under
/interface wifi configuration
and leave the single interfaces get it from the configuration.
I read the fact that if in :
/interface wifi
you have to specify the configuration to be used, and then you add:
configuration.manager=<local/capsman/capsman-or-local>
it is meaning:
"use configuration=<name_of_configuration> BUT use INSTEAD of the manager specified there this other one."
At least this would be logic, but cannot say if the priorities are the above or the inverse (the manager in configuration is prevalent).
"Hi jaclaz,
In theory, I can accept what youāre saying, but:
I believe there must be a limit to flexible configurability, beyond which the system simply becomes opaque. If placing a specific parameter in the configuration hierarchy causes operational uncertainty, the best approach is to draw a line. We should make it clear where that value must be set, thereby making its impact on the system unambiguous.
If a parameter cannot be placed freely throughout the entire system (meaning the whole managed network of CAPs and manager(s)), then we must admit that this apparent freedom is meaningless. One might think itās justifiable to make the choice of manager dependent on a configuration profile, but in reality, it isn't. A CAP only knows itās a CAP because you explicitly tell it to look for a manager (referring to @mkx's 'chicken & egg paradox'). I don't think anyone would want to define a device as a managed AP through a complex configuration hierarchy on the CAP itselfāthat would be like shooting yourself in the foot. You would be building local configuration hierarchies on individual CAPs, which works directly against the very convenience a central manager is supposed to provide.
So, I maintain that 'less is sometimes more,' and I believe this is absolutely true in this case."
Not unheard of in programming
https://www-users.york.ac.uk/~ss44/joke/foot.htm
"Classic! Thanks for the link, jaclaz.
I think MikroTik is like an infinitely sophisticated application where you can spend hours designing the perfect safety boots, only to realize the gun has been pointed at your toes for a long time due to a hidden configuration layer. But I love MikroTik.
Iām glad we could wrap this up with a bit of humor. Cheers!"
This thread helped me so farā¦..buuutā¦.
I have the same configuration - hap ax2 and axlite on my second floor as a CAP and a switch as well. Prior to finding this thread, I was stuck at the cap appearing in Remote CAPs section, but the interface was not managed. I finally set the manager correctly for the interface and it appeared as managed and I could see the single SSID with all the signal strenght bars. I finally achieved my goal, after many hours more than Iād like to admit =D.
My laptop can now roam freely throughout the house. However, Iām getting much lower speeds, compared to when I was running two separate SSIDs. Using the same laptop on same place on the table, Iām getting around 80-90Mbit, where on the separate wifi (from the hap ax lite), I was getting 430-440Mbit, so almost fully utilized bandwidth. I have a 1Gbit from the optic fiber GPON coming into the hap ax2. I can measure almost 960Mbit when connecting to the hap ax lite with my desktop PC.
Any idea what might cause this drop of speed? I have traffic processing on CAP, channel set for 2GhzAX. I canāt find any other difference to when the interface was managed locally with separate SSID.
430-440 on hap AX Lite ??
Hard to believe.
Most I have ever been able to squeeze out of it was around 400 ( which is already fantastic given it is only 2.4 GHz).
80-90 sounds like normal speed for most 2GHz access points.
Check frequency channel occupation where that ax lite is located. Make sure it is as free as possible ( which for 2.4GHz can be a challenge).
I do have the advantage of living in a rural area with practically no wifi networks around the house. It seems, that a specified channel and channel width to 20Mhz in the configuration. Once clearing those, I was able to get back to measuring over 260Mbit on speedtest.net, which is a great improvement. Its still not there, but for my 1-2 work laptops purpose its more than enough. Thanks a lot!
Hi SPrajc,
To help you find the root cause of the speed drop, we should first double-check the physical topology and your measurement points. Could you confirm if the following layout is correct?
Assumed Topology:
hAP ax2 (main router):
Follow-up questions to narrow down the issue:
To rule out physical link issues, we need to be sure exactly which segment you tested when you saw the 960Mbit:
Is there a single, direct cable between the ax2 and the ax lite (direct galvanic connection)?
When you measured 960Mbit on the Desktop, was the target of the test the main hAP ax2, or just the local hAP ax lite?
If the 960Mbit was measured between the Desktop and the main hAP ax2, then we know the backbone cable is solid. If you haven't tested the throughput between the two routers yet, I suggest running a MikroTik BTest between them to verify the link.
Once the physical layer is confirmed as 1Gbps end-to-end, we can move on to the CAPsMAN settings.
About 960Mbps, I wasn't even thinking about it.
No other way then direct ethernet connection or it would be simply impossible when AX Lite is in the chain.
@holvoetn: You assume the 960Mbps was an internet speed test, which would indeed confirm the whole path. However, it is not clear from the original post what the other end of that test was.
It surely wasn't over wifi with AX Lite as AP... that I am 2000% sure of.
It could only have been via ethernet. External speedtest or internal, I don't care then.
