This is my first setup, so I may ask stupid questions.
I have the GS1900 and I want to use it with one trunk (all vlans tagged) port and one access port (one VLAN untagged).
I'm a bit surprised that this is the default configuration... normally the main bridge will contain all ports in a list format, and then the bridge-vlans use a list format rather than an option with all the ports.
For example:
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config bridge-vlan
option device 'br-lan'
option vlan '1'
list ports 'lan1:t'
list ports 'lan2:u*'
config bridge-vlan
option device 'br-lan'
option vlan '2'
list ports 'lan1:t'
list ports 'lan3:u*'
config bridge-vlan
option device 'br-lan'
option vlan '3'
list ports 'lan1:t'
list ports 'lan4:u*'
What version of OpenWrt is currently on your device?
Because the syntax here is so different than most other OpenWrt DSA devices (i.e. routers), and I don't have specific experience with this device, I'm going to defer to others to help you here. That's simply because I don't want to give you incorrect information that could cause you headaches.
In general, you should be able to find a lot of your answers in the DSA tutorial, but as mentioned, for some reason your switch doesn't seem to follow the same syntax rules... therefore, be careful as you experiment and/or wait until someone with specific knowledge of your switch can assist.
I have exactly the same device running the same version. Below is a copy of my network file (less loopback/globals section) so you can compare.
I have three vlans but all trunked back via lan port 8. The bridged vlan filtering section is configured as follows:
ports 1 and 2 untagged on vlan 20
ports 3 and 4 untagged on vlan 30
ports 5,6 and 7 are not members of any vlan
Vlan 10 exists but is for testing mainly and normally has no ports assigned
port 8 is tagged for all 3 vlans and is the vlan trunk link back to my main switch
Hope this helps
config device 'switch'
option name 'switch'
option type 'bridge'
option macaddr '5c:f4:ab:ca:9b:12'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
list ports 'lan5'
list ports 'lan6'
list ports 'lan7'
list ports 'lan8'
option ipv6 '0'
config bridge-vlan
option device 'switch'
option vlan '20'
list ports 'lan1'
list ports 'lan2'
list ports 'lan8:t'
config bridge-vlan
option device 'switch'
option vlan '30'
list ports 'lan3'
list ports 'lan4'
list ports 'lan8:t'
config bridge-vlan
option device 'switch'
option vlan '10'
list ports 'lan8:t'
config interface 'HIFI'
option proto 'none'
option device 'switch.20'
option delegate '0'
config interface 'IOT'
option proto 'none'
option device 'switch.30'
option delegate '0'
config interface 'HOME'
option proto 'static'
option device 'switch.10'
option ipaddr '192.168.1.150'
option netmask '255.255.255.0'
option gateway '192.168.1.1'
option delegate '0'
config device
option name 'switch.10'
option type '8021q'
option ifname 'switch'
option vid '10'
option ipv6 '0'
config device
option name 'switch.20'
option type '8021q'
option ifname 'switch'
option vid '20'
option ipv6 '0'
config device
option name 'switch.30'
option type '8021q'
option ifname 'switch'
option vid '30'
option ipv6 '0'
Just set the protocol to "unmanaged" for the non-management VLANs. So whichever VLAN you want to use to manage the device set the protocol to "static address" and configure an appropriate address.
I've now the following config and noticed that untagged traffic arriving at a trunk will be sent untagged to all other ports.
Is there a way to discard them on a trunk port?
On my trunk ports I don't set any untagged and as far as I can tell I only have tagged frames on the wire. Also, I explicit do not configure vlan 1 at all in my environment.
That's a legit way to do it. But the OP is saying that there is untagged traffic flowing, so the guaranteed way to block that from being an issue is black-holing the traffic with an untagged+PVID VLAN that goes nowhere.
That said, I do agree that this is something of a hack because the untagged traffic must be flowing due to some other misconfiguration.The good news is that the black-holing of the traffic will likely break something else, revealing the path to proper resolution.