Bridge port "is already a slave" after updating to newer RouterOS versions

RouterOS Beginner Basics
1

I’ve been using the long term update channel for awhile now, after noticing that my WiFi became extremely flaky after upgrading to newer versions. Today I finally had some time to diagnose the issue, but was unable to fix it. I noticed that only the 5GHz network stopped working and that the associated bridge port is inactive with the error "is already a slave". I was unable to find out why. My cAP has a similar config, but that upgraded just fine. I hope someone is unable to pinpoint the issue and that this is the proper category for this question.

The (hopefully) relevant parts of my config:

<cut partial config>
2

I am sorry to say that configs generally make me go cross eyed.

But let's start with what kit you have and what wireless you are expecting.

You have some sort of Chateau pro ax which is itself an AP and you have another AP?

You are expecting to find SSIDs 'Trusted' and 'Untrusted' from both units on both 2.4 and 5, which is working for the other AP but not for the Chateau? Can you confirm this and say what you are actually seeing from the Chateau?

3

Could it be that the 5GHz radio was manually provisioned from CAPsMAN?

4

>> You have some sort of Chateau pro ax which is itself an AP and you have another AP?
MikroTik Chateau PRO ax and MikroTik cAP ax.

>> You are expecting to find SSIDs 'Trusted' and 'Untrusted' from both units on both 2.4 and 5

  • Trusted is 2.4GHz and 5GHz.
    • Normally I use the same SSID for 2.4GHz and 5GHz, but due to this issue I splitted the SSIDs.
  • UnTrusted is 2.4GHz only and a slave of Trusted 2.4GHz.

>>which is working for the other AP but not for the Chateau? Can you confirm this and say what you are actually seeing from the Chateau?

Yes. This setup works on older RouterOS versions (7.20.x) on both devices. On the current stable (7.22.3) and long term (7.21.4) the Chateau allows devices to join the network, but these disconnect, I assume due to the bridge port no longer working.

5

>> Could it be that the 5GHz radio was manually provisioned from CAPsMAN?

I don’t use CAPSman, but how do I check this?


[admin@MikroTik] /interface/wifi/capsman> print 
                   enabled: no  
  require-peer-certificate: no  
              package-path:     
            upgrade-policy: none
  generated-ca-certificate: *1  
     generated-certificate: *2  
[admin@MikroTik] /interface/wifi/capsman> export 
# 2026-05-11 09:10:39 by RouterOS 7.22.3
# software id = K9WK-QCYD
#
# model = H53UiG-5HaxQ2HaxQ
# serial number = HH90A4ECZ4Y
/interface wifi capsman
set package-path="" require-peer-certificate=no upgrade-policy=none
6

Reset the wifi1 interface and reconfigure it.
Also check asterisks in the config, which could indicate problems.

7

How do I reset the wifi1 interface? It can’t be removed.

8

/interface/wifi reset wifi1

9

For solve some "*" problems, paste this on terminal

/// removed ///

updated script here: Bridge port "is already a slave" after updating to newer RouterOS versions - #16 by rextended

But don't make the usual presumptuous mistake:
paste the entire configuration.
(Obviously, be EXTREMELY careful not to post your username/password or serial number on the forum.)
Consistently censor the sensitive parts without removing them.

Since CAPsMAN is disabled, you can ignore these read-only values.

10

I’m quite positive I only left out irrelevant stuff such as firewall rules, wireguard config, adlist config, IP address allocations, static DNS records. I don’t see any of these being relevant for this issue.

11

Okay, I'll leave you to your own device, but check out all the other topics...
Often, the "I know where the problem lies" people... don't solve the problem...

(ok, for sure not lists static DNS and dhcp leases or firewall address lists, no scripts and no schedules...)

12

Likely NOT relevant to the issue at hand, but check point #21 here:
GP & CSA (Good Practice and Common Sense Advice) for Mikrotik devices
a partial configuration with asterisks in it is a sure sign of a mis-configuration, that may extend also to the non-posted part.

JFYI, you are in blatant violation of Rule #12:
The twelve Rules of Mikrotik Club
(there are reasons why the more experienced members ask for the FULL configuration)

13

Here you go.


<cut old config>
14

I'm sorry you didn't trust me...
Maybe it's precisely those errors that create that problem...

15

I don’t see how this has any relation with the wifi interface.

16

What's the point of trying? At most, you'll solve other problems...

Given the rest of the configuration, the script to paste is this:

# fix *9 error (default "bridge") and set to default values ​​(they have never been set by the user)
/disk settings
set auto-media-interface=none auto-media-sharing=no auto-smb-sharing=no

# fix *2000011 error (default "LAN")
/ip neighbor discovery-settings
set discover-interface-list=LAN
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
# this is for 2 rules (input and forward), with same description
/ipv6 firewall filter
set [find where comment="defconf: drop everything else not coming from LAN"] in-interface-list=!LAN

# alignment with NEW default values on RouterOS 7.22.3 ​​(they have never been set by the user)
/interface ethernet switch
set 0 cpu-flow-control=no
/interface ovpn-server server
remove [find]
/ip ipsec profile
set [ find default=yes ] dpd-interval=8s dpd-maximum-failures=4

# remove unused datapath on wifi settings
/interface wifi datapath
remove [find]

and an extra script, not related to the problem, for use the new fasttrack, if the device support it:

/ip firewall filter
:execute "/ip firewall filter set [find where comment=\"defconf: fasttrack\"] hw-offload=yes"

/ipv6 firewall filter
:if ([:len [find where comment="defconf: fasttrack6"]] = 0) do={
    :execute "/ipv6 firewall filter add chain=forward action=fasttrack-connection connection-state=established,related comment=\"defconf: fasttrack6\" \
                                        place-before=[find where chain=forward comment=\"defconf: accept established,related,untracked\"]"
}

because this:

17

EDIT: mixed the descriptions with the script before

18

Simple: Maybe if some internal function that checks whether interface are already busy or not fails due to unsatisfied *xxx indexes,
perhaps by removing the errors the function executes correctly.

Just copy and paste the script here: Bridge port "is already a slave" after updating to newer RouterOS versions - #16 by rextended.
All the instructions are clearly visible, and anyone on the forum can see them.
What's the harm in trying?

19

Thanks. I’ll try your suggestions this afternoon/evening and get back to you.

20

I’ve made the changes you suggested. Unfortunately the issue still persists; Trusted5 is still “already a slave” after re-adding the bridge port. New config:

<removed this non-working config>