> On 23. Jul 2020, at 14:17, Jo-Philipp Wich <[email protected]> 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 _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
