[RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

[Martin Schiller]

On 2021-03-26 10:44, Felix Fietkau wrote:
> On 2021-03-26 09:55, Martin Schiller wrote:
>> On 2021-03-26 09:42, Felix Fietkau wrote:
>>> On 2021-03-26 09:34, Martin Schiller wrote:
>>>> On 2020-07-24 19:13, Felix Fietkau wrote:
>>>>> On 2020-07-24 18:44, Jo-Philipp Wich wrote:
>>>>>> Hi Felix,
>>>>>> 
>>>>>>> [...]
>>>>>>> 
>>>>>>> For a simple default config, you could have this:
>>>>>>> 
>>>>>>> # network
>>>>>>> config device
>>>>>>         option type bridge  # I assume this is needed as well
>>>>>>> 	option name switch0
>>>>> Correct.
>>>>> 
>>>>>>> config bridge-vlan
>>>>>>> 	option vlan 1
>>>>>>> 	option ports "lan1 lan2 lan3 lan4"
>>>>>>> 
>>>>>>> config interface lan
>>>>>>> 	option ifname switch0.1
>>>>>>> 
>>>>>>> 
>>>>>>> # wireless
>>>>>>> 
>>>>>>> config wifi-iface
>>>>>>> 	option network lan
>>>>>>> 
>>>>>>> 
>>>>>>> In this case, wlan0 would be added to switch0 and set to VLAN 1
>>>>>>> untagged
>>>>>>> by default.
>>>>>>> 
>>>>>>> If you want it on VLAN 10 tagged/PVID instead, you could do:
>>>>>>> 	option network-vlan "10:t*"
>>>>>>> 
>>>>>>> 
>>>>>>> What do you think?
>>>>>> 
>>>>>> I did think about it some more, also in context of a LuCI
>>>>>> implementation and
>>>>>> the special role of wifi and I am convinced now that this approach
>>>>>> generally
>>>>>> makes sense.
>>>>>> 
>>>>>> However for the vlan I wonder if we should simply use "option vid
>>>>>> 10"
>>>>>> since
>>>>>> setting anything besides an egress untagged pvid does not make 
>>>>>> sense
>>>>>> for wifi.
>>>>> I think more complex VLAN settings make sense for WDS if you want 
>>>>> to
>>>>> carry multiple networks over the link.
>>>>> 
>>>>>> So your second example above would become:
>>>>>> 
>>>>>>   config wifi-iface
>>>>>>     option network lan
>>>>>>     option vid 10  # instead of inheriting vid 1, use 10 as pvid
>>>>>> 
>>>>>> 
>>>>>> Also, just to clarify... assuming a:
>>>>>> 
>>>>>>   config interface foo
>>>>>>     option ifname somevlanbridge0.456
>>>>>> 
>>>>>> and an wifi iface without an explicit vid override:
>>>>>> 
>>>>>>   config wifi-iface
>>>>>>     option network foo
>>>>>> 
>>>>>> ... we would inherit vid 456 and set as pvid, right? Or are we are
>>>>>> always
>>>>>> going to default to 1?
>>>>> It would inherit 456 to keep it in sync with the VLAN based 
>>>>> network.
>>>>> 
>>>> 
>>>> Is this functionality already integrated?
>>>> I am testing with a xrx200 based system with the DSA mainline driver
>>>> and
>>>> a wifi interface and have the problem that the wlan0 interface is
>>>> added
>>>> to the bridge switch0 but the bridge vlan configuration for the 
>>>> wlan0
>>>> interface is not set.
>>> It's handled differently now.
>>> 
>>> You can set lan's ifname to switch0.1 (without option type bridge) 
>>> and
>>> use 'option network lan' in the wifi-iface. It will detect that the 
>>> lan
>>> ifname is a vlan on top of a vlan-filtering bridge and will add wlan0
>>> to
>>> switch0 and make it a member of lan's vlan.
>>> 
>> 
>> Hmmm... I think that's what I've alread done. Here is my config:
>> 
>> network:
>> ---------
>> config interface 'lan'
>> 	option proto 'static'
>> 	option ipaddr '192.168.X.Y'
>> 	option netmask '255.255.255.0'
>> 	option ifname 'switch0.1'
>> 
>> config device
>> 	option type 'bridge'
>> 	option name 'switch0'
>> 	list ifname 'lan1'
>> 	list ifname 'lan2'
>> 	list ifname 'lan3'
>> 	list ifname 'lan4'
>> 
>> config bridge-vlan
>> 	option device 'switch0'
>> 	option vlan '1'
>> 	list ports 'lan1:u*'
>> 	list ports 'lan2:u*'
>> 	list ports 'lan3:u*'
>> 	list ports 'lan4:u*'
>> 
>> wireless:
>> ----------
>> config wifi-iface 'default_radio0'
>> 	option device 'radio0'
>> 	option mode 'ap'
>> 	option encryption 'psk2'
>> 	option ssid 'TETS-AP'
>> 	option network 'lan'
>> 	option key 'xxxxxxxxxxxxxxxxxxxxxxx'
>> 	option wpa_disable_eapol_key_retries '1'
>> 
>> 
>> Did I forget anything?
> Looks right to me. I'll see if I can find the time to reproduce this.
> You're using a recent version of OpenWrt, right?

Yes, I'm using 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=07c49462ad2ac3f6386bb4463546509f3bf35e39

- Martin