with swconfig to manage port tagging (tagged/untagged/off). But that gone and along with it the LuCI VLAN section it is unclear to me of how to mange port tagging for a DSA switch.
is there some stanza to be added to the implizit notation of iface.X (that creates the VID), e.g.
iface.X iface.X.t iface.X t t iface.X t.iface.X
or something to that extent? Or is there some other logic applicable?
The documentation I looked into does not appear to contain that information, unless of course I missed somehow.
One of the challenges of use of DSA is that swconfig and the associated UCI is not architected for DSA, but for the switch chips that OpenWrt typically uses.
DSA typically needs to be configured with ip tools directly, assuming that the DSA driver in question can even handle VLANs. qca8k, for example, at least a couple months ago, even in Linux 5.x, can't.
If you “believe the hype”, ip bridge should magically be understood by the driver. At least as I understand it, you should be able to address each of the switch ports directly, setting up VLAN tagging on each through ethN.1234 notation.
In my (limited, as the device itself is obsolete) experience with a DSA capable driver on a tl-wr941nd v2 (100 MBit/s Marvell 88E6060, which might -or might not- be similar to more modern DSA drivers), you do end up with lan1-4 && wan interfaces (ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" "wan"), which can be tagged or bridged as needed - all the magic of configuring the switch fabric accordingly happens behind the curtain (by the DSA module).
ought to share input from the Turris Omnia developer team
The true is that swconfig is no longer available so switch sections in /etc/config/network are obsolete and they no longer work. On the other hand there is no feature lost. VLANs work and are even easier to configure than before.
The difference between swconfig and DSA is that in case of swconfig you have to configure both sides. You have to configure switch using swconfig including port to CPU and you have to configure CPU interface to switch. This is no longer required. DSA manages switch for you. You now have lan interfaces “exported” to CPU and you can bridge them to create separate lan. Tagging is as easy as tagging CPU port. In Luci you just name port lan0.1 and given interface will be tagged 1. You no longer have to manage and tag CPU<->switch ports. Also note that no traffic is forwarded to CPU unless you assign address to bridge. Setting protocol none allows you to create vlan that does not go to CPU at all. If you want to have some port dedicated to specific interface then it is as easy as using that lan interface as any other ethernet interface.
But why do you need VID3 in this case, as it is untagged it will only be valid inside the switch itself. I agree that you found differences between swconfig and DSA, I simply do not yet understand why these actually should matter? If you could state a use case in which the hidden VID3 is important I would love to hear it.
I did not initiate the thread to get into a discussion of "do you really need this feature? (aka state your use case)". But rather to figure of how to get it working.
It is considered good practice to move traffic off the default VLAN where possible, in order to minimise the extent to which an unconfigured switch port would give access to the network.
This does not mean that a network which uses the default VLAN is necessarily insecure, and vacating it may not be feasible since some devices have functions that are hardwired to a VID of 1. However, if you have the opportunity to use a different VLAN then that is usually preferable.
And another reason is VLAN filtering which provides for less cluttered topology
Lastly - there is quite a number of users with such scenario (specific VID with untag state) for whatever their (different) use case is, if you were reckoning me being the sole one.
Hope that otherwise we could stay on topic and not debating whether mine or someone else's use case justifies this thread topic in the first place.
seems like bridge vlan add vid [X] dev lan[N] untagged pvid is the way to go.
[X] = VID
[N] = lan port
Just I do not see that UCI is able to parse it somehow from a config file, or rephrasing - how that would translate into a config setting being parsed by UCI.
also raising the question about setting a PVID with UCI for DSA as it used to be possible with swconfig?
How to express non-swconfig configuration is not an agreed-upon thing, or perhaps even discussed yet.
If you're going to work with DSA at this time and want anything but default config, you will need to configure it with sh scripts, not with UCI, as far as I know.
a use case basic example for untag 802.1q frames, br-lan enslaving lan0,lan1,lan2
bridge v a dev br-lan self vid 2 untagged pvid
bridge v a dev lan0 vid 2 untagged pvid
bridge v a dev lan1 vid 2 untagged pvid
bridge v a dev lan2 vid 2 untagged pvid
sysctl -w /sys/class/net/br-lan/bridge/vlan_filtering=1
sysctl -w sets the filter in motion and thus to be last or else access to the node could be cut off.
is not the same as lan0.11. If I bridge lan0.11 & lan1, then a client connected to lan0 cannot get an IP while lan1 works just fine.
How do I get this behaviour with DSA: untagged packets arrive on lan0 and then get tagged? I just need to isolate the wired ports and I do not use smart switches.