I have two Wireless devices: a hAP BE3 media and cAP AX which are connected to a CRS326 and managed by a RB5009 in the new wifi section.
Each were added by rebooting them into CAP mode.
I'm using a single ssid with PPSK which land devices on a specific VLAN based on the passphrase. Everything works great and works as expected.
What I noticed however:
On the hAP BE3 I had to configure the trunk port back to my switch and as I'm using the other ports for devices, have configured VLAN filtering and PVID settings on each individual port.
On the cAP however, I've not had to do this. And in the bridge settings I don't see VLAN filtering enabled.
Is there a fundamental difference between how the hAP and cAP are configured? Should I expect VLAN filtering to be enabled on the cAP too?
Basic truth: CAPsMAN only provisions wifi interfaces ... to the extent of adding them to a bridge. CAPsMAN does not provision any other parts of CAP ... and that includes default bridge.
That being said ... default (non VLAN aware) bridge happily passes VLAN headers with ethernet frames ... so if ingress frame has 802.1Q header attached, it will be kept intact upon egress. What VLAN-unaware bridge does not do (compared to VLAN-aware configuration) is that it doesn't care about bridge port membership ... essentially it works as if all ports were members of all VLANs and all ports had frame-types=admit-all set. When using wifi-qcom or wifi-mediatek drivers with vlan-id set, it's the wifi driver who does tagging ... so frames, entering bridge through wifi ports, will already be tagged. Wifi driver will also do the untagging, so any frames egressing bridge towards wifi port with 802.1Q header attached will be properly handled by wifi driver.
If you need bridge set up as VLAN-aware (because wired ports have to be handled with respect to VLAN settings), then you have to set up bridge with respect to VLANs set up on wifi ports as well. That includes adding upstream trunk port as tagged member to relevant VLANs (i.e. those which are used on wifi interface but are not used on wired ports). If device is used as router, then the "upstream port" is CPU (so bridge the CPU-facing port) and that port has to be made tagged member of all relevant VLANs.
Thank you for your detailed and comprehensive answer, that's really helped cleared things up for me.
With regards to the cAP where in my environment the second port is unused, is it worth enabling VLAN filtering at all?
As far as I understand there's no performance benefit/degradation as the switch chip isn't capable of VLAN hardware offload and wifi traffic goes through the CPU anyway. The only benefit I see is I can see dynamic interfaces being populated as wifi clients connect in /bridge/vlan
And if one goes for VLAN-aware bridge, then one has to carefully configure VLAN membership of ports ... if that's configured too permissive (e.g. setting wifi interface member of VLANs 2-4094), then there's no point in enabling VLAN functionality. Using VLAN functionality in this case is only sensible if one configures VLANs in a restrictive manner ... because this adds (or might add) some security on L2. And even then only minor as it's still device admin who configures VLANs on wifi interface.
OTOH it's a good exercise to configure VLANs properly on all devices and ports ... which adds consistency into the whole setup. And consistent setups are less error-prone IMO.