Turris OS 4.0 beta4 is released!

Found this link with a VLAN config example. Yeah, it should work.
And if the VLAN config is not converted automatically during the upgrade, it is not a big deal to add it.

1 Like

Well, it might be a bit more complicated than I initially thought: this and this (The very last comment in the second link is informative).
Unfortunately, I am not in the position to test at this time.

Could not get PVIDs working via (L)UCI parsing from a conf file only via cli, e.g.

bridge vlan add vid 5 dev lan2
ip l add l lan0 n lan1.7 type vlan id 7

Should this be normal operation for all devices on 18.06? I have several other routers running in ap-configuration with luci or /etc/config/network configuring successfully the VLANs…

All/any of them DSA(SWITCHDEV) managed?

swconfig is gone for the TO with 18.06


I just now figured figured out via /etc/config/network - seems easy,simple and straightforward - e.g. just having added list ifname 'lan0.5' to

iface
config interface 'lan'
	option type 'bridge'
	option bridge_empty '1'
	list ifname 'lan0'
	list ifname 'lan1'
	list ifname 'lan2'

ip -d a s lan0.5 then turns out

lan0.5@lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
link/ether d8:58:d7:00:79:7a brd ff:ff:ff:ff:ff:ff promiscuity 1
vlan protocol 802.1Q id 5 <REORDER_HDR>


Seems that VLAN filtering is also supported

gzip -cd /proc/config.gz | grep CONFIG_BRIDGE_VLAN_FILTERING

CONFIG_BRIDGE_VLAN_FILTERING=y

That’s just what I’ve always been doing. :blush:

So i assume the configuration part with vid etc (normally in the lower part of /etc/config/network) is obsolete by now?

How would I get this information?

querying the kernel config, not sure how on other nodes, on the TO e.g.

gzip -cd /proc/config.gz | grep DSA

CONFIG_HAVE_NET_DSA=y
CONFIG_NET_DSA=y
CONFIG_NET_DSA_TAG_DSA=y
CONFIG_NET_DSA_TAG_EDSA=y
CONFIG_NET_DSA_TAG_TRAILER=y
CONFIG_NET_DSA_MV88E6060=y
CONFIG_NET_DSA_MV88E6XXX=y
CONFIG_NET_DSA_MV88E6XXX_GLOBAL2=y


It appears to be so for TO featuring a switch with DSA capabilities (but do not take my word as gospel). That might be different on other boards.

1 Like

Ah, wait, I do/did not use lan0.5 but eth0.5.
Seems none of my other access points is using DSA (otherwise VLAN wouldn’t work anymore)…

Are you tagging ports? Without swconfig I do not see how to manage tagged/untagged/off.

Is not this how it is done?

config device
	option type '8021q'
	option ifname 'eth0'
	option vid '106'
	option name 'vlan1'

config device
	option type '8021q'
	option ifname 'eth0'
	option vid '204'
	option name 'vlan2'

config interface 'lan'
	option type 'bridge'
	option ifname 'vlan1'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'

That is the same, just the explicit notation. In implicit notation the VLAN ID and parent interface is derived from the ifname option value in dot-notation.

Are you saying that the tagged/untagged VLAN’s like they worked in v3.x are no longer supported in v4.x?

Yep, in TOS3.x swconfig been utilized for managing the port tagging. Just not sure how it can be done in 18.06/19.07 with DAS or whether it is supported. Documentation is scarce and not very helpful in this regard.

Well, I am hoping @Pepe would comment on this soon…

Guys, guys it works. 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.

TLDR you can use this script to migrate network configuration: https://gitlab.labs.nic.cz/turris/turris-os-packages/blob/master/updater/tos3to4/files/switch_and_vlans

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.
I hope that this clarifies it. I suggest you to read up on DSA. There is a lot of material out there. OpenWRT’s and ours documentation lacks behind for time being in this segment but DSA is provided by upstream Linux and not by some OpenWRT patchset.

5 Likes

Hello,

after the update I become this Error:

Error notifications

Updater selhal:

runtime: [string “file:////etc/updater/conf.d/base.lua”]:38: attempt to index global ‘model’ (a nil value)

What can I do?
Bernd

Literally can you hear sighing about the illiterate user getting all panicky and overexerted :sweat_smile:
The problem is rather reading all the technical bits at kernel source development it is not clear how that translates to settings that are parsed by UCI and how those settings are to be deployed. Once looking into that transition script it become more clear.

1 Like

for a DMZ that bypasses the CPU ports one would have to e.g. eth2.1 and then bridge that iface with the lan iface serving the DMZ (e.g. lan4)?

updated from beta 3 to beta 4, or some previous beta?


Maybe it is just a temporary hiccup. Did you try a rollback to the snapshot prior to the update (plus reboot) and then run the update again?

I came from RC 3.11.5 and use the medikit with USB

I test the Rollback and report