I’m following the guide, it mostly works except that vlan-id is only applied to the slave port and not the master.
On CAPsMAN both CAP interfaces properly display vlan-id as was set. But on the CAP /interface bridge port print only shows correct pvid for the slave port. The master port shows the default pvid=1. Additionally, contrary to the guide, only the slave port is marked as dynamic.
Am I doing something wrong or should I just manually set pvid on the interfaces?
No to both parts of your question..
The Bridge in context is the Bridge at the Capsman-Router, not the Bridge at the CAP.
I see where maybe this guide given in the link is somewhat “tricking” a reader into thinking that the depicted Bridge Port print is actually on the CAP side, as it is put in the CAP section of the Guide.
But it clearly states, that this is the Caps-Router.
Hmm, I understand that CAPsMAN fully manages CAP’s wlan interfaces. But I’m surprised to see misleading information on CAP’s bridge port, especially given that for the slave interface pvid is as I expect it.
Do you know a way to confirm that packets that are entering bridge get tagged with as I want them? I cannot figure out how to sniff traffic on switch/router side of a port.
0 H ether1 bridge1 yes 1 0x80 10 10 none
1 D wlan1 bridge1 10 0x80 10 10 none
2 D wlan5 bridge1 20 0x80 10 10 none
Clearly the state of the bridge ports was captured on CAP. Moreover, CAPs wlans are not even added to CAPsMAN (although the UI/CLI seems to allow to do this manually, it seems pointless for local forwarding).
…Aggree with you on the last part, as I thought you’d be using your setup in manager forwarding mode,So I’ve been referring to the second part of the guide.
So, maybe you did not follow the guide entrirely? PVID=1 is the standard ID, system wide…so maybe you actually want that VLAN-ID on that interface or you did not follow the guide?
Besides, on what VLAN is the DHCP-Server listening/responding for WiFi-Clients on that wlan interface?
If the VLANd is ID=10 for example and IPs are handed out on that VLAN and not by a DHCP-Server on VLANID=1, I’d say it works as designed.
I can’t test, as I happen to have my Master WLAN-Interfaces on ID=1 by design (or on account of being lazy).
/caps-man manager
set ca-certificate=CAPsMAN-CA-… certificate=CAPsMAN-… enabled=yes require-peer-certificate=yes upgrade-policy=suggest-same-version
As you can see the bedroom-* interfaces have inline vlan-id=2 while iot-2.4 has vlan-id=99 through the “Matryoshka IoT 2.4Ghz” config.
On CAP’s /interface bridge vlan print only the iot-2.4 interface is recognized as tagged for vlan-id=99. The bedroom-* interfaces are untagged for the dynamic vlan-id=1.
I have also noticed that the physical interfaces on the CAP for bedroom-* cannot be deleted and, unlike the virtual-AP interface created for iot-2.4, can be edited in /interface bridge port.
IMHO all the vlan config needs to go with “/caps-man configuration path”. So why not create one config with vlanid=2 that then gets applied to that specific CAP?
..but then, what is actually the ID used for traffic?
For example on the interface “bedroom”…is it vid=2 or vid/pvid=1 ? … attach a dhcp-server with a different pool to each vid and see which one feeds IPs to clients that connects to that interface.
Alright, looks like I figured out what I was missing: on the CAP I had to manually mark the CAPsMAN managed master interface as tagged in /interface bridge vlan for the vlan-id I set on the wireless interface on CAPsMAN
Did you add wlan interface (the master wlan) to bridge on CAP manually, before configuring device as CAP client? If you use CAPsMAN to provision wireless interfaces on CAP, this should not be done.