I’m sorry I had to solve this quickly and I have already rebooted the router. And now it is working as expected. I did not change any configuration since.
As far as I know, untagged property is settable by config and includes only ports which were explicitly added as untagged ports. current-untagged shows actual running value (if you wish) and includes also ports which are implicitly untagged members of that VLAN (e.g. because they have PVID set in /interface/bridge/port).
Having the opposite (an existing port is on untagged but not on current-untagged) IMO should not happen and that would clearly be a bug (but again there might be a case where this is possible … I’m interested in hearing about it).
Rebooting device would not change the outcome (as it did in your case) if this was the case. However, it seems that there are (minor?) glitches when it comes to L2 configuration (both SW bridge and HW offloaded bridge) where certain changes in settings somehow don’t get applied until reboot. As these problems are of transient nature, they are extremely hard to debug … unless one notices that such case might be going on and take supout.rif files before reboot and another one after reboot … so that MT devs might analyze them and see what might be the difference.
includes also ports which are implicitly untagged members of that VLAN (e.g. because they have PVID set in /interface/bridge/port
Is that so? Even when vlan-filtering=yes and ingress-filtering=yes? If I remember correcly, then setting vlan-filtering=yes will prevent ports dyamically added to the bride’s vlan table.
Rebooting device would not change the outcome (as it did in your case) if this was the case. However, it seems that there are (minor?) glitches when it comes to L2 configuration (both SW bridge and HW offloaded bridge) where certain changes in settings somehow don’t get applied until reboot.
Well yes, the port’s pvid was set to 2 (GREEN) and the port was only added as an untagged port on vlan=2 under interface/bridge/vlan. And yet is was showing up as a “currently untagged” port for vlan 1 (BLUE).
This is solved now, but I had to reboot the router.
Yes. When bridge port is configured with PVID (and bridge has vlan-filtering enabled, otherwise all vlan settings are completely ignored), then port is automatically added as untagged member … unless frame-types=admit-only-vlan-tagged is set (in which case PVID setting is ignored). Bridge setting vlan-filtering doesn’t have anything to do directly with automatic port/vlan membership.
I always wondered what it meant to set frame-types=admit-only-vlan-tagged on the bridge, then add the bridge to the vlan table as untagged. I guess it means nothing, and it is an errorneous configuration?
Whatever settings you see under /interface/bridge/port, e.g. pvid or frame-types, which can be set on bridge itself (/interface/bridge) are about bridge port (CPU-facing port member of bridge).
So yes, setting bridge port with frame-types=admit-only-vlan-tagged and adding bridge port as untagged member of certain VLAN (under /interface/bridge/vlan) is an error which results in asymmetric setup, likely in no traffic between CPU and the rest of bridge port via that VLAN. Because: bridge (the switch-like entity) will untag frames sent out towards CPU while on ingress from CPU it’ll discard untagged frames. So no bi-directional traffic (without some tricks played), but some stuff might pass on egress (e.g. broadcasts and unicasts where destination is not in FDB).
