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

Felix Fietkau nbd at nbd.name
Thu Jul 23 12:39:46 EDT 2020


> On 23. Jul 2020, at 14:17, Jo-Philipp Wich <jo at mein.io> wrote:
> 
> Hi,
> 
>> 1. Have VLAN devices on top of vlan-enabled bridges to define hotplug
>> ops where applicable, so LAN could be a plain VLAN interface switch0.1
>> instead of its own bridge.
>> 2. With these wrapper hotplug ops, a default VLAN would be passed as
>> well, unless overwritten by other VLAN settings (see below)
>> 3. In addition to option network, allow specifying option network-vlan
>> in the wifi-iface section and have it contain a list of VLANs +
>> modifiers (tagged/PVID).
> 
> I am a little bit torn. While the simplification of the config is nice, I
> don't like how "option network" acts completely different compared to when the
> target interface does not happen to be a (vlan enabled) bridge. People might
> assume that merely specifying "option network" somehow creates a bridge.
We already use the parameter for bridge and non-bridge cases, so I’d argue that my proposal fits well into the existing pattern.

> What about spelling out the dependency explicitly? Instead of overloading the
> meaning of "option network", add an "option bridge" instead which reuses the
> existing vlan notation followed by a vlan id spec as defined by the "option
> ports" notation for bridge devices, e.g.
> 
>  option bridge switch0  (default vlan 1 untagged)
> 
> or
> 
>  option bridge switch0
>  option vlan 1:u*  # equivalent to just switch0
> 
> or
> 
>  option bridge switch0
>  option vlan 20:t
> 
> 
> The advantage would also be, that is is completely clear that we're not
> inheriting any layer 3 ip settings but that we make the wifi netdev act as
> bridge port. It is also somewhat aligned with native hostapd configuration.
The disadvantage is that the wireless config has to be different if we switch to a default config with no separate LAN bridge, and it becomes potentially more confusing for common use cases.
I think semantically it fits quite well to just assign a Wifi interface to the lan network and hide some implementation details of what that means.

- Felix



More information about the openwrt-devel mailing list