Do I really need to create an extra bridge device myself?
So far I have entered the ports directly at the interface and as I understood it, a corresponding bridge is automatically created:
Everything seems to work as it should in my case - untagged ends up in lan and everything with VLAN ID 3 ends up in office.
Is there a problem if I configure it this way?
Hmm....
I think that this guide is currently only right for master, but not for the forthcoming 21.02 release, right? Your brand new port / bridge device related config changes have not been backported to 21.02.
If I have understood the situation right, you might clearly specify in your message that to which branches this guide applies.
Ps. And as 21.02 does not know about the new config syntax, it will be impossible to downgrade from up-to-date master to a 21.02 build is DSA if used, right?
21.02 has full DSA support if your device has DSA support. But 21.02 doesn’t have LUCI DSA config support.
But there are no problem moving config files from master snapshot back and forth to 21.02 (done that my self). The problem is actually going back to 19.07 if you have installed 21.02.
I have my config running on 21.02 rc1.
So you mean in future releases I can no longer use this but must configure it as in the tutorial here? - I hope not....
Yes. UCI sections interface are meant for layer 3 configuration. Bridge works in layer 2 and should use UCI section device.
What you are using is legacy (deprecated) syntax that the recent LuCI doesn't support anymore and is planned to be dropped at some point.
Related commits:
Absolutely. It was just easier for me to sit down and write quickly this tutorial without integrating it into existing wiki content. I'll work on that later.
Nice trick: Make the file configuration much more cumbersome than before to push people towards LUci.
But of course - I can understand the reasoning behind it - I still found the previous solution pretty smart and now it sadly becomes significantly more cumbersome.
Why? Cumbersome is to mix both L2 and L3 configuration. It doesn't make sense, they're independent layers and should be treated as such. The new DSA configuration in UCI is, in fact, a lot similar in intent to the old swconfig, with a more explicit structure. The extra verboseness makes it largely self-documenting (the exception being the PVID configuration which, granted, is rather cryptic).
Yes - for my sake, this corresponds to pure doctrine.
In my practice, however, the configuration of a new network is always a combination of L2 and L3.
And even if I am always aware that I am working on several layers of a theoretical concept at the same time, I have no noticeable disadvantage when I do this combined in one place.
What is the bad consequence if I also set layer2 settings in the interface section?
9 additional lines with named links to other places in the configuration file with completely the same final result do not promote clarity for me.
A solution which respects the layer concept and could be configured similarly elegantly as the past ifname solution would have been dearer to me simply than the construct which was presented here. And yes - the concept is quite clear to me - but so was the previous one.
But I am neither a network expert nor an active developer - this is just the view of a normal end user.
So consider my limited knowledge and inability to fully assess the consequences of such a decision. I therefore plead for nothing and ask no one to reconsider the concept - I only regret that the solution, which has been elegant for me so far, is to be abolished.
The lines and levels aren’t for you, they are for the computer. It will be more efficient data moving if the CPU knows where to send the data before manipulating the data in the receiving interface instead of manipulating the data and then realize it was sent to the wrong place.
To be honest I now think the DSA setup is more logical and easier to use when building up more complex systems in comparison with the swconfig.
In swconfig there was a completely different manual config system for PVID. And that never ever received LuCi support, to be honest not many complained about that. So the ones not complaining about pvid probably didn’t use VLAN in any great extent or didn’t know how the VLAN standard worked. Because every single manageable switch I have played around with always had both VLAN and PVID settings in the GUI.
So the old swconfig with both vlan, pvid and interfaces was a lot of config lines in comparison with DSA if the VLAN starts to build up in numbers.
Now with DSA we actually aim to comply with a network industry standard.
I have left both gui and hand tapping, now my metode is about 300 lines (in 19.07.7) and about 250 lines (in 21.02 ) and it does exactly the same configuration of UCI code with a config script.
Could you please advise how wifi interfaces/devices should look like with DSA/new config notation?
Like, how would you define a home and guest networks through multiple APs where home would be a wired and wireless network (ssidA), and guest would be a separate wireless (ssidB)? So far guest wifi interface with VLAN and trunk port defined on switch level solved this. I dont exactly see how this could be done now.
I have not been able to assign a wifi interface to a VLAN no matter what I did. All I could do was to specify a new subnet and attach the two radios/wlan0/wlan1 to it. Less than idea, as it just makes more of a mess of IP address spacing to keep track of when I perfectly have proper VLANs already defined.
Would you mind sharing your config so I can assign my wlan0/1 to an existing VLAN? I have spend close to 2 days on it and couldn't get it to work. I'd appreciate it.
- a fine conclusion.