[RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules
jo at mein.io
Fri Jul 24 04:37:23 EDT 2020
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
- 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
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.
- 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
Things to consider:
- In addition to shell based protocol handlers, implement a similar machinery
for shell based device type handlers to allow to quickly bootstrap uci
support for new device types (think things like veth, vxlan etc. - I know
that they have been implemented in C already for netifd, but just serving
as an example)
- When actually moving "config wifi-iface" as "config device" to the network
config, it might make sense to move "config wifi-device" as "config radio"
to the network config as well, entirely eliminating /etc/config/wireless
- If we find some way to deal with name clashes (what about MS DOS style
wan~1 :P), consider eliminating the concept of protocol prefixes like
"pppoe-", "3g-" etc.
I probably missed many details, but I think we really should consider tidying
up the network configuration.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the openwrt-devel