I'm using the new bridge devices to have one bridge for every VLAN, e.g. VLAN 10, 20, 30 I have set up bridges br10, br20, br30. My firewall has got MAC filtering set up which allows only certain outgoing tcp/udp ports from OpenWrt devices to the internet. I noticed my NTP client on the OpenWrt device failing to receive date and time from the internet zone. It was the firewall MAC filter entry which was to blame but on deeper insight, the MAC was correctly set to eth0 of the TP-Link's switch. This was correct before "21.02.0-rcX's network migration". Now, entering "ip a" shows that the brX devices generate their own random MAC address for each bridge on reboot. This auto-generated MAC can be seen from "arp -a" on the network, observed by a Win10 client.
I need to put the correct MAC where br10 (management VLAN) can see the OpenWrt device onto the firewall. How can I do this, because it's randomly changing after each reboot?
Is there a way to "safely" use the eth0 (or another according to a pattern) generated MAC to make the bridge's MAC static like before in 19.07.x?
Is it valid to use e.g. the same static MAC on br10, br20, br30 as they're VLAN separated networks?
I tried looking at docu for the new DSA settings, and it seems still a bit thin on the ground. But how about trying traditional arguments, where you specify e.g. 'mac'? Otherwise hardware might need patching. What do you run?
I could edit the MAC of the bridge device in LUCI, but which MAC is valid for there? Should I use the eth0 (physical switch) MAC which is also printed on the bottom of the device?
Very strange: running "ip a | grep br10" showed the random mac address, and putting this one to the firewall's mac filter table solved the connection problems.
I've now rebooted all TP-Link Archer C7v5's and the MAC addresses got auto-generated as follows which looks okay to me (I visually remember eth0 = wlan1 was the case before, even on 19.07.x).
Basically a good idea, but I have also a wifi manager script for "Alexa, turn on guest wifi" which modifies and remotely applies the new /etc/config/wireless at runtime.
I can now reproduce the problem with getting random MACs on my bat0.X bridges out of the blue after some OpenWrt usage timespan. I am still WAITING for the br-vl177 != eth0 MAC problem to reoccur.
