I have a bridge with ports: eth1 , wlan1 and a vAP (ap-bridge) interface of wlan1. (ros 6.42.3)

Eth1 has the "lowest" mac of all, yet the bridge keeps taking the mac address of the vAP. (i read on the forums from user citing the manual- that a bridge with all defaults, will take the mac of the "lowest mac" of its member ports). However i show that the rOS manual now says, the bridge will take the mac of the first interface "up"

This is an issue as we often times need to switch the vAP on / off (or add a 2nd vAP, at times), thus the bridge mac changes and all traffic stops for 10-15 seconds (as the physical switch connected to eth1, has to re-learn new mac address stp/rstp), and also the MTs IP changes (as its running dhcp-client on the bridge).

normally this wouldn't be a big deal, but with over 100 MTs that this needs to be fixed on, its not going to be easy (and it appears that you can set a bridge's admin-mac via winbox, but you *must use the cli* to disable auto-mac=no ??). + on any newly deployed devices we have to keep a list/be sure that no mac's are duplicated.

Also, if the bridge takes the mac address of the 1st interface UP (i guess at boot, or bridge creation), then why when i enable a disabled vAP does the bridge mac change (ie it now takes the mac of the vAP i just enabled, which clearly is not "the MAC address of first bridge port which comes up ".

Am i correct in all this? or is there a way for the bridge to take the eth 's mac address by default?
(i notice mikrotik ETH mac addresses always seem to be lower than the wireless interfaces's mac addresses, atleaste on mt branded wifi hardware)

tks

ros manual:
One MAC address will be assigned to all the bridged interfaces (the MAC address of first bridge port which comes up will be chosen automatically)

to update- i got a reply from mt support-
(in regurads to bridges, and them taking the mac address of a vAP over all other member ports):

"currently it will assign the MAC address of the first interface that is up, virtual interfaces are a bit more likely to be up first."
We do not have plans to chnage this behavior.
---

the suggestion solution is to manually set a mac address for the bridge of the mac address of one of the ether member ports, via auto-mac=no , admin-mac=...

I didnt realize the bridge could have the SAME mac as one of its member ports (so that addresses my concern of using a made-up mac from the IEEE Reserved mac range, and having to keep track of them so as to not duplicate them on another device's bridge later).
As this is the case, it will be easy to script this for my existing MTs, and to manually set this for any new deploys.