Not questioning at all, but rather trying to understand the use case to help with a proper solution/workaround. Oh, well…
Ok now I know what @anon50890781 means.
First of all there is nothing like untagged vlan with VID. That is like having TCP stack without lower layer like IP. It does not make sense. You just don’t understand swconfig configuration as it seems.
Ok so what following configuration meant with swconfig:
config switch_vlan
option device 'switch0'
option vlan '3'
option ports '5t 2'
option vid '3'
First of all port 5 is CPU port. This instructed switch to create VLAN over port 2 and CPU port where traffic on CPU will be tagged. That means that it will be received on CPU port with tag 3.
In case of DSA you can just use plain lan2 to have same functionality.
3 Likes
I guess the biggest question I have seeing this is, what behaviour do you expect? In that specific case the VID does not seem to serve any obvious purpose, so my understanding is that this should isolate LAN2, so I guess the closest in DSA would be to take LAN2 out of the lan bridge, instead of using the SoC portN.3 to talk to LAN2 you simply keep talking to LAN2 as that now represents itself as an ethernet interface.
Sure this is not exactly the same approach as with swconfig, but it should effectively give you similar capabilities. As far as I can tell the upstream kernel blocked swconfig and requested DSA so unless it can be shown that DSA is unfixable and does not offer the required capabilities I believe it is here to stay, so we as a community will have to learn how to express our configurations in DSA-speak.
@cynerd beat me to the punch…
I concur with @anon50890781 that things will be slightly different, but I believe we will need to make this jump sooner or later anyway…
I still stand behind that there is no jump to make. If you ever configured VLAN on Linux box then you know all you need to know to configure DSA. I would even say that DSA gives you more tools because there are stuff you are able to do in Linux but not with swconfig.
It is just clear now, I thing, that swconfig design was misleading. I wasn’t at first aware that there might be some misunderstandings introduced by swconfig it self. Its limiting design where one VLAN can have only one tag created probably this misunderstanding. switch VLAN and 802.1q are not not interlinked per say. VLAN creates lan network between different ports where 802.1q packs multiple other ports in one port. 802.1q can be used without vlan as well as vlan can be used without tagging.
1 Like
I am afraid not - untag packet gets PVID on egress that is derived from the VID and thus defaults to 1 unless otherwise specified.
If however the iface is specified with an appended VID it automatically defaults to tag state.
VLAN filtering relies on PVID, if all PVID are the same (default 1) it would obsolete the filtering.
Then why would enabling VLAN by appending the VID to the iface automatically provide 802.1q protocol functionality on such iface?
That is the last from me on the subject in this thread since it seems superfluous. Pretty sure that this will pop up again for any user of current TOS3.x that having VLAN untag state enabled and making the transition to TOS4.x
The problem is that patches we need are only in kernel 5.0 (or maybe even newer). We have patchset for Linux 4.19 but not for 4.14. The problem we are currently in discussion is if we should backport kernel 4.19 or patches on 4.14.
Original idea was to migrate all Turris 1.x users directly to TOS 5.x and just skip 4.x but upstream decided to stick with kernel 4.14 with OpenWRT 19.07 so we are out of luck there. This means that we now have to decide what will be our approach and we still are in discussion about that.
Best thing to do in this case is to create a wiki entry I think. Hope turris team will do this.
Kernel 4.14 is wrong way, EOL will be in next few months. OpenWrt will support also 4.19.
2 Likes
Tos4 has been in development for quite some time
OpenWrt master already supports kernel 4.19 for some targets (E.g. mvebu - Turris Omnia, Turris MOX was recently updated to kernel 4.19 in master) , but upcoming OpenWrt stable version (19.07) comes with kernel 4.14. It’s their decision.
Source:
http://lists.infradead.org/pipermail/openwrt-devel/2019-May/017048.html
And current Turris OS also using kernel 4.4 instead 3.18 from OpenWrt 15.05.
But it should be possible to still use lan0 for another bridge.
Or you could e.g. bridge lan1.5 with lan0 or whatever your usecase is…
Just my 2 cents on what you might misunderstand, nevermind if I am wrong…
Fine, one last time then - this is not about some high level issue or use case that needs solving, it is simply about functionally that is provisioned in TOS3.x but but not TOS4x concerning 802.1q protocol management.
Now, it just needs to be distinguished what provides said functionality.
- there is no loss of VLAN functionality with the introduction of DSA
- there is loss of 802.1q protocol management functionality with the introduction of DSA since UCI, for the time being, is not integrated with DSA. This is also reflected by the no show of VLAN/802.1q settings management in LuCI
To retain advanced 802.1q settings (for whatever the use case), other than 802.1q enabled tag state, such as - untag state, off state, assigning PVID, between reboots it requires currently init scripting utilizing Linux tools such as
bridge vlan
Now my missing usb device works:
dmesg
[ 13.377875] usbcore: registered new interface driver usbserial
[ 13.383819] usbcore: registered new interface driver usbserial_generic
[ 13.390404] usbserial: USB Serial support registered for generic
[ 13.420130] usbcore: registered new interface driver cp210x
[ 13.425833] usbserial: USB Serial support registered for cp210x
[ 13.438807] usb 4-1: cp210x converter now attached to ttyUSB0
lsusb
Bus 004 Device 002: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB lightIs this really TOS 4.0? I encountered this error in 5.0+ last week and fixed it but I am not aware of the same happening in 4.0.
Where I can download nighly build?
that is the HBD branch and depending on your device medkit is available from Index of /☞🐉/
Or alternatively from the cli switch-branch hbd
!
Can and will break regularly, not meant to be used on daily basis, more just for testing.
@anon50890781 that is not exactly true.
@viktor as a nightly builds can be considered all branches with exception of HBT (intended for testing next stable) and HBS (for current stable).
HBK are builds of latest development version based on same OpenWRT release as HBT and HBS. This is effectively branch we used to prepare next minor Turris OS release (4.x).
HBD are builds of latest development version on next OpenWRT release. This is effectively branch used to prepare next major release (x.0).
This is described more in depth, including considerations, in text you get if you run switch-branch without any arguments.
2 Likes
Yes and no. If I configure the other ports in a similar way (5t 0, 5t 1, and 5t 2), add all four of them to the same bridge br0, and put the bridge into a guest firewall zone, then I can use kmod-br-netfilter with echo 1 > /sys/class/net/br0/bridge/nf_call_iptables to prevent the those ports from talking to each other while belonging to the same bridge.
Having this config simplifies the configuration a lot: a single bridge with a single IP range can now include wired ports and AP’s and deliver complete isolation between wired ports and between wired ports and APs.
I tried this setup with lan0/1/2/3 (OpenWRT 18.06 latest) and the devices connected to different ports can still ping each other. Can you suggest how to achieve this with DSA?
An alternative is to create an interface per each port and AP and add them all to the guest firewall zone, but that is a lot of interfaces and IP ranges vs a simple config before.