| Message ID | 20190714135037.18471-1-linus.walleij@linaro.org |
|---|---|
| State | Not Applicable |
| Delegated to: | Petr Štetiar |
| Headers | show |
| Series | [OpenWrt-Devel,v2] gemini: Bring up DSA switches | expand |
On 14.07.2019 15:50, Linus Walleij wrote: > +storlink,gemini324) > + # These are all connected to eth1 thru VSC7385 > + ucidef_set_interface "eth" ifname "eth1" protocol "none" > + ucidef_set_interfaces_lan_wan "eth1 lan1 lan2 lan3 lan4" "eth0" > + ;; and: > +itian,sq201) > + # These are all connected to eth1 thru VSC7395 > + ucidef_set_interface "eth" ifname "eth1" protocol "none" > + ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" "eth0" > + ;; Hi Linus, I can't reproduce working state on P2020RDB with this two methods. In my device work this sequence: ip link set eth0 up ip link set lan1 up ip link set lan2 up ip link set lan3 up ip link set lan4 up ip link add name br-lan type bridge ip link set dev lan1 master br-lan ip link set dev lan2 master br-lan ip link set dev lan3 master br-lan ip link set dev lan4 master br-lan ip addr add 192.168.1.1/24 dev br-lan ip link set dev br-lan up ip link set dev eth0 master br-lan I think, vsc73xx without vlan filtering is very tricky now. Best Regards, Pawel Dembicki
On Sun, Jul 14, 2019 at 5:15 PM Pawel Dembicki <paweldembicki@gmail.com> wrote: > > +storlink,gemini324) > > + # These are all connected to eth1 thru VSC7385 > > + ucidef_set_interface "eth" ifname "eth1" protocol "none" > > + ucidef_set_interfaces_lan_wan "eth1 lan1 lan2 lan3 lan4" "eth0" > > + ;; Ooops I say I shall fix it then I don't. eth1 is still there. OK I fix a v3. The switch is working fine on the VSC7385 like this. > I can't reproduce working state on P2020RDB with this two methods. > In my device work this sequence: > > ip link set eth0 up > ip link set lan1 up > ip link set lan2 up > ip link set lan3 up > ip link set lan4 up > ip link add name br-lan type bridge > ip link set dev lan1 master br-lan > ip link set dev lan2 master br-lan > ip link set dev lan3 master br-lan > ip link set dev lan4 master br-lan > ip addr add 192.168.1.1/24 dev br-lan > ip link set dev br-lan up > ip link set dev eth0 master br-lan > > I think, vsc73xx without vlan filtering is very tricky now. I think you should have it like this: ucidef_set_interface "eth" ifname "eth0" protocol "none" ucidef_set_interfaces_lan "lan1 lan2 lan3 lan4" If you don't have any WAN interface (uplink) on the device. Yours, Linus Walleij
On Sun, Jul 14, 2019 at 10:46 PM Linus Walleij <linus.walleij@linaro.org> wrote: > On Sun, Jul 14, 2019 at 5:15 PM Pawel Dembicki <paweldembicki@gmail.com> wrote: > > > > +storlink,gemini324) > > > + # These are all connected to eth1 thru VSC7385 > > > + ucidef_set_interface "eth" ifname "eth1" protocol "none" > > > + ucidef_set_interfaces_lan_wan "eth1 lan1 lan2 lan3 lan4" "eth0" > > > + ;; > > Ooops I say I shall fix it then I don't. eth1 is still there. > > OK I fix a v3. The switch is working fine on the VSC7385 like > this. Or no it doesn't. I'm not smart today... Keeping eth1 as "none" isn't working. I had to assign a static address (the same) to eth1 as well, then it works. In /etc/config/network it looks like this: config interface 'eth' option ifname 'eth1' option proto 'static' option ipaddr '169.254.1.2' option netmask '255.255.255.0' config interface 'lan' option type 'bridge' option ifname 'lan1 lan2 lan3 lan4' option proto 'static' option ipaddr '169.254.1.2' option netmask '255.255.255.0' option ip6assign '60' I don't know if there is any better way to fix it? Yours, Linus Walleij
On Sun, Jul 14, 2019 at 23:12 Linus Walleij <linus.walleij@linaro.org> wrote: > > > I don't know if there is any better way to fix it? > I think, that the best approach is vlan filtering. I started some work: https://github.com/CHKDSK88/linux/commit/38b62482d9f828b5720db11145fa474e368b248c At this moment it works (I used ip-full and ip-bridge packets). But I have no idea how to integrate dsa vlan filtering with OpenWRT configuration. This is first dsa switch with DSA_TAG_PROTO_NONE in OpenWRT. Best regards, Pawel Dembicki
On Fri, Jul 19, 2019 at 6:49 AM Paweł Dembicki <paweldembicki@gmail.com> wrote: > I think, that the best approach is vlan filtering. I started some work: > https://github.com/CHKDSK88/linux/commit/38b62482d9f828b5720db11145fa474e368b248c Hey! I wanted to do that but never had time, so very happy that you're fixing it up! :) > At this moment it works (I used ip-full and ip-bridge packets). But I > have no idea how to integrate dsa vlan filtering with OpenWRT > configuration. > This is first dsa switch with DSA_TAG_PROTO_NONE in OpenWRT. I think in the upstream kernel look at commit f9bbe4477c30ece44296437ee26142b42ef8070b "net: dsa: Optional VLAN-based port separation for switches without tagging" by Vladimir Oltean. I intuitively think this is what we want to do in the end is use DSA_TAG_PROTO_8021Q but admittedly I don't think I understand VLANs well enough for enabling this. For OpenWrt using kernel v4.19 I have no idea what the best would be. I don't think Vladimir's work can be easily backported. I suppose some special hack to just bring up the DSA with a custom script is the best compromise for the time being. FYI this board supported by OpenWrt also has this switch: https://openwrt.org/toh/evaluation.boards/pb44 with a custom driver: https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/files/drivers/spi/spi-vsc7385.c It's a MIPS device though, and I don't know if anyone is actively maintaining it and could test to migrate it to this new driver and help out? Yours, Linus Walleij
> On Fri, Jul 19, 2019 at 09:51 Linus Walleij <linus.walleij@linaro.org> wrote: > > > I think, that the best approach is vlan filtering. I started some work: > > https://github.com/CHKDSK88/linux/commit/38b62482d9f828b5720db11145fa474e368b248c > > Hey! I wanted to do that but never had time, > so very happy that you're fixing it up! :) > It would be great if You found some time to test it. :) > > At this moment it works (I used ip-full and ip-bridge packets). But I > > have no idea how to integrate dsa vlan filtering with OpenWRT > > configuration. > > This is first dsa switch with DSA_TAG_PROTO_NONE in OpenWRT. > > I think in the upstream kernel look at > commit f9bbe4477c30ece44296437ee26142b42ef8070b > "net: dsa: Optional VLAN-based port separation for switches without tagging" > by Vladimir Oltean. > > I intuitively think this is what we want to do in the end is use > DSA_TAG_PROTO_8021Q but admittedly I don't think I > understand VLANs well enough for enabling this. > This is the question for OpenWRT core developers. What is the best approach for DSA_TAG_PROTO_NONE switches? DSA_TAG_PROTO_8021Q or just vlan filtering and configuration without tagging support? Both solutions can give You port separation. Personally I prefer simple vlan separation. This method was used in OpenWRT for many non-dsa switches. But it need to create API for dsa devices. > For OpenWrt using kernel v4.19 I have no idea what the best would > be. I don't think Vladimir's work can be easily backported. > I suppose some special hack to just bring up the DSA with > a custom script is the best compromise for the time being. > I agree with You. At this moment only hack could work. > FYI this board supported by OpenWrt also has this switch: > https://openwrt.org/toh/evaluation.boards/pb44 > with a custom driver: > https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/files/drivers/spi/spi-vsc7385.c > It's a MIPS device though, and I don't know if anyone is > actively maintaining it and could test to migrate it to this > new driver and help out? Pb44 isn't ported to ath79 yet. I think, it is abandoned at this moment. Best Regards, Pawel Dembicki
Hi Pawel, Linus, On Fri, 19 Jul 2019 at 12:22, Paweł Dembicki <paweldembicki@gmail.com> wrote: > > > On Fri, Jul 19, 2019 at 09:51 Linus Walleij <linus.walleij@linaro.org> wrote: > > > > > I think, that the best approach is vlan filtering. I started some work: > > > https://github.com/CHKDSK88/linux/commit/38b62482d9f828b5720db11145fa474e368b248c > > > > Hey! I wanted to do that but never had time, > > so very happy that you're fixing it up! :) > > > > It would be great if You found some time to test it. :) > > > > At this moment it works (I used ip-full and ip-bridge packets). But I > > > have no idea how to integrate dsa vlan filtering with OpenWRT > > > configuration. > > > This is first dsa switch with DSA_TAG_PROTO_NONE in OpenWRT. > > > > I think in the upstream kernel look at > > commit f9bbe4477c30ece44296437ee26142b42ef8070b > > "net: dsa: Optional VLAN-based port separation for switches without tagging" > > by Vladimir Oltean. > > > > I intuitively think this is what we want to do in the end is use > > DSA_TAG_PROTO_8021Q but admittedly I don't think I > > understand VLANs well enough for enabling this. > > > > This is the question for OpenWRT core developers. What is the best > approach for DSA_TAG_PROTO_NONE switches? > > DSA_TAG_PROTO_8021Q or just vlan filtering and configuration without > tagging support? Both solutions can give You port separation. > > Personally I prefer simple vlan separation. This method was used in > OpenWRT for many non-dsa switches. But it need to create API for dsa > devices. > I have never used OpenWRT on a board having an L2 switch so I don't know how traffic over the switch ports is managed there. In theory it is possible to transplant the dsa_port_setup_8021q_tagging function from net/dsa/tag_8021q.c into a shell script that operates with 'bridge vlan' operations. However you will quickly find that you will need to do 'bridge vlan add vid ${rx_vid} dev ${cpu_port}' aka "tagged egress" <- but surprise, there is no CPU port net device exposed to userspace. I see you overcame this by hardcoding the CPU port as a VLAN trunk for all VLANs added on the user ports. This is going to work as a hack, but you will need to add 2 VLAN sub-interfaces to the master port per switch front-panel port - one for TX and another for RX. Otherwise you will have the switch work as standalone net devices, but you'll break its core functionality - switching. And you'll likely need to do exotic things with applications that need bidirectional communication over switch ports, because ingress and egress will happen over different interfaces. DSA_TAG_PROTO_8021Q abstracts all of that away and the switch netdevices will not need any VLAN sub-interface on top of the master port, and no hardcoding of VLAN trunking over the CPU port either. But then there's the semantics issue - the network stack expects that a bridge with vlan_filtering disabled (the default) passes frames with the 802.1Q EtherType (0x8100) unmodified. It also expects that the switch doesn't perform port membership enforcements based on the VLAN ID. To be compliant, you'll either need to go your route and install the VLANs from userspace (hence you activate vlan_filtering which will means that having a bridge will be a requirement, even the "standalone ports" mode will be emulated), and accept the above limitations, or go with DSA_TAG_PROTO_8021Q and figure out a way that the switch parses and emits VLAN-tagged frames using a different EtherType than the default (case in which the stack will not need to know that the switch is dealing with VLANs as part of its tagging protocol). And when vlan_filtering is enabled, you either have to expose the VLANs used for tagging to the bridge core, or encapsulate the custom tags, or disable tagging. If you choose DSA_TAG_PROTO_8021Q, there is no universal way to ensure the switch treats standard 802.1Q frames distinctly from custom 802.1Q ones - whatever works and is supported by your hardware. Again, with a network stack framework that doesn't rely on the bridge driver (I don't know how OpenWRT/swconfig works), the requirement that the switch obeys the vlan_filtering semantics may be much more lax. For DSA/switchdev, it is what it is. You should also consider that you need Shared VLAN Learning (instead of Independent VLAN Learning) in order not to break address learning and have the switch flood everything. > > For OpenWrt using kernel v4.19 I have no idea what the best would > > be. I don't think Vladimir's work can be easily backported. > > I suppose some special hack to just bring up the DSA with > > a custom script is the best compromise for the time being. > > > > I agree with You. At this moment only hack could work. > > > > FYI this board supported by OpenWrt also has this switch: > > https://openwrt.org/toh/evaluation.boards/pb44 > > with a custom driver: > > https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/files/drivers/spi/spi-vsc7385.c > > It's a MIPS device though, and I don't know if anyone is > > actively maintaining it and could test to migrate it to this > > new driver and help out? > > Pb44 isn't ported to ath79 yet. I think, it is abandoned at this moment. > > Best Regards, > Pawel Dembicki Hope this helps, -Vladimir
diff --git a/target/linux/gemini/base-files/etc/board.d/02_network b/target/linux/gemini/base-files/etc/board.d/02_network new file mode 100755 index 000000000000..b5c486666c82 --- /dev/null +++ b/target/linux/gemini/base-files/etc/board.d/02_network @@ -0,0 +1,27 @@ +#!/bin/sh + +. /lib/functions/uci-defaults.sh + +board_config_update + +case "$(board_name)" in +storlink,gemini324) + # These are all connected to eth1 thru VSC7385 + ucidef_set_interface "eth" ifname "eth1" protocol "none" + ucidef_set_interfaces_lan_wan "eth1 lan1 lan2 lan3 lan4" "eth0" + ;; +itian,sq201) + # These are all connected to eth1 thru VSC7395 + ucidef_set_interface "eth" ifname "eth1" protocol "none" + ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" "eth0" + ;; +dlink,dir-685) + # These are all connected to eth0 thru RTL8366RB + ucidef_set_interface "eth" ifname "eth0" protocol "none" + ucidef_set_interfaces_lan_wan "lan0 lan1 lan2 lan3" "wan" + ;; +esac + +board_config_flush + +exit 0
First group the interfaces on the DSA switch into the right LAN/WAN groups. Tested successfully on the Itian Square One SQ201 and the SL93512 reference design with the Vitesse DSA switches. As discussed on the mailing list, these switches are untagged (DSA_TAG_PROTO_NONE) so the DSA slave devices are only slave devices with not datapath control. This means each of the CPU-facing interfaces need to be brought up with the "none" protocol before any slave devices are brought up. (The sequence matters here.) Tested on each of the three affected devices. Cc: Pawel Dembicki <paweldembicki@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> --- ChangeLog v1->v2: - Remove the eth1 from the LAN bridge in both the Vitesse switch devices, instead bring up each ethernet master interface independently with "none" protocol. --- .../gemini/base-files/etc/board.d/02_network | 27 +++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100755 target/linux/gemini/base-files/etc/board.d/02_network