| Message ID | 20200707201035.751527-1-jo@mein.io |
|---|---|
| Headers | show |
| Series | Introduce UCI support for configuring DSA VLAN filter rules | expand |
Hi, I have a somewhat radical comment on this. As far as I understand, the vlan filtering support in the linux bridge subsystem is not specific to dsa, but can equally be configured for a pure software bridge. The fact that the switch supports dsa/switchdev then simply allows this to be transparently handled in hardware, just like the simple bridging of the switch port interfaces. Isn't it conceptually more correct in this case for the vlan filtering to be configured as part of the "interface" in uci? Ie I configure an interface of type "bridge" which bridges the switch ports, then the vlan filtering is a configuration property of this interface (just like enabling igmp_snooping on a bridge interface) Thanks, Josh On Tue, 7 Jul 2020 at 22:13, Jo-Philipp Wich <jo@mein.io> wrote: > > This patch series introduces a new package "dsaconfig" which provides the > necessary logic to allow configuration of bridge vlan filter rules for > DSA switches. > > While well supported DSA switches can be programmed by solely bridging > per-port netdevices together, explicit bridge VLAN filter rules are needed > for more complex scenarios or for DSA switches that do not support a > tagging protocol. > > The UCI configuration interpreted by the dsaconfig package closely follows > the structure and semantics of the legacy swconfig architecture, honouring > "dsa", "dsa_vlan" and "dsa_port" sections within the > /etc/config/network file. The only difference compared to swconfig is > that "dsa" sections are optional and that the syntax of ports within > the "dsa_vlan" section differs, instead of <portnumber><tag>?, e.g. > "0t", "1u" or "2", it is now <portname>(.<tag>)?, e.g. "wan.u", "lan1.t" > or "lan2". > > The dsaconfig package will spawn a bridge device named "switchN" for each > DSA switch, where N denotes the number of the switch. In contrast to > swconfig, interfaces do not use the CPU port to target VLAN port groups on > the switch but reference a VLAN on top of the switch, e.g. > "option ifname switch0.1" to use the VLAN 1 port group on the first DSA > switch. > > A complete configuration example for a simple LAN/WAN setup might look > like below. Note that this configuration should be equivalent to just > bridging lan1..lan4 without any VLAN filter rules. > > -- 8< -- > config dsa_vlan > option vlan 1 > option ports 'lan1 lan2 lan3 lan4' > > config dsa_vlan > option vlan 2 > option ports 'wan' > > config interface lan > option ifname switch0.1 > option proto static > option ipaddr 192.168.1.1/24 > > config interface wan > option ifname switch0.2 > option proto dhcp > -- >8 -- > > A slightly more complex example that uses multiple tagged VLANs on different > ports would look like this: > > -- 8< -- > config dsa switch0 > ## Override CPU port. Normally it is auto-discovered. > #option cpu_port eth0 > > config dsa_vlan > ## Specify the switch this vlan belongs to. > ## If there is only one switch on the system, it may be omitted. > #option device switch0 > option vlan 1 > option ports 'lan1 lan2.t' > > config dsa_vlan > #option device switch0 > option vlan 2 > option ports 'wan' > > config dsa_vlan > #option device switch0 > option vlan 5 > option ports 'lan2.t lan3' > > config dsa_vlan > #option device switch0 > option vlan 8 > option ports 'lan2.t lan4' > > config dsa_vlan > #option device switch0 > option vlan 11 > option ports 'lan2.t lan4.t' > > config dsa_port > #option device switch0 > option port lan2 > ## By default, the port PVID is set to the ID of the first > ## untagged VLAN the port is member of. It can be overriden here. > option pvid 5 > > config interface lan > option type bridge > option ifname 'switch0.1 wlan0' > option proto static > option ipaddr 192.168.1.1/24 > > config interface wan > option ifname switch0.2 > option proto dhcp > > config interface vlan5 > option ifname switch0.5 > option proto static > option ipaddr 10.255.5.1/24 > > config interface vlan8 > option ifname switch0.8 > option proto static > option ipaddr 10.255.8.1/24 > > config interface vlan11 > option ifname switch0.11 > option proto static > option ipaddr 10.255.11.1/24 > -- >8 -- > > Additionally, the "dsaconfig" executable provided by this package implements > a "show" option to display the current switch port states and their VLAN > memberships in a compact manner. For the latter configuration example above, > the utility would produce an output similar to the following: > > -- 8< -- > root@OpenWrt:~# dsaconfig show > Switch: switch0 > VLAN/ | lan1 | lan2 | lan3 | lan4 | wan | > Link: | down | 1000F | down | 1000F | down | > 1 | u* | t | | | | > 2 | | | | | u* | > 5 | | t* | u* | | | > 8 | t | t | | u* | | > 11 | | t | | t | | > > -- >8 -- > > This code has been tested on a WRT3200ACM and a Mir3G but is supposed to > work with any DSA switch. It requires wider testing before it is suitable > for inclusion. > > Once the configuration format is and rule logic is finalized, the shell > script code provided by this package should be implemented directly in > netifd C code to reduce the amount of required external dependencies and > to allow for improved performance when processing large configurations. > > Open questions/topics: > > - Ensure that the chosen configuration approach actually works with > DSA_TAG_PROTO_NONE switches > > - Investigate potential MTU issues regarding the CPU port > > Changes since v1: > > - Rename switch, switch_vlan and switch_port sections to dsa, dsa_vlan > and dsa_port respectively > > - Forcibly move DSA ports to the switch bridge if they're part of another > bridge yet > > - Disallow VLAN ID 0 > > - Properly display unassigned ports as empty in "dsaconfig show" > > - Handle implicit switch0 in "dsaconfig show" > > Jo-Philipp Wich (1): > dsaconfig: introduce package for UCI configuration of VLAN filter > rules > > package/network/config/dsaconfig/Makefile | 40 +++ > .../config/dsaconfig/files/dsaconfig.hotplug | 7 + > .../config/dsaconfig/files/dsaconfig.include | 11 + > .../config/dsaconfig/files/dsaconfig.sh | 306 ++++++++++++++++++ > 4 files changed, 364 insertions(+) > create mode 100644 package/network/config/dsaconfig/Makefile > create mode 100644 package/network/config/dsaconfig/files/dsaconfig.hotplug > create mode 100755 package/network/config/dsaconfig/files/dsaconfig.include > create mode 100755 package/network/config/dsaconfig/files/dsaconfig.sh > > -- > 2.27.0 > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Hi, > [...] > Isn't it conceptually more correct in this case for the vlan filtering > to be configured as part of the "interface" in uci? > Ie I configure an interface of type "bridge" which bridges the switch > ports, then the vlan filtering is a configuration property of this > interface (just like enabling igmp_snooping on a bridge interface) the "config interface" section type already is quite overloaded with different layer2 and layer3 configuration semantics which leads to confusion and quirks, as can be seen e.g. with "option mtu" on top of PPPoE interfaces or "option mac" on bridges. I agree that this setting could conceptually make sense in a "config device" section of type bridge, but with the VLAN filter settings being multi-dimensional it does not fit very well into simple uci option values without defining yet another micro format to declare VLAN / port memberships. The proposed dsaconfig approach has been selected due to its similarity with swconfig, it is easier to understand for people already used to swconfig and even allows for some automatic configuration conversion to some extent. I also do see it as a complementary higher level kind of configuration. It is entirely opt-in and can be supplemented or superseded with per-interface and per-device attributes that are implemented in netifd eventually. Regards, Jo
Hello,
I had the same feeling since I saw this patch. I would really like
something that could transparently allow me to bridge
either DSA ports, standard ethernet ports or even have a syntax that
would be compatible with swconfig (where dsa is not available).
It is a good opportunity to rebuild current network configuration from
scratch. Today, OpenWrt config does not make clear
how this two are connected:
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config interface 'lan'
option type 'bridge'
option ifname 'eth0.1'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
And we still have wireless:
config wifi-iface 'wifinet0'
option device 'radio0'
option mode 'ap'
option network 'lan' #shouldn't it be "interface"?
It's confusing for someone just arriving that switch0 will use eth0
and switch0 vlan 1 will be mapped to eth0.1. And, after bringing up
the interface, we have a br-lan, not mentioned anywhere.
Both L2 and L3 configurations are mixed, with part of it being even in
a separated configuration file (wireless).
The same feeling is still with this DSA proposal. The syntax "lan2.t
lan2 lan3 lan5" is unstructured and it does not help too.
The use of "switch0" for cpu interface is good and I think it should
even be used for swconfig (simply rename eth0 to switch0 by default
and it will improve usability).
Trying to reuse the current swconfig syntax might be a curse that will
haunt us. We could have simply 2 sections: bridge (L2) and interface
(L3). My proposal:
config bridge br-lan <- the real bridge device name
option type "auto" # use the best way to merge every ports
# swconfig
list port switch0@1.1 # switch0, port 1, vlan 1, untagged
list port switch0@2.1 # switch0, port 2, vlan 1, untagged
list port switch0@3.1t # switch0, port 3, vlan 1, tagged
list port switch0@4.2t # switch0, port 4, vlan 2, tagged
list port switch0@4 # switch0, port 4, no vlan filtering (trunk mode)
# DSA
list port lan1 # lan1, no vlan filtering (trunk mode)
list port lan2.1 # lan2 port, vlan 1, untagged
list port lan3.1t # lan3 port, vlan 1, tagged
list port lan3.2t # lan3 port, vlan 2, tagged
# Other interfaces
list port eth0 # eth0 port, no vlan filtering (trunk mode)
list port eth0.2t # eth0 port, vlan 2, tagged
list port wlan0 # it could also be specified in wifi-iface
# for swconfig, where wan would be what eth0.2 is today (simply renamed).
# it might keep the current misunderstanding that eth0.2 is not wan
port but a two-port bridge
# between CPU and wan ports
bridge wan
list port switch0@0 # swith0, port 0, no vlan filtering
# for DSA or swconfig
interface wan
ifname wan
proto dhcp
interface lan
ifname lanbridge0 #<- the real bridge device name
proto static
...
config wifi-iface 'wifinet'
option bridge lanbridge0
...
I don't have a working DSA system to test on but according to
https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html,
it looks like DSA could allow two different ports to use the same vlan
but belong to different bridges. swconfig does not allow that setup
when you use two bridges. But, it could join them using software
bridges. There are obviously incompatible arrangements but the system
could detect them if the configured setup is not possible and avoid to
load them (or load whatever is possible). The bridge device might be
a DSA switch, a software bridge, or simply the CPU port (maybe even
using openvswitch when available?).
My proposal might have tons of uncovered cases (PPPoE, vlan, tunnel)
but it looks easier than current swconfig and dsa proposed
configuration.
The main points are to split L2 and L3 confs, split port list into
individual options and let the system decide the best way to implement
the proposed setup.
Regards,
---
Luiz Angelo Daros de Luca
luizluca@gmail.com
Hi, > [...] > The same feeling is still with this DSA proposal. The syntax "lan2.t > lan2 lan3 lan5" is unstructured and it does not help too. What is unstructured about it? The fact that it is not a uci list? That can be easily changed. > The use of "switch0" for cpu interface is good and I think it should > even be used for swconfig (simply rename eth0 to switch0 by default > and it will improve usability). I agree but I don't think it'll ever materialize for swconfig. > Trying to reuse the current swconfig syntax might be a curse that will > haunt us. We could have simply 2 sections: bridge (L2) and interface > (L3). My proposal: > > config bridge br-lan <- the real bridge device name This is invalid uci syntax, dashes are not allowed. It also duplicates "config device" with "option type bridge". > option type "auto" # use the best way to merge every ports What possible ways would there be? > # swconfig > [...] Skipped because I don't think there will be new syntax for swconfig anymore. > # DSA > list port lan1 # lan1, no vlan filtering (trunk mode) > list port lan2.1 # lan2 port, vlan 1, untagged > list port lan3.1t # lan3 port, vlan 1, tagged > list port lan3.2t # lan3 port, vlan 2, tagged All of that except vlan/untagged are already possible using: config interface foo option type bridge list ifname lan1 list ifname lan2.1 list ifname lan3.1 list ifname lan3.2 option proto ... or alternatively using: config device option type bridge option name blah0 list ifname lan1 list ifname lan2.1 list ifname lan3.1 list ifname lan3.2 > [...] > > My proposal might have tons of uncovered cases (PPPoE, vlan, tunnel) > but it looks easier than current swconfig and dsa proposed > configuration. It might be a matter of taste but personally I don't see what is easier about it. The main change seems to be that instead by VLAN ID, your proposal groups the port memberships by bridge. So instead having a vlan section that attaches ports to a bridge, you declare a bridge containing ports with their respective VLAN IDs. > The main points are to split L2 and L3 confs, split port list into > individual options and let the system decide the best way to implement > the proposed setup. Point 1 is already doable, point 2 can be easily added (in fact changing "option ports 'lan1 lan2 lan3'" to "list ports lan1; list ports lan2; list ports lan3" is possible without changing any code). I disagree with point 3. Having a network config that automagically translates into different things on different boards makes debugging potential issues very hard. The uci network config is too low level for that imho. Regards, Jo
Ok thanks. I think my main point was not that this belongs in interface per-se, but that it makes sense for the configuration of vlan tagging to apply to bridges in general (and to have as little as possible special handling of dsa in uci, since the logic is that it should be possible to configure it exactly as a generic bridge) On Tue, 14 Jul 2020 at 19:05, Jo-Philipp Wich <jo@mein.io> wrote: > > Hi, > > > [...] > > Isn't it conceptually more correct in this case for the vlan filtering > > to be configured as part of the "interface" in uci? > > Ie I configure an interface of type "bridge" which bridges the switch > > ports, then the vlan filtering is a configuration property of this > > interface (just like enabling igmp_snooping on a bridge interface) > > the "config interface" section type already is quite overloaded with different > layer2 and layer3 configuration semantics which leads to confusion and quirks, > as can be seen e.g. with "option mtu" on top of PPPoE interfaces or "option > mac" on bridges. > > I agree that this setting could conceptually make sense in a "config device" > section of type bridge, but with the VLAN filter settings being > multi-dimensional it does not fit very well into simple uci option values > without defining yet another micro format to declare VLAN / port memberships. > > The proposed dsaconfig approach has been selected due to its similarity with > swconfig, it is easier to understand for people already used to swconfig and > even allows for some automatic configuration conversion to some extent. > > I also do see it as a complementary higher level kind of configuration. It is > entirely opt-in and can be supplemented or superseded with per-interface and > per-device attributes that are implemented in netifd eventually. > > > Regards, > Jo >
Hi, In the setup that I have (dsa), in addition to creating interfaces which are managed, I also have vlans which are not managed at all, thus having pure switching for these specific vlans. With dsaconfig, all vlans get tagged on the switch to "self". I understand this as tagging the cpu port. It is exactly this step which I skip to have unmanageable switched vlans. The devices do not show up with "ip l" but the vlans can be seen with "bridge v". I would propose adding an option something like this: config dsa_vlan option vlan 500 option ports 'lan3.t lan4.t' option cpuport '0' # default value is 1 The CPU Port with the swconfig setup is always some number which changes from router to router followed by a 't'. This way, tagging the cpu port is the default but can be overridden. Greets, Perry On 7/14/20 5:34 PM, Josh Bendavid wrote: > Hi, > I have a somewhat radical comment on this. > > As far as I understand, the vlan filtering support in the linux bridge > subsystem is not specific to dsa, but can equally be configured for a > pure software bridge. The fact that the switch supports dsa/switchdev > then simply allows this to be transparently handled in hardware, just > like the simple bridging of the switch port interfaces. > > Isn't it conceptually more correct in this case for the vlan filtering > to be configured as part of the "interface" in uci? > Ie I configure an interface of type "bridge" which bridges the switch > ports, then the vlan filtering is a configuration property of this > interface (just like enabling igmp_snooping on a bridge interface) > > Thanks, > Josh > > On Tue, 7 Jul 2020 at 22:13, Jo-Philipp Wich <jo@mein.io> wrote: >> >> This patch series introduces a new package "dsaconfig" which provides the >> necessary logic to allow configuration of bridge vlan filter rules for >> DSA switches. >> >> While well supported DSA switches can be programmed by solely bridging >> per-port netdevices together, explicit bridge VLAN filter rules are needed >> for more complex scenarios or for DSA switches that do not support a >> tagging protocol. >> >> The UCI configuration interpreted by the dsaconfig package closely follows >> the structure and semantics of the legacy swconfig architecture, honouring >> "dsa", "dsa_vlan" and "dsa_port" sections within the >> /etc/config/network file. The only difference compared to swconfig is >> that "dsa" sections are optional and that the syntax of ports within >> the "dsa_vlan" section differs, instead of <portnumber><tag>?, e.g. >> "0t", "1u" or "2", it is now <portname>(.<tag>)?, e.g. "wan.u", "lan1.t" >> or "lan2". >> >> The dsaconfig package will spawn a bridge device named "switchN" for each >> DSA switch, where N denotes the number of the switch. In contrast to >> swconfig, interfaces do not use the CPU port to target VLAN port groups on >> the switch but reference a VLAN on top of the switch, e.g. >> "option ifname switch0.1" to use the VLAN 1 port group on the first DSA >> switch. >> >> A complete configuration example for a simple LAN/WAN setup might look >> like below. Note that this configuration should be equivalent to just >> bridging lan1..lan4 without any VLAN filter rules. >> >> -- 8< -- >> config dsa_vlan >> option vlan 1 >> option ports 'lan1 lan2 lan3 lan4' >> >> config dsa_vlan >> option vlan 2 >> option ports 'wan' >> >> config interface lan >> option ifname switch0.1 >> option proto static >> option ipaddr 192.168.1.1/24 >> >> config interface wan >> option ifname switch0.2 >> option proto dhcp >> -- >8 -- >> >> A slightly more complex example that uses multiple tagged VLANs on different >> ports would look like this: >> >> -- 8< -- >> config dsa switch0 >> ## Override CPU port. Normally it is auto-discovered. >> #option cpu_port eth0 >> >> config dsa_vlan >> ## Specify the switch this vlan belongs to. >> ## If there is only one switch on the system, it may be omitted. >> #option device switch0 >> option vlan 1 >> option ports 'lan1 lan2.t' >> >> config dsa_vlan >> #option device switch0 >> option vlan 2 >> option ports 'wan' >> >> config dsa_vlan >> #option device switch0 >> option vlan 5 >> option ports 'lan2.t lan3' >> >> config dsa_vlan >> #option device switch0 >> option vlan 8 >> option ports 'lan2.t lan4' >> >> config dsa_vlan >> #option device switch0 >> option vlan 11 >> option ports 'lan2.t lan4.t' >> >> config dsa_port >> #option device switch0 >> option port lan2 >> ## By default, the port PVID is set to the ID of the first >> ## untagged VLAN the port is member of. It can be overriden here. >> option pvid 5 >> >> config interface lan >> option type bridge >> option ifname 'switch0.1 wlan0' >> option proto static >> option ipaddr 192.168.1.1/24 >> >> config interface wan >> option ifname switch0.2 >> option proto dhcp >> >> config interface vlan5 >> option ifname switch0.5 >> option proto static >> option ipaddr 10.255.5.1/24 >> >> config interface vlan8 >> option ifname switch0.8 >> option proto static >> option ipaddr 10.255.8.1/24 >> >> config interface vlan11 >> option ifname switch0.11 >> option proto static >> option ipaddr 10.255.11.1/24 >> -- >8 -- >> >> Additionally, the "dsaconfig" executable provided by this package implements >> a "show" option to display the current switch port states and their VLAN >> memberships in a compact manner. For the latter configuration example above, >> the utility would produce an output similar to the following: >> >> -- 8< -- >> root@OpenWrt:~# dsaconfig show >> Switch: switch0 >> VLAN/ | lan1 | lan2 | lan3 | lan4 | wan | >> Link: | down | 1000F | down | 1000F | down | >> 1 | u* | t | | | | >> 2 | | | | | u* | >> 5 | | t* | u* | | | >> 8 | t | t | | u* | | >> 11 | | t | | t | | >> >> -- >8 -- >> >> This code has been tested on a WRT3200ACM and a Mir3G but is supposed to >> work with any DSA switch. It requires wider testing before it is suitable >> for inclusion. >> >> Once the configuration format is and rule logic is finalized, the shell >> script code provided by this package should be implemented directly in >> netifd C code to reduce the amount of required external dependencies and >> to allow for improved performance when processing large configurations. >> >> Open questions/topics: >> >> - Ensure that the chosen configuration approach actually works with >> DSA_TAG_PROTO_NONE switches >> >> - Investigate potential MTU issues regarding the CPU port >> >> Changes since v1: >> >> - Rename switch, switch_vlan and switch_port sections to dsa, dsa_vlan >> and dsa_port respectively >> >> - Forcibly move DSA ports to the switch bridge if they're part of another >> bridge yet >> >> - Disallow VLAN ID 0 >> >> - Properly display unassigned ports as empty in "dsaconfig show" >> >> - Handle implicit switch0 in "dsaconfig show" >> >> Jo-Philipp Wich (1): >> dsaconfig: introduce package for UCI configuration of VLAN filter >> rules >> >> package/network/config/dsaconfig/Makefile | 40 +++ >> .../config/dsaconfig/files/dsaconfig.hotplug | 7 + >> .../config/dsaconfig/files/dsaconfig.include | 11 + >> .../config/dsaconfig/files/dsaconfig.sh | 306 ++++++++++++++++++ >> 4 files changed, 364 insertions(+) >> create mode 100644 package/network/config/dsaconfig/Makefile >> create mode 100644 package/network/config/dsaconfig/files/dsaconfig.hotplug >> create mode 100755 package/network/config/dsaconfig/files/dsaconfig.include >> create mode 100755 package/network/config/dsaconfig/files/dsaconfig.sh >> >> -- >> 2.27.0 >> >> >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > . >
> > config bridge br-lan <- the real bridge device name > > This is invalid uci syntax, dashes are not allowed. It also duplicates "config > device" with "option type bridge". Yes, "config device" is better. If used, a wireless definition would now reference a device and not an interface. > > option type "auto" # use the best way to merge every ports > > What possible ways would there be? The bridge type to use. It could be a software bridge, DSA, <del>swconfig</del>, openvswitch. But with a device section, "option type 'openvswitch'" might already cover it. > It might be a matter of taste but personally I don't see what is easier about > it. The main change seems to be that instead by VLAN ID, your proposal groups > the port memberships by bridge. So instead having a vlan section that attaches > ports to a bridge, you declare a bridge containing ports with their respective > VLAN IDs. A bridge is a broader concept than a vlan inside a switch. It might include ports that use different vlans (although not very common) or devices outside the switch. Linux configures DSA using the bridge concept and not vlans. I think using vlan would simply make it harder to map or limit what you can do with it. I'm still ignorant about DSA and all I know is only from docs. Would it be possible to simply connect any ethernet device to a DSA bridge? Something like: ip link add name br0 type bridge ip link set dev lan1 master br0 ip link set dev lan2 master br0 ip link set dev lan3 master br0 ip link set dev usb0 master br0 > > The main points are to split L2 and L3 confs, split port list into > > individual options and let the system decide the best way to implement > > the proposed setup. > > Point 1 is already doable, point 2 can be easily added (in fact changing > "option ports 'lan1 lan2 lan3'" to "list ports lan1; list ports lan2; list > ports lan3" is possible without changing any code). > > I disagree with point 3. Having a network config that automagically translates > into different things on different boards makes debugging potential issues > very hard. The uci network config is too low level for that imho. You are right. It would not be nice to have too much implicit configuration. A more complex setup might use a device that references other devices. Regard, --- Luiz Angelo Daros de Luca luizluca@gmail.com
Perry <isprotejesvalkata@gmail.com> writes: > With dsaconfig, all vlans get tagged on the switch to "self". I > understand this as tagging the cpu port. > > It is exactly this step which I skip to have unmanageable switched > vlans. The devices do not show up with "ip l" but the vlans can be seen > with "bridge v". Yes, I'd also like to avoid unnecessarily switching every packet to the CPU port (assuming it will be in prmisc mode from time to time). It would be nice if we could add only the necessary VLANs there. I.e. VLAN interfaces with IP config, or being members of another bridge, or backing PPPoE, or whatever But I don't know how to implement that automagically. I wouldn't want to be forced to explicitly configure this either. Bjørn
Hi, I would like to propose an alternative configuration format that is structurally close to your proposal, but more generic in that it is not tied to DSA directly but configures bridge vlans instead. Here's the converted form of your example: config device switch0 option name switch0 option type bridge config bridge-vlan vlan1 option device switch0 option vlan 1 option ports 'lan1 lan2=t' config bridge-vlan vlan2 option device switch0 option vlan 2 option ports wan config bridge-vlan vlan5 option device switch0 option vlan 5 option ports 'lan2=pt lan3' config bridge-vlan vlan8 option device switch0 option vlan 8 option ports 'lan2=t lan4' config bridge-vlan vlan11 option device switch0 option vlan 11 option ports 'lan2=t lan4=t' Changes: - The device is created as a netifd bridge - Bridge vlan sections should always refer to the bridge instead of automatically be applied to the first one - Use = instead of . to mark tagging modifiers. "." is already used for vlan interface names and reusing it here creates ambiguity. - Allow specifing pvid as a modifier instead of needing to create a separate port section. The section names are optional, I chose to put them in to make it easier to modify the sections from scripts What do you think? - Felix
Hi, > Changes: > - The device is created as a netifd bridge > - Bridge vlan sections should always refer to the bridge instead of > automatically be applied to the first one > - Use = instead of . to mark tagging modifiers. "." is already used > for vlan interface names and reusing it here creates ambiguity. > - Allow specifing pvid as a modifier instead of needing to create a > separate port section. > > The section names are optional, I chose to put them in to make it easier > to modify the sections from scripts > > What do you think? First of all, I was reworking dsaconfig into a very similar direction for a v3 so overall I do like your proposal and I think it makes sense. Specific points from my side: - I dislike the equal sign syntax, colon would fit better imho - For denoting pvid I used a trailing asterisk, like the old roboswitch config - The bridge-vlan sections should be anonymous - Bridge vlan filtering will be implicitely enabled as soon as at least one bridge-vlan section references a bridge device? So my preferred configuration would look like (choosing list over option notation for ports but that should have no code impact): config device option name switch0 option type bridge config bridge-vlan option device switch0 option vlan 1 list ports 'lan1' list ports 'lan2:t' config bridge-vlan option device switch0 option vlan 2 list ports 'wan:u' # I think we also should support an explicit # untag which is equivalent to no suffix config bridge-vlan option device switch0 option vlan 5 list ports 'lan2:t*' # The "*" denotes a PVID list ports 'lan3' config bridge-vlan option device switch0 option vlan 8 list ports 'lan2:t' list ports 'lan4' config bridge-vlan option device switch0 option vlan 11 list ports 'lan2:t' list ports 'lan4:t' ~ Jo
On 2020-07-15 09:56, Jo-Philipp Wich wrote: > Hi, > >> Changes: >> - The device is created as a netifd bridge >> - Bridge vlan sections should always refer to the bridge instead of >> automatically be applied to the first one >> - Use = instead of . to mark tagging modifiers. "." is already used >> for vlan interface names and reusing it here creates ambiguity. >> - Allow specifing pvid as a modifier instead of needing to create a >> separate port section. >> >> The section names are optional, I chose to put them in to make it easier >> to modify the sections from scripts >> >> What do you think? > > First of all, I was reworking dsaconfig into a very similar direction for a v3 > so overall I do like your proposal and I think it makes sense. > > Specific points from my side: > > - I dislike the equal sign syntax, colon would fit better imho I didn't pick it, because it is already used for linux alias netdevices. Since we don't use those, I guess it might not be a problem in practice. > - For denoting pvid I used a trailing asterisk, like the old roboswitch config Fine with me as well. > - The bridge-vlan sections should be anonymous Sure. As I pointed out, the section name should be optional. > - Bridge vlan filtering will be implicitely enabled as soon as at least one > bridge-vlan section references a bridge device? Yes. I just discussed with John that I'm going to start working on a netifd prototype implementation this week, and I'll include your proposed modifications. - Felix
Jo-Philipp Wich <jo@mein.io> writes: > config device > option name switch0 > option type bridge > > config bridge-vlan > option device switch0 > option vlan 1 > list ports 'lan1' > list ports 'lan2:t' If we can't come up with a working automatic scheme, maybe we could have an option to disable the cpu port per vlan? Something like config bridge-vlan option device switch0 option vlan 2 option self 0 # defaults to true list ports 'lan2:t' Bjørn
Hi, > If we can't come up with a working automatic scheme, maybe we could have > an option to disable the cpu port per vlan? Having a default-enabled "option self" or "option local" was my idea as well. Any idea which name fits better? ~ Jo
On 15.07.20 13:39, Jo-Philipp Wich wrote: > Hi, > >> If we can't come up with a working automatic scheme, maybe we could have >> an option to disable the cpu port per vlan? > Having a default-enabled "option self" or "option local" was my idea as > well. Any idea which name fits better? > > ~ Jo > self is what ip-bridge uses as a parameter name for this feature John
> - For denoting pvid I used a trailing asterisk, like the old roboswitch config
I'm not sure whether using an asterisk is wise here, as it might pose interesting problems when people use scripts to set/evaluate uci config (as you have to be extra careful to not have it treated as a wildcard.)
I'd be happy if we could find another symbol here.
Best
Adrian
Hi, > I'm not sure whether using an asterisk is wise here, as it might pose > interesting problems when people use scripts to set/evaluate uci > config (as you have to be extra careful to not have it treated as a > wildcard.) I'd be happy if we could find another symbol here. hm, can you elaborate on the problem here? Scripts which use uci values verbatim without quoting are prone to any kind of shell injection flaws, not sure if papering over such deficiencies is the way to go here. ~ Jo
I guess the vlan_default_pvid setting would fit into the config device block in this scheme? On Wed, 15 Jul 2020 at 09:59, Jo-Philipp Wich <jo@mein.io> wrote: > > Hi, > > > Changes: > > - The device is created as a netifd bridge > > - Bridge vlan sections should always refer to the bridge instead of > > automatically be applied to the first one > > - Use = instead of . to mark tagging modifiers. "." is already used > > for vlan interface names and reusing it here creates ambiguity. > > - Allow specifing pvid as a modifier instead of needing to create a > > separate port section. > > > > The section names are optional, I chose to put them in to make it easier > > to modify the sections from scripts > > > > What do you think? > > First of all, I was reworking dsaconfig into a very similar direction for a v3 > so overall I do like your proposal and I think it makes sense. > > Specific points from my side: > > - I dislike the equal sign syntax, colon would fit better imho > - For denoting pvid I used a trailing asterisk, like the old roboswitch config > - The bridge-vlan sections should be anonymous > - Bridge vlan filtering will be implicitely enabled as soon as at least one > bridge-vlan section references a bridge device? > > > So my preferred configuration would look like (choosing list over option > notation for ports but that should have no code impact): > > config device > option name switch0 > option type bridge > > config bridge-vlan > option device switch0 > option vlan 1 > list ports 'lan1' > list ports 'lan2:t' > > config bridge-vlan > option device switch0 > option vlan 2 > list ports 'wan:u' # I think we also should support an explicit > # untag which is equivalent to no suffix > > config bridge-vlan > option device switch0 > option vlan 5 > list ports 'lan2:t*' # The "*" denotes a PVID > list ports 'lan3' > > config bridge-vlan > option device switch0 > option vlan 8 > list ports 'lan2:t' > list ports 'lan4' > > config bridge-vlan > option device switch0 > option vlan 11 > list ports 'lan2:t' > list ports 'lan4:t' > > > ~ Jo > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> -----Original Message----- > From: openwrt-devel [mailto:openwrt-devel-bounces@lists.openwrt.org] > On Behalf Of Jo-Philipp Wich > Sent: Mittwoch, 15. Juli 2020 14:19 > To: mail@adrianschmutzler.de; openwrt-devel@lists.openwrt.org > Subject: Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA > VLAN filter rules > > Hi, > > > I'm not sure whether using an asterisk is wise here, as it might pose > > interesting problems when people use scripts to set/evaluate uci > > config (as you have to be extra careful to not have it treated as a > > wildcard.) I'd be happy if we could find another symbol here. > > hm, can you elaborate on the problem here? Scripts which use uci values > verbatim without quoting are prone to any kind of shell injection flaws, not > sure if papering over such deficiencies is the way to go here. I'm not having a specific case in mind; and of course you are right about unquoted values. However, I just tend to not use certain special characters as a symbol without need as there always will be a case where "problems" show up later. For example, one might create interesting effects when using sed on uci config values (same would be true for the dot in swconfig at the moment, I admit). Of course, this is just for consideration, I won't insist on it if you think the asterisk is a superior solution here. Best Adrian > > ~ Jo
On 2020-07-15 13:52, John Crispin wrote: > > On 15.07.20 13:39, Jo-Philipp Wich wrote: >> Hi, >> >>> If we can't come up with a working automatic scheme, maybe we could have >>> an option to disable the cpu port per vlan? >> Having a default-enabled "option self" or "option local" was my idea as >> well. Any idea which name fits better? >> >> ~ Jo >> > self is what ip-bridge uses as a parameter name for this feature I think local is a better fit - self/master seems to be used for bridge vlan filter command target selection, not just for this feature. - Felix
One thing which is a bit awkward as long as the bridge itself is configured as an interface, is that as far as I have understood, creating a tagged interface to the bridge requires first setting up an interface for the bridge, e.g. with protocol Unmanaged, and then setting up one or more vlan tagged interfaces on top of it which can then be configured with ip addresses. (Maybe this isn't such a big deal though.) On Thu, 16 Jul 2020 at 06:00, Felix Fietkau <nbd@nbd.name> wrote: > > On 2020-07-15 13:52, John Crispin wrote: > > > > On 15.07.20 13:39, Jo-Philipp Wich wrote: > >> Hi, > >> > >>> If we can't come up with a working automatic scheme, maybe we could have > >>> an option to disable the cpu port per vlan? > >> Having a default-enabled "option self" or "option local" was my idea as > >> well. Any idea which name fits better? > >> > >> ~ Jo > >> > > self is what ip-bridge uses as a parameter name for this feature > I think local is a better fit - self/master seems to be used for bridge > vlan filter command target selection, not just for this feature. > > - Felix > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Hi, > One thing which is a bit awkward as long as the bridge itself is > configured as an interface, is that as far as I have understood, > creating a tagged interface to the bridge requires first setting up an > interface for the bridge, e.g. with protocol Unmanaged, and then > setting up one or more vlan tagged interfaces on top of it which can > then be configured with ip addresses. The following configuration: config interface foo option type bridge option ifname 'bar baz qrx' option proto ... Is actually a convenience shortcut for: config device option type bridge option name br-foo list ifname bar list ifname baz list ifname qrx config interface foo option ifname br-foo option proto ... So in order to define a bridge interface without IP configuration, you could solely use: config device option type bridge option name mybridge0 list ifname lan1 list ifname lan2 ... This has a couple of advantages: - You don't need a logical dummy interface - You can get rid of the implicit "br-" prefix - The resulting configuration becomes more explicit Regards, Jo
Ok thanks, I agree this makes much more sense. As Luiz mentioned earlier, this exposes more explicitly the awkwardness of the "network" option for wifi-iface pointing to an interface rather than a device. Related to this, is it possible to add a wireless interface to a bridge specifying a non-default PVID? I guess this is needed if one wants to run multiple wireless interfaces off a single bridge with different vlans. On Thu, 23 Jul 2020 at 08:53, Jo-Philipp Wich <jo@mein.io> wrote: > > Hi, > > > One thing which is a bit awkward as long as the bridge itself is > > configured as an interface, is that as far as I have understood, > > creating a tagged interface to the bridge requires first setting up an > > interface for the bridge, e.g. with protocol Unmanaged, and then > > setting up one or more vlan tagged interfaces on top of it which can > > then be configured with ip addresses. > The following configuration: > > config interface foo > option type bridge > option ifname 'bar baz qrx' > option proto ... > > Is actually a convenience shortcut for: > > config device > option type bridge > option name br-foo > list ifname bar > list ifname baz > list ifname qrx > > config interface foo > option ifname br-foo > option proto ... > > So in order to define a bridge interface without IP configuration, > you could solely use: > > config device > option type bridge > option name mybridge0 > list ifname lan1 > list ifname lan2 > ... > > This has a couple of advantages: > > - You don't need a logical dummy interface > - You can get rid of the implicit "br-" prefix > - The resulting configuration becomes more explicit > > > Regards, > Jo >
Hi, > Related to this, is it possible to add a wireless interface to a > bridge specifying a non-default PVID? I would have expected that something like config bridge-vlan option device mybridge0 option vlan 100 option ports 'wlan0:u*' achieves that effect. The wlan0 interface would be added as untagged port with PVID 100 to bridges VLAN filter rules. ~ Jo
Ok sure, but the documentation currently says "As WLAN interface names may be dynamic or unpredictable, it is strongly recommended that they be assigned to bridges using the network option in UCI wireless configuration" This is referring to the list of interfaces for the bridge, but presumably the same would/should apply to the bridge-vlan configuration? On Thu, 23 Jul 2020 at 11:59, Jo-Philipp Wich <jo@mein.io> wrote: > > Hi, > > > Related to this, is it possible to add a wireless interface to a > > bridge specifying a non-default PVID? > > I would have expected that something like > > config bridge-vlan > option device mybridge0 > option vlan 100 > option ports 'wlan0:u*' > > achieves that effect. The wlan0 interface would be added as untagged port with > PVID 100 to bridges VLAN filter rules. > > ~ Jo >
Hi, yeah I forgot to elaborate that in my last mail. The problem of dynamic / not explicitly addressable wifi interface names in the network config remains. The best solution I can think of is fixing the wifi ifnames using "option ifname" in the wifi-iface sections (which causes some very interesting effects in my tests when not applied to *all* wifi-ifaces) and then using those fixes names in /etc/config/network. The other alternative I see would be a hypothetical new notation comparable to the existing alias notation that resolves ifnames to their actual values at runtime... something like "@wifi-network(ssid=foo)" but this is just a very vague idea I had from time to time throughout the last few years which never gained any traction. ~Jo
Another option, as long as the standard method is to attach a wireless interface to a bridge though the "option network" in the wifi-ifaces, would be to add a corresponding "option pvid" to wifi-ifaces which could then be propagated to the bridge when the wifi interface is added. On Thu, 23 Jul 2020 at 12:10, Jo-Philipp Wich <jo@mein.io> wrote: > > Hi, > > yeah I forgot to elaborate that in my last mail. The problem of dynamic / not > explicitly addressable wifi interface names in the network config remains. > > The best solution I can think of is fixing the wifi ifnames using "option > ifname" in the wifi-iface sections (which causes some very interesting effects > in my tests when not applied to *all* wifi-ifaces) and then using those fixes > names in /etc/config/network. > > The other alternative I see would be a hypothetical new notation comparable to > the existing alias notation that resolves ifnames to their actual values at > runtime... something like "@wifi-network(ssid=foo)" but this is just a very > vague idea I had from time to time throughout the last few years which never > gained any traction. > > ~Jo >
Hi, On 2020-07-23 12:10, Jo-Philipp Wich wrote: > yeah I forgot to elaborate that in my last mail. The problem of dynamic / not > explicitly addressable wifi interface names in the network config remains. > > The best solution I can think of is fixing the wifi ifnames using "option > ifname" in the wifi-iface sections (which causes some very interesting effects > in my tests when not applied to *all* wifi-ifaces) and then using those fixes > names in /etc/config/network. > > The other alternative I see would be a hypothetical new notation comparable to > the existing alias notation that resolves ifnames to their actual values at > runtime... something like "@wifi-network(ssid=foo)" but this is just a very > vague idea I had from time to time throughout the last few years which never > gained any traction. I'm considering the following extensions to netifd: 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). For a simple default config, you could have this: # network config device option name switch0 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? - Felix
"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." By this you mean that the creation of the switch0.1 device will trigger automatically through the hotplug op "bridge vlan add dev switch0 vid 1 tagged self" or its equivalent? On Thu, 23 Jul 2020 at 13:29, Felix Fietkau <nbd@nbd.name> wrote: > > Hi, > > On 2020-07-23 12:10, Jo-Philipp Wich wrote: > > yeah I forgot to elaborate that in my last mail. The problem of dynamic / not > > explicitly addressable wifi interface names in the network config remains. > > > > The best solution I can think of is fixing the wifi ifnames using "option > > ifname" in the wifi-iface sections (which causes some very interesting effects > > in my tests when not applied to *all* wifi-ifaces) and then using those fixes > > names in /etc/config/network. > > > > The other alternative I see would be a hypothetical new notation comparable to > > the existing alias notation that resolves ifnames to their actual values at > > runtime... something like "@wifi-network(ssid=foo)" but this is just a very > > vague idea I had from time to time throughout the last few years which never > > gained any traction. > I'm considering the following extensions to netifd: > > 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). > > For a simple default config, you could have this: > > # network > config device > option name switch0 > > 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? > > - Felix
> On 23. Jul 2020, at 13:44, Josh Bendavid <joshbendavid@gmail.com> wrote: > > "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." > > By this you mean that the creation of the switch0.1 device will > trigger automatically through the hotplug op > "bridge vlan add dev switch0 vid 1 tagged self" or its equivalent? No, it refers to how wifi interfaces are added dynamically in netifd. If lan is a bridge and the wifi-iface has option network lan, it means that wlan* is added to br-lan automatically. I want to make that same mechanism work with lan ifname switch0.1 (and no extra lan bridge) as well. - Felix
Ok I see, but then wouldn't it be much simpler to specify the bridge device directly in wifi-ifaces instead of the network? It's also needed in this case to ensure that the bridge-vlan section can configure tagging on the bridge interface itself. On Thu, 23 Jul 2020 at 13:53, Felix Fietkau <nbd@nbd.name> wrote: > > > > On 23. Jul 2020, at 13:44, Josh Bendavid <joshbendavid@gmail.com> wrote: > > > > "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." > > > > By this you mean that the creation of the switch0.1 device will > > trigger automatically through the hotplug op > > "bridge vlan add dev switch0 vid 1 tagged self" or its equivalent? > No, it refers to how wifi interfaces are added dynamically in netifd. > If lan is a bridge and the wifi-iface has option network lan, it means that wlan* is added to br-lan automatically. I want to make that same mechanism work with lan ifname switch0.1 (and no extra lan bridge) as well. > > - Felix
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. 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. ~Jo
Hi again, > 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. That should have read: Add an option bridge that specifies the target bridge name and an option vlan which contains vlan id, followed by the tag/untag/pvid spec as defined for bridge ports. Also a fourth example: option bridge switch0 option vlan 20 # is equivalent to 20:u* Since setting a non-default untagged pvid is by far the most (and likely only sensible) use case for wifi-ifaces, specifying a vlan id without any suffix should be supported as well. So `N` should be equivalent to `N:u*` or `N:*`. ~ Jo
> On 23. Jul 2020, at 14:17, Jo-Philipp Wich <jo@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
> 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. I think we should try hard to split between L2 and L3 as a goal. Those convenient shortcuts (interface.type=bridge) make it harder for a newcomer to understand what is going on. I would try to avoid them. I had to explain the mixed concepts dozens of times for newbies, even for those with Linux experience. It's just confusing that linux network devices, which are also called network interfaces, are not OpenWrt interfaces. I hope someday I could see the same "names" both in config and the output from network commands like ip address. OpenWrt interface name could be a label for an address. OpenWrt uses multiple names "ifname, iface, device, network, interface" sometimes for the same and also different concepts. Those names/references should be standardized. Choose one and stick with it. Also, there is the problem of how to reference a device/interface. It should be much easier if the section name could be always used. However, uci has its limitations, which requires an "option name". I would use "option name" as "section name" by default, requiring it to be set explicitly only as a way to overcome the uci section name limitations. Wireless defines a network device and maybe wifi-iface should be declared simply as a type of device with some extra options and a reference to a radio. BTW, wireless.wifi-device introduces another confusion with network.device and simply "radio" might be better. It would be better to have predictable interface names for everything. If it is not possible, we could introduce a reverse option "device_for". As both device and interface section can have a device option, "option device_for" could use both as a valid value. This is a simple example to illustrate general idea: config radio 'radio0' option type 'mac80211' option hwmode '11a' config device 'wifinet_wan' option type wifi option ssid 'uplink_wwan' option radio 'radio0' option mode 'sta' option device_for wan # reverse referenced for an interface config device 'wifinet_OpenWrt' # wifinet_ap will be the linux network device name option type wifi option ssid 'OpenWrt' option radio 'radio0' option mode 'ap' option device_for brlan # reverse referenced for a device config device 'wifinet_OpenWrt2' # wifinet_ap2 will be the linux network device name option type wifi option ssid 'OpenWrt2' option radio 'radio0' option mode 'ap' config device brlan type bridge # option name brlan # by default, no need to set list device dev1 list device dev2 list device dev3 # list device wifinet_OpenWrt list device wifinet_OpenWrt2 # directly referencing config interface lan option device brlan #device instead of ifname option proto static config interface lan6 option device @lan #the value for lan.device option proto static config interface wan # option device wifinet_wan option proto dhcp --- Luiz Angelo Daros de Luca
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 - 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 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. Regards, Jo
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
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 > > 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. 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? Regards, Jo
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. - Felix
Hi all, A couple things which I think seem to still be missing are: port mirroring (src port, dst port) flow control (enable/disable) stp (type, enable/disable) igmp snooping And some other features, which as far as I can tell should be possible with DSA: LAG LLDP Jumbo Frames Greets, P On 7/14/20 5:34 PM, Josh Bendavid wrote: > Hi, > I have a somewhat radical comment on this. > > As far as I understand, the vlan filtering support in the linux bridge > subsystem is not specific to dsa, but can equally be configured for a > pure software bridge. The fact that the switch supports dsa/switchdev > then simply allows this to be transparently handled in hardware, just > like the simple bridging of the switch port interfaces. > > Isn't it conceptually more correct in this case for the vlan filtering > to be configured as part of the "interface" in uci? > Ie I configure an interface of type "bridge" which bridges the switch > ports, then the vlan filtering is a configuration property of this > interface (just like enabling igmp_snooping on a bridge interface) > > Thanks, > Josh > > On Tue, 7 Jul 2020 at 22:13, Jo-Philipp Wich <jo@mein.io> wrote: >> >> This patch series introduces a new package "dsaconfig" which provides the >> necessary logic to allow configuration of bridge vlan filter rules for >> DSA switches. >> >> While well supported DSA switches can be programmed by solely bridging >> per-port netdevices together, explicit bridge VLAN filter rules are needed >> for more complex scenarios or for DSA switches that do not support a >> tagging protocol. >> >> The UCI configuration interpreted by the dsaconfig package closely follows >> the structure and semantics of the legacy swconfig architecture, honouring >> "dsa", "dsa_vlan" and "dsa_port" sections within the >> /etc/config/network file. The only difference compared to swconfig is >> that "dsa" sections are optional and that the syntax of ports within >> the "dsa_vlan" section differs, instead of <portnumber><tag>?, e.g. >> "0t", "1u" or "2", it is now <portname>(.<tag>)?, e.g. "wan.u", "lan1.t" >> or "lan2". >> >> The dsaconfig package will spawn a bridge device named "switchN" for each >> DSA switch, where N denotes the number of the switch. In contrast to >> swconfig, interfaces do not use the CPU port to target VLAN port groups on >> the switch but reference a VLAN on top of the switch, e.g. >> "option ifname switch0.1" to use the VLAN 1 port group on the first DSA >> switch. >> >> A complete configuration example for a simple LAN/WAN setup might look >> like below. Note that this configuration should be equivalent to just >> bridging lan1..lan4 without any VLAN filter rules. >> >> -- 8< -- >> config dsa_vlan >> option vlan 1 >> option ports 'lan1 lan2 lan3 lan4' >> >> config dsa_vlan >> option vlan 2 >> option ports 'wan' >> >> config interface lan >> option ifname switch0.1 >> option proto static >> option ipaddr 192.168.1.1/24 >> >> config interface wan >> option ifname switch0.2 >> option proto dhcp >> -- >8 -- >> >> A slightly more complex example that uses multiple tagged VLANs on different >> ports would look like this: >> >> -- 8< -- >> config dsa switch0 >> ## Override CPU port. Normally it is auto-discovered. >> #option cpu_port eth0 >> >> config dsa_vlan >> ## Specify the switch this vlan belongs to. >> ## If there is only one switch on the system, it may be omitted. >> #option device switch0 >> option vlan 1 >> option ports 'lan1 lan2.t' >> >> config dsa_vlan >> #option device switch0 >> option vlan 2 >> option ports 'wan' >> >> config dsa_vlan >> #option device switch0 >> option vlan 5 >> option ports 'lan2.t lan3' >> >> config dsa_vlan >> #option device switch0 >> option vlan 8 >> option ports 'lan2.t lan4' >> >> config dsa_vlan >> #option device switch0 >> option vlan 11 >> option ports 'lan2.t lan4.t' >> >> config dsa_port >> #option device switch0 >> option port lan2 >> ## By default, the port PVID is set to the ID of the first >> ## untagged VLAN the port is member of. It can be overriden here. >> option pvid 5 >> >> config interface lan >> option type bridge >> option ifname 'switch0.1 wlan0' >> option proto static >> option ipaddr 192.168.1.1/24 >> >> config interface wan >> option ifname switch0.2 >> option proto dhcp >> >> config interface vlan5 >> option ifname switch0.5 >> option proto static >> option ipaddr 10.255.5.1/24 >> >> config interface vlan8 >> option ifname switch0.8 >> option proto static >> option ipaddr 10.255.8.1/24 >> >> config interface vlan11 >> option ifname switch0.11 >> option proto static >> option ipaddr 10.255.11.1/24 >> -- >8 -- >> >> Additionally, the "dsaconfig" executable provided by this package implements >> a "show" option to display the current switch port states and their VLAN >> memberships in a compact manner. For the latter configuration example above, >> the utility would produce an output similar to the following: >> >> -- 8< -- >> root@OpenWrt:~# dsaconfig show >> Switch: switch0 >> VLAN/ | lan1 | lan2 | lan3 | lan4 | wan | >> Link: | down | 1000F | down | 1000F | down | >> 1 | u* | t | | | | >> 2 | | | | | u* | >> 5 | | t* | u* | | | >> 8 | t | t | | u* | | >> 11 | | t | | t | | >> >> -- >8 -- >> >> This code has been tested on a WRT3200ACM and a Mir3G but is supposed to >> work with any DSA switch. It requires wider testing before it is suitable >> for inclusion. >> >> Once the configuration format is and rule logic is finalized, the shell >> script code provided by this package should be implemented directly in >> netifd C code to reduce the amount of required external dependencies and >> to allow for improved performance when processing large configurations. >> >> Open questions/topics: >> >> - Ensure that the chosen configuration approach actually works with >> DSA_TAG_PROTO_NONE switches >> >> - Investigate potential MTU issues regarding the CPU port >> >> Changes since v1: >> >> - Rename switch, switch_vlan and switch_port sections to dsa, dsa_vlan >> and dsa_port respectively >> >> - Forcibly move DSA ports to the switch bridge if they're part of another >> bridge yet >> >> - Disallow VLAN ID 0 >> >> - Properly display unassigned ports as empty in "dsaconfig show" >> >> - Handle implicit switch0 in "dsaconfig show" >> >> Jo-Philipp Wich (1): >> dsaconfig: introduce package for UCI configuration of VLAN filter >> rules >> >> package/network/config/dsaconfig/Makefile | 40 +++ >> .../config/dsaconfig/files/dsaconfig.hotplug | 7 + >> .../config/dsaconfig/files/dsaconfig.include | 11 + >> .../config/dsaconfig/files/dsaconfig.sh | 306 ++++++++++++++++++ >> 4 files changed, 364 insertions(+) >> create mode 100644 package/network/config/dsaconfig/Makefile >> create mode 100644 package/network/config/dsaconfig/files/dsaconfig.hotplug >> create mode 100755 package/network/config/dsaconfig/files/dsaconfig.include >> create mode 100755 package/network/config/dsaconfig/files/dsaconfig.sh >> >> -- >> 2.27.0 >> >> >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > . >
> config dsa_vlan > option vlan 1 > option ports 'lan1 lan2 lan3 lan4' Just got aware that this will make the names/labels of the ports part of the config (not just their internal numbers, as before), i.e. we cannot change them afterwards. Maybe we should think again about whether those can be standardized to some extent .... Best Adrian
Hi, > -----Original Message----- > From: openwrt-devel [mailto:openwrt-devel-bounces@lists.openwrt.org] > On Behalf Of Jo-Philipp Wich > Sent: Dienstag, 7. Juli 2020 22:11 > To: openwrt-devel@lists.openwrt.org > Cc: Jo-Philipp Wich <jo@mein.io> > Subject: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN > filter rules > > This patch series introduces a new package "dsaconfig" which provides the > necessary logic to allow configuration of bridge vlan filter rules for DSA > switches. > > While well supported DSA switches can be programmed by solely bridging > per-port netdevices together, explicit bridge VLAN filter rules are needed for > more complex scenarios or for DSA switches that do not support a tagging > protocol. > > The UCI configuration interpreted by the dsaconfig package closely follows > the structure and semantics of the legacy swconfig architecture, honouring > "dsa", "dsa_vlan" and "dsa_port" sections within the /etc/config/network > file. The only difference compared to swconfig is that "dsa" sections are > optional and that the syntax of ports within the "dsa_vlan" section differs, > instead of <portnumber><tag>?, e.g. > "0t", "1u" or "2", it is now <portname>(.<tag>)?, e.g. "wan.u", "lan1.t" > or "lan2". > > The dsaconfig package will spawn a bridge device named "switchN" for each > DSA switch, where N denotes the number of the switch. In contrast to > swconfig, interfaces do not use the CPU port to target VLAN port groups on > the switch but reference a VLAN on top of the switch, e.g. > "option ifname switch0.1" to use the VLAN 1 port group on the first DSA > switch. > > A complete configuration example for a simple LAN/WAN setup might look > like below. Note that this configuration should be equivalent to just bridging > lan1..lan4 without any VLAN filter rules. > > -- 8< -- > config dsa_vlan > option vlan 1 > option ports 'lan1 lan2 lan3 lan4' > > config dsa_vlan > option vlan 2 > option ports 'wan' > > config interface lan > option ifname switch0.1 > option proto static > option ipaddr 192.168.1.1/24 > > config interface wan > option ifname switch0.2 > option proto dhcp Looking at this from yet another angle, with the new "port names" we got ourselves an ambiguous "wan": We may have a "port" labelled "wan" and use the same name for the "interface" wan in uci config. While this most probably will work for a basic implementation, I'm starting to wonder whether there will be cases where "wan", e.g. used as an ifname, wouldn't be uniquely assignable to one of the two cases (apart from the general confusion for the unaware user)? Best Adrian
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. - Martin
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. - Felix
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? - Martin
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? > `ubus call network.device status` shows: ... "switch0": { "external": false, "present": true, "type": "bridge", "up": true, "carrier": true, "bridge-members": [ "lan1", "lan2", "lan3", "lan4", "wlan0" ], "bridge-vlans": [ { "id": 1, "local": true, "ports": [ "lan1", "lan2", "lan3", "lan4" ] } ], ...
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? - Felix
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
On 2021-03-26 10:49, Martin Schiller wrote: > 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 > Hello Felix! Have you already found time to look at this problem? I think this affects quite a few users when DSA is used "productively".
On 2021-03-26 10:30, Martin Schiller 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? >> > > `ubus call network.device status` shows: > > > ... > "switch0": { > "external": false, > "present": true, > "type": "bridge", > "up": true, > "carrier": true, > "bridge-members": [ > "lan1", > "lan2", > "lan3", > "lan4", > "wlan0" > ], > "bridge-vlans": [ > { > "id": 1, > "local": true, > "ports": [ > "lan1", > "lan2", > "lan3", > "lan4" > ] > } > ], > ... > As you can see here, "wlan0" is added to the "bridge-members", but not to the "ports" of the "bridge-vlans"/"id":1. Maybe this is the problem? - Martin
On 2021-04-28 14:39, Martin Schiller wrote: > On 2021-03-26 10:30, Martin Schiller 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? >>> >> >> `ubus call network.device status` shows: >> >> >> ... >> "switch0": { >> "external": false, >> "present": true, >> "type": "bridge", >> "up": true, >> "carrier": true, >> "bridge-members": [ >> "lan1", >> "lan2", >> "lan3", >> "lan4", >> "wlan0" >> ], >> "bridge-vlans": [ >> { >> "id": 1, >> "local": true, >> "ports": [ >> "lan1", >> "lan2", >> "lan3", >> "lan4" >> ] >> } >> ], >> ... >> > > As you can see here, "wlan0" is added to the "bridge-members", but not > to the "ports" of the "bridge-vlans"/"id":1. Maybe this is the problem? > With netifd commit 61a71e5e49c3 ("bridge: dynamically create vlans for hotplug members) the behavior has changed in that now the wlan0 interface is added to the "ports" of the "bridge-vlans"/"id":1, but unfortunately the lan ports are kicked out: ... "switch0": { "external": false, "present": true, "type": "bridge", "up": true, "carrier": true, "auth_status": false, "bridge-members": [ "lan1", "lan2", "lan3", "lan4", "wlan0" ], "bridge-vlans": [ { "id": 1, "local": true, "ports": [ "wlan0" ] } ], ...
This patch series introduces a new package "dsaconfig" which provides the necessary logic to allow configuration of bridge vlan filter rules for DSA switches. While well supported DSA switches can be programmed by solely bridging per-port netdevices together, explicit bridge VLAN filter rules are needed for more complex scenarios or for DSA switches that do not support a tagging protocol. The UCI configuration interpreted by the dsaconfig package closely follows the structure and semantics of the legacy swconfig architecture, honouring "dsa", "dsa_vlan" and "dsa_port" sections within the /etc/config/network file. The only difference compared to swconfig is that "dsa" sections are optional and that the syntax of ports within the "dsa_vlan" section differs, instead of <portnumber><tag>?, e.g. "0t", "1u" or "2", it is now <portname>(.<tag>)?, e.g. "wan.u", "lan1.t" or "lan2". The dsaconfig package will spawn a bridge device named "switchN" for each DSA switch, where N denotes the number of the switch. In contrast to swconfig, interfaces do not use the CPU port to target VLAN port groups on the switch but reference a VLAN on top of the switch, e.g. "option ifname switch0.1" to use the VLAN 1 port group on the first DSA switch. A complete configuration example for a simple LAN/WAN setup might look like below. Note that this configuration should be equivalent to just bridging lan1..lan4 without any VLAN filter rules. -- 8< -- config dsa_vlan option vlan 1 option ports 'lan1 lan2 lan3 lan4' config dsa_vlan option vlan 2 option ports 'wan' config interface lan option ifname switch0.1 option proto static option ipaddr 192.168.1.1/24 config interface wan option ifname switch0.2 option proto dhcp -- >8 -- A slightly more complex example that uses multiple tagged VLANs on different ports would look like this: -- 8< -- config dsa switch0 ## Override CPU port. Normally it is auto-discovered. #option cpu_port eth0 config dsa_vlan ## Specify the switch this vlan belongs to. ## If there is only one switch on the system, it may be omitted. #option device switch0 option vlan 1 option ports 'lan1 lan2.t' config dsa_vlan #option device switch0 option vlan 2 option ports 'wan' config dsa_vlan #option device switch0 option vlan 5 option ports 'lan2.t lan3' config dsa_vlan #option device switch0 option vlan 8 option ports 'lan2.t lan4' config dsa_vlan #option device switch0 option vlan 11 option ports 'lan2.t lan4.t' config dsa_port #option device switch0 option port lan2 ## By default, the port PVID is set to the ID of the first ## untagged VLAN the port is member of. It can be overriden here. option pvid 5 config interface lan option type bridge option ifname 'switch0.1 wlan0' option proto static option ipaddr 192.168.1.1/24 config interface wan option ifname switch0.2 option proto dhcp config interface vlan5 option ifname switch0.5 option proto static option ipaddr 10.255.5.1/24 config interface vlan8 option ifname switch0.8 option proto static option ipaddr 10.255.8.1/24 config interface vlan11 option ifname switch0.11 option proto static option ipaddr 10.255.11.1/24 -- >8 -- Additionally, the "dsaconfig" executable provided by this package implements a "show" option to display the current switch port states and their VLAN memberships in a compact manner. For the latter configuration example above, the utility would produce an output similar to the following: -- 8< -- root@OpenWrt:~# dsaconfig show Switch: switch0 VLAN/ | lan1 | lan2 | lan3 | lan4 | wan | Link: | down | 1000F | down | 1000F | down | 1 | u* | t | | | | 2 | | | | | u* | 5 | | t* | u* | | | 8 | t | t | | u* | | 11 | | t | | t | | -- >8 -- This code has been tested on a WRT3200ACM and a Mir3G but is supposed to work with any DSA switch. It requires wider testing before it is suitable for inclusion. Once the configuration format is and rule logic is finalized, the shell script code provided by this package should be implemented directly in netifd C code to reduce the amount of required external dependencies and to allow for improved performance when processing large configurations. Open questions/topics: - Ensure that the chosen configuration approach actually works with DSA_TAG_PROTO_NONE switches - Investigate potential MTU issues regarding the CPU port Changes since v1: - Rename switch, switch_vlan and switch_port sections to dsa, dsa_vlan and dsa_port respectively - Forcibly move DSA ports to the switch bridge if they're part of another bridge yet - Disallow VLAN ID 0 - Properly display unassigned ports as empty in "dsaconfig show" - Handle implicit switch0 in "dsaconfig show" Jo-Philipp Wich (1): dsaconfig: introduce package for UCI configuration of VLAN filter rules package/network/config/dsaconfig/Makefile | 40 +++ .../config/dsaconfig/files/dsaconfig.hotplug | 7 + .../config/dsaconfig/files/dsaconfig.include | 11 + .../config/dsaconfig/files/dsaconfig.sh | 306 ++++++++++++++++++ 4 files changed, 364 insertions(+) create mode 100644 package/network/config/dsaconfig/Makefile create mode 100644 package/network/config/dsaconfig/files/dsaconfig.hotplug create mode 100755 package/network/config/dsaconfig/files/dsaconfig.include create mode 100755 package/network/config/dsaconfig/files/dsaconfig.sh