mdio-mii hw VLAN 1 already used
{"kernel":"4.14.131","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"TurrisOS","version":"5.0-dev","revision":"202260a","target":"mvebu/cortexa9","description":"TurrisOS 5.0-dev 202260a"}}
Observed kernel log during boot time
mv88e6085 f1072004.mdio-mii:10 lan0: configuring for phy/gmii link mode
mv88e6085 f1072004.mdio-mii:10: p0: hw VLAN 1 already used by br-guest
mv88e6085 f1072004.mdio-mii:10 lan1: configuring for phy/gmii link mode
mv88e6085 f1072004.mdio-mii:10: p1: hw VLAN 1 already used by br-guest
mv88e6085 f1072004.mdio-mii:10 lan2: configuring for phy/gmii link mode
mv88e6085 f1072004.mdio-mii:10: p2: hw VLAN 1 already used by br-guest
mv88e6085 f1072004.mdio-mii:10 lan3: configuring for phy/gmii link mode
mv88e6085 f1072004.mdio-mii:10: p3: hw VLAN 1 already used by br-guest
This does not look like a correct behaviour somehow, each switch port that gets enslaved by a bridge other than br-guest trying to occupy the VLAN 1 and subsequently being refuted - that seems at least what the output implies. There could be potential that this might cascades into unintended consequences with the management of VLAN a/o 802.1q.
config interface 'lan'
option type 'bridge'
option bridge_empty '1'
option proto 'static'
list ifname 'lan0'
list ifname 'lan1'
list ifname 'lan2'
config interface 'mgt'
option type 'bridge'
option bridge_empty '1'
option proto 'static'
list ifname 'lan3'
list ifname 'dummy0'
config interface 'guest'
option type 'bridge'
option bridge_empty '1'
option proto 'static'
list ifname 'lan4'