CAPsMAN local CAP: all forbid=yes with lo forbid=no causes wireless client connectivity issues

[robertozanandrea]

Hi everyone,

I would like to share some unexpected behavior with legacy CAPsMAN on an RB951G-2HnD running RouterOS 7.23.8 and wireless 7.23.8.

The router manages both its own built-in wireless interface and a remote RB941-2nD CAP.

The local CAP connects to CAPsMAN using 127.0.0.1.

My original /caps-man manager interface configuration was:

INTERFACE FORBID

all yes

lo no

vlan79_main no

With this configuration, two wireless printers (Brother QL-820NWB and HP DesignJet T630) could associate with the SSID but failed to obtain DHCP addresses or respond to ping.

The local CAP remained in the Run state.

The Brother printer showed approximately -82 to -85 dBm signal strength and zero received packets in the CAPsMAN registration statistics.

I tried different channels, 20 MHz width, WPA2/AES, and even downgraded both RouterOS and the wireless package to 7.23.5 while restoring the previous configuration.

Nothing fixed the issue.

The solution was simply changing the manager interfaces to:

INTERFACE FORBID

all no

ether5-wan yes

bridge_wan yes

vlan88_welcome yes

Immediately, both wireless printers started working normally again, including DHCP and ping.

Important firewall detail:

My IP firewall input chain does NOT end with an unconditional drop all rule.

The last rule is:

chain=input action=drop in-interface-list=wan

The WAN interface list contains only lte1 and ether5-wan. Loopback is not blocked by that rule.

I also found this related thread:

CAPsMAN manager can't manage its own wireless

Hi everyone, Anyone would know why on earth my CAPsMAN router is able to properly manage the wifi on my AP, but can’t manage its own wlan interfaces? Please check attached screenshot below, you should be able to see the local wlan interfaces are not enabled. Screen Shot 2017-11-08 at 02.14.51.png Please, what am I doing wrong, this is driving me nuts. Thanks, Pedro. PS: without wanting to be rude, this is the same issue as reported on http://forum.mikrotik.com/t/capsman-does-not-enable-loc…

My questions are:

• Shouldn’t lo forbid=no explicitly allow the local CAP when all forbid=yes?
• Does the all entry take precedence over specific interface entries?
• Is there any known issue with CAPsMAN managing its own radio through loopback?
• Why did the CAP remain in the Run state while the printers could associate but could not exchange data?

Is this expected behavior, or could it be a RouterOS bug?

Any technical explanation would be appreciated.

Thanks!

[BartoszP]

Hi,

Welcome on the forum.

Please write the post again. Do not use AI for that. Please also post the current config as your post is a mess to read and no one is able to guess if

Is this expected behavior, or could it be a RouterOS bug?

Follow this:

Forum rules

Hello and welcome to the Mikrotik forum For all new users that uses RouterOS for the first time and have some questions regarding their config here is short tutorial on how to access RouterOS configuration using "WinBox" and how to export their configuration and posting it properly in their topic. So after you unpack your new device and connect it to the power supply you need to connect it to the PC. Be careful when connecting because to access your new router you need to use one of…

[robertozanandrea]

Hi BartoszP,

Thanks for your reply.

English is not my native language, so I used AI to help me translate and explain the issue. However, all configurations, tests and results are from my actual MikroTik devices.

The problem is real, and I managed to solve it by changing /caps-man manager interface from all forbid=yes to all forbid=no, while explicitly forbidding the unwanted interfaces.

What I am trying to understand is why the previous configuration, with lo forbid=no and vlan79_main forbid=no, caused connectivity problems for some wireless clients even though the CAPs were running.

I will provide a sanitized configuration export to make the setup easier to examine.

Thanks for your help.

[BartoszP]

@robertozanandrea

English is not my native language, so I used AI to help me translate and explain the issue.

Do not worry, mine too and a big part of users of that forum too.
I believe that test were done on your device but AI usually adds a lot of info that is not true as it quite often confabulates.

The best way is to post a config and write in own words what is the problem.
AI could be used to translate but do not ask it to "describe" the problem.

[robertozanandrea]

OK, I’ll post the configuration tomorrow.