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

[Felix Fietkau]

On 2020-07-24 10:37, Jo-Philipp Wich wrote:
> Hi Luiz,
> 
> I mostly agree with your proposal (though I'd call "device_for" simply
> "bridge" instead but that's details).
> 
> I don't think everything can be simply switched in one go but I do think your
> proposal could be broken down into the following measures.
> 
> The simple things:
> 
>  - Rename "config wifi-device" to "config radio", keep supporting the old
>    name for backwards compatibility
Not sure how much that would help

>  - For network.device sections, make "option name" optional and default it
>    to the section name, ignore section if it is anonymous and no option name
>    is set
ACK

> The harder things:
> 
>  - Untangle the meaning of "option ifname" - for some protocols it specifies
>    the existing device to use, for some protocols, e.g. tunnel ones, it
>    specifies the name of the device to create. Ideally we should switch to
>    "option device"  instead and introduce an "option name" for those cases
>    where the resulting device name is controllable. This would also clear up
>    some quirks with protocol types that both use a physical link and create a
>    tunnel interface on top like PPPoE. One could then use "option device eth0"
>    and "option name pppoe-wan" to specify both the L2 device to use and the
>    name of the L3 device to create.
ACK

>  - Support "@" style notation for "option device" to resolve netdev names once
>    the above untangling is done>
>  - Handling name clashes and device name limitations. Given tunnel devices
>    with arbitrary names and - since the introduction of DSA - existing netdevs
>    with generic names like "wan", "lan1" etc. clashes between configured
>    bridge or tunnel devices and existing netdevs become likely. What should
>    happen if a bridge with name "wan" is declared and a "wan" DSA port device
>    already exists on the system? What should happen if a chosen name exceeds
>    the 15 byte ifname limit?
> 
>  - Transform "config wifi-iface" in the wireless config into "config device"
>    in the network config and handle it like yet another device type which
>    happens to understand the various logical wifi network properties like
>    SSID, encryption etc. Problem here: a logical wifi network does not really
>    represent a 1:1 relationship to a netdev in all cases, an AP/VLAN interface
>    for example will create a new vlan-subdevice for each associated station,
>    so one wifi network can result in N+1 wifi netdevs. The only sensible
>    use case for such uci "devices" would be associating them with a bridge
>    or to leave them alone in case something outside of netifd's realm is
>    somehow dealing with the existing vlan netdevs. What likely would not work
>    is associating them with a "config interface" that specifies "proto static"
>    since multiple netdev would get the same subnets assigned then
I think this one is very likely to cause a lot more problems than it
would solve:
You already mentioned the lack of a 1:1 relationship between wifi
interfaces and netdevs. That alone would probably introduce a lot of
implementation complexity (and possibly subtle bugs).
Another issue is that some drivers have limitations on the order in
which devices are brought up, and 802.11ax introduces implicit
dependencies between interfaces (transmitted vs non-transmitted BSS).
All of this does not map well to how netifd treats devices at the moment.

I'd strongly prefer keeping the current wireless config structure
(separate from network interfaces/devices).

- Felix