Perhaps things slightly changed with event of bridge vlan-filtering ... in previous times, when bridge was sort of a dumb switch, bridge interface happily utilized packets belonging to VLAN ID 1 just the same as explicitly untagged while one had to use VLAN interface for the rest of VLANs. This might explain why pvid=1 is default setting ... to keep (broken) bridge port behaviour the same as it was before 6.42.This is, fortunately or unfortunately, not true. I used to think the same until I've found out that it is not VLAN ID 1 which is always handled untagged but it's actually "the VLAN ID which is configured as bridge's own pvid parameter" which is treated as untagged on the bridge. If you change bridge's own pvid to something else than 1, VID 1 starts behaving normally.Mikrotik uses VLAN ID 1 as synonym for untagged
I guess this is the origin of @sindy's explanation about what happens on the bridge.
But then again, setting bridge's pvid to some other value and setting member interfaces' pvid to the same value re-instate the same behaviour ... seemingly untagged packets on bridge, but my own simplification covers that variant just the same.
Anyhow, I'll stop bitching about this ... it is one view vs. another one and unless some MT developer explains the way it's really implemented in ROS it's all just guessing.
There's a distinction between untagged frame and frame tagged with VLAN ID=1. The former has ethertype value 0x0800 (or, if it's not about IPv4 packet, appropriate ethertype value), the later has (outer) ether type 0x8100 with additional header (3 bits PCP - priority code point; 1 bit DEI - drop eligible indicator and 12 bits VID with value of 1 in this particular case) followed by usual ethertype 0x0800 (or, if it's not IPv4 packet, appropriate ethertype value)./interface bridge port
add bridge=bridgeHallway comment=defconf interface=ether1 (pvid=1)
add bridge=bridgeHallway comment=defconf interface=DevicesHallway pvid=45
/ip bridge vlan
bridge=homebridge untagged=ether1 vlanid=1 is correct as it is consistent with the other interfaces
But what does that mean.......... Will the CapAC remove vlanID1 from packets going to the WLAN?? and the packets will have vlanid0 and if so how will that affect devices connecting??
As you can surmize I am still not sure how to handle the bridge vlan for my capAC for ether1
So in the latter case, receiver would have to know how to deal with 802.1q frames (or blindly strip them which would become a problem in the other direction if switch/router actually expected 802.1q frames with VID set to 1) while in the former case it really is about truly untagged, plain ethernet.
In the quoted case cAPs really should strip VLAN headers even with VID=1 not to confuse wireless clients.