Re: [OpenWrt-Devel] [PATCH] gemini: Bring up DSA switches
Hi Linus, I work with P2020RDB and I stucked at the same problem. On 14.07.2019 12:04, Linus Walleij wrote: On Sat, Jul 13, 2019 at 10:38 PM Florian Fainelli wrote: I really tried to figure out a way to get both the Vitesse and Realtek switches to do internal tagging but they just don't. I'm afraid, that You have right. The Vitesse switches can do VLAN but I just haven't implemented it yet, but now that Adrian is using it on a Freescale board as well I might get to it as we have some more users. I plan to make support for VLAN filtering for this switch. Maybe we can work together? There are some patches to the kernel do do port separation using only VLAN (by Vladimir Oltean) but of course I have to implement VLAN first if I want to try to use that. I see three possible solutions for port separation after VLAN support: 1. Use this only: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/dsa/configuration.rst#n211 2. Use 8021q tag based solution. 3. Use tag_8021q tag based solution and try to use VLAN_KEEP_TAG_ENA for dual vlan tagging. Best Regards, Pawel Dembicki ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] gemini: Bring up DSA switches
On Sat, Jul 13, 2019 at 10:38 PM Florian Fainelli wrote:
> drivers/net/dsa/vitesse-vsc73xx.c returns DSA_TAG_PROTO_NONE for the
> tagging protocol, which means that the DSA slave devices are only
> control devices they are not used by the data-path (which requires an
> appropriate tagging protocol to allow differentiating the Ethernet
> frames on a per-port basis). If you supported a different tagging
> protocol, then you would not be able to enslave the DSA master device
> (eth1) into the bridge, because that would conflict with the bridge's
> rx_handler, see 8db0a2ee2c6302a1dcbcdb93cb731dfc6c0cdb5e ("net: bridge:
> reject DSA-enabled master netdevices as bridge members")
Ah it's because of this! I try to figure it out. Thanks Florian!
I really tried to figure out a way to get both the Vitesse and Realtek
switches to do internal tagging but they just don't.
The Vitesse switches can do VLAN but I just haven't implemented
it yet, but now that Adrian is using it on a Freescale board as well
I might get to it as we have some more users.
There are some patches to the kernel do do port separation using
only VLAN (by Vladimir Oltean) but of course I have to implement
VLAN first if I want to try to use that.
> Your second sequence is more in line with what you should do, see the
> recent documentation examples from Benedikt:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/dsa/configuration.rst
Oh that is really good documentation. I linked it in the Ethernet switch
page in the OpenWrt wiki.
Yours,
Linus Walleij
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] gemini: Bring up DSA switches
On 7/13/2019 4:04 AM, Linus Walleij wrote:
> On Fri, Jul 12, 2019 at 8:57 AM Hauke Mehrtens wrote:
>> On 7/12/19 8:07 AM, Linus Walleij wrote:
>
>>> + # These are all connected to eth1 thru VSC7385
>>> + ucidef_set_interfaces_lan_wan "eth1 lan1 lan2 lan3 lan4" "eth0"
>>
>> This will create a bridge over eth1, lan1, lan2, lan3 and lan4, but I
>> think you do not have to put eth1 into this bridge, it should be
>> sufficient to have all the lanX in it.
>
> It is really puzzling to me too :(
drivers/net/dsa/vitesse-vsc73xx.c returns DSA_TAG_PROTO_NONE for the
tagging protocol, which means that the DSA slave devices are only
control devices they are not used by the data-path (which requires an
appropriate tagging protocol to allow differentiating the Ethernet
frames on a per-port basis). If you supported a different tagging
protocol, then you would not be able to enslave the DSA master device
(eth1) into the bridge, because that would conflict with the bridge's
rx_handler, see 8db0a2ee2c6302a1dcbcdb93cb731dfc6c0cdb5e ("net: bridge:
reject DSA-enabled master netdevices as bridge members")
Your second sequence is more in line with what you should do, see the
recent documentation examples from Benedikt:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/dsa/configuration.rst
>
> What I notice is that if I do this everything works fine and if eth1
> is not included it doesn't.
>
> This sequence also works fine:
> ifconfig eth1 169.254.1.2 netmask 255.255.255.0 up
> ifconfig lan1 up
> ifconfig lan2 up
> ifconfig lan3 up
> ifconfig lan4 up
>
> I think the reason is that the IP address is not assigned to
> eth1 (the CPU port towards the switch/DSA).
>
> Maybe other DSA switches are better with this? My dmesg
> looks like this with eth1 included in the lan-facing interfaces:
>
> [ 52.704396] gemini-ethernet-port 6000c000.ethernet-port eth1: link
> flow control: both
> [ 53.046012] br-lan: port 1(eth1) entered blocking state
> [ 53.170160] br-lan: port 1(eth1) entered disabled state
> [ 53.253455] device eth1 entered promiscuous mode
> [ 53.299150] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
> [ 53.388545] vsc73xx spi0.0: enable port 0
> [ 53.446029] vsc73xx spi0.0 lan1: configuring for phy/gmii link mode
> [ 53.526483] br-lan: port 2(lan1) entered blocking state
> [ 53.594789] br-lan: port 2(lan1) entered disabled state
> [ 53.665816] device lan1 entered promiscuous mode
> [ 53.728728] br-lan: port 1(eth1) entered blocking state
> [ 53.760176] br-lan: port 1(eth1) entered forwarding state
> [ 53.874449] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
> [ 54.000353] vsc73xx spi0.0: enable port 1
> [ 54.056099] vsc73xx spi0.0 lan2: configuring for phy/gmii link mode
> [ 54.142223] br-lan: port 3(lan2) entered blocking state
> [ 54.214679] br-lan: port 3(lan2) entered disabled state
> [ 54.266496] device lan2 entered promiscuous mode
> [ 54.308593] vsc73xx spi0.0: enable port 2
> [ 54.335298] vsc73xx spi0.0 lan3: configuring for phy/gmii link mode
> [ 54.377279] br-lan: port 4(lan3) entered blocking state
> [ 54.97] br-lan: port 4(lan3) entered disabled state
> [ 54.515791] device lan3 entered promiscuous mode
> [ 54.588687] vsc73xx spi0.0: enable port 3
> [ 54.646048] vsc73xx spi0.0 lan4: configuring for phy/gmii link mode
> [ 54.726991] br-lan: port 5(lan4) entered blocking state
> [ 54.785910] vsc73xx spi0.0 lan1: Link is Up - 1Gbps/Full - flow control
> rx/tx
> [ 54.844478] br-lan: port 5(lan4) entered disabled state
> [ 54.915911] device lan4 entered promiscuous mode
> [ 54.976533] br-lan: port 2(lan1) entered blocking state
> [ 55.007954] br-lan: port 2(lan1) entered forwarding state
>
> After this I can ping the host:
> # ping 169.254.1.1
> PING 169.254.1.1 (169.254.1.1): 56 data bytes
> 64 bytes from 169.254.1.1: seq=0 ttl=64 time=2.049 ms
> 64 bytes from 169.254.1.1: seq=6 ttl=64 time=0.913 ms
> 64 bytes from 169.254.1.1: seq=25 ttl=64 time=1.268 ms
> And the host can ping the device:
> $ ping 169.254.1.2
> PING 169.254.1.2 (169.254.1.2) 56(84) bytes of data.
> 64 bytes from 169.254.1.2: icmp_seq=1 ttl=64 time=1.12 ms
> 64 bytes from 169.254.1.2: icmp_seq=2 ttl=64 time=0.582 ms
> 64 bytes from 169.254.1.2: icmp_seq=3 ttl=64 time=0.576 ms
> 64 bytes from 169.254.1.2: icmp_seq=4 ttl=64 time=0.654 ms
>
> But if I remove eth1 from the LAN facing interfaces it looks like
> this:
>
> [ 52.433253] gemini-ethernet-port 6000c000.ethernet-port eth1: link
> flow control: both
> [ 52.769503] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
> [ 52.925178] device eth1 entered promiscuous mode
> [ 52.987672] vsc73xx spi0.0: enable port 0
> [ 53.014460] vsc73xx spi0.0 lan1: configuring for phy/gmii link mode
> [ 53.054754] br-lan: port 1(lan1) entered blocking state
> [ 53.086323] br-lan: port 1(lan1) entered disabled state
> [ 53.119857] device lan1 enter
Re: [OpenWrt-Devel] [PATCH] gemini: Bring up DSA switches
On 13/07/2019 13:04, Linus Walleij wrote: On Fri, Jul 12, 2019 at 8:57 AM Hauke Mehrtens wrote: On 7/12/19 8:07 AM, Linus Walleij wrote: + # These are all connected to eth1 thru VSC7385 + ucidef_set_interfaces_lan_wan "eth1 lan1 lan2 lan3 lan4" "eth0" This will create a bridge over eth1, lan1, lan2, lan3 and lan4, but I think you do not have to put eth1 into this bridge, it should be sufficient to have all the lanX in it. It is really puzzling to me too :( What I notice is that if I do this everything works fine and if eth1 is not included it doesn't. This sequence also works fine: ifconfig eth1 169.254.1.2 netmask 255.255.255.0 up ifconfig lan1 up ifconfig lan2 up ifconfig lan3 up ifconfig lan4 up I think the reason is that the IP address is not assigned to eth1 (the CPU port towards the switch/DSA). Maybe other DSA switches are better with this? My dmesg looks like this with eth1 included in the lan-facing interfaces: Hi Linus, I recall while bringing up QCA8k that the underlying physical ethernet needs to be up and have a valid mac addr otherwise the unicast filter of the mac ip block would drop traffic. long shot guess, the mac of eth1 probably implictly brings up the uni cast filter when you set an IP. try just doing an ifconfig up and setting the same mac as the switchdev ports. John [ 52.704396] gemini-ethernet-port 6000c000.ethernet-port eth1: link flow control: both [ 53.046012] br-lan: port 1(eth1) entered blocking state [ 53.170160] br-lan: port 1(eth1) entered disabled state [ 53.253455] device eth1 entered promiscuous mode [ 53.299150] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready [ 53.388545] vsc73xx spi0.0: enable port 0 [ 53.446029] vsc73xx spi0.0 lan1: configuring for phy/gmii link mode [ 53.526483] br-lan: port 2(lan1) entered blocking state [ 53.594789] br-lan: port 2(lan1) entered disabled state [ 53.665816] device lan1 entered promiscuous mode [ 53.728728] br-lan: port 1(eth1) entered blocking state [ 53.760176] br-lan: port 1(eth1) entered forwarding state [ 53.874449] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready [ 54.000353] vsc73xx spi0.0: enable port 1 [ 54.056099] vsc73xx spi0.0 lan2: configuring for phy/gmii link mode [ 54.142223] br-lan: port 3(lan2) entered blocking state [ 54.214679] br-lan: port 3(lan2) entered disabled state [ 54.266496] device lan2 entered promiscuous mode [ 54.308593] vsc73xx spi0.0: enable port 2 [ 54.335298] vsc73xx spi0.0 lan3: configuring for phy/gmii link mode [ 54.377279] br-lan: port 4(lan3) entered blocking state [ 54.97] br-lan: port 4(lan3) entered disabled state [ 54.515791] device lan3 entered promiscuous mode [ 54.588687] vsc73xx spi0.0: enable port 3 [ 54.646048] vsc73xx spi0.0 lan4: configuring for phy/gmii link mode [ 54.726991] br-lan: port 5(lan4) entered blocking state [ 54.785910] vsc73xx spi0.0 lan1: Link is Up - 1Gbps/Full - flow control rx/tx [ 54.844478] br-lan: port 5(lan4) entered disabled state [ 54.915911] device lan4 entered promiscuous mode [ 54.976533] br-lan: port 2(lan1) entered blocking state [ 55.007954] br-lan: port 2(lan1) entered forwarding state After this I can ping the host: # ping 169.254.1.1 PING 169.254.1.1 (169.254.1.1): 56 data bytes 64 bytes from 169.254.1.1: seq=0 ttl=64 time=2.049 ms 64 bytes from 169.254.1.1: seq=6 ttl=64 time=0.913 ms 64 bytes from 169.254.1.1: seq=25 ttl=64 time=1.268 ms And the host can ping the device: $ ping 169.254.1.2 PING 169.254.1.2 (169.254.1.2) 56(84) bytes of data. 64 bytes from 169.254.1.2: icmp_seq=1 ttl=64 time=1.12 ms 64 bytes from 169.254.1.2: icmp_seq=2 ttl=64 time=0.582 ms 64 bytes from 169.254.1.2: icmp_seq=3 ttl=64 time=0.576 ms 64 bytes from 169.254.1.2: icmp_seq=4 ttl=64 time=0.654 ms But if I remove eth1 from the LAN facing interfaces it looks like this: [ 52.433253] gemini-ethernet-port 6000c000.ethernet-port eth1: link flow control: both [ 52.769503] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready [ 52.925178] device eth1 entered promiscuous mode [ 52.987672] vsc73xx spi0.0: enable port 0 [ 53.014460] vsc73xx spi0.0 lan1: configuring for phy/gmii link mode [ 53.054754] br-lan: port 1(lan1) entered blocking state [ 53.086323] br-lan: port 1(lan1) entered disabled state [ 53.119857] device lan1 entered promiscuous mode [ 53.160541] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready [ 53.250938] vsc73xx spi0.0: enable port 1 [ 53.309220] vsc73xx spi0.0 lan2: configuring for phy/gmii link mode [ 53.394269] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 53.476271] br-lan: port 2(lan2) entered blocking state [ 53.543459] br-lan: port 2(lan2) entered disabled state [ 53.604655] device lan2 entered promiscuous mode [ 53.686932] vsc73xx spi0.0: enable port 2 [ 53.744974] vsc73xx spi0.0 lan3: configuring for phy/gmii link mode [ 53.820229] br-lan: port 3(lan3) entered blocking state [ 53.893505] br
Re: [OpenWrt-Devel] [PATCH] gemini: Bring up DSA switches
On Fri, Jul 12, 2019 at 8:57 AM Hauke Mehrtens wrote: > On 7/12/19 8:07 AM, Linus Walleij wrote: > > + # These are all connected to eth1 thru VSC7385 > > + ucidef_set_interfaces_lan_wan "eth1 lan1 lan2 lan3 lan4" "eth0" > > This will create a bridge over eth1, lan1, lan2, lan3 and lan4, but I > think you do not have to put eth1 into this bridge, it should be > sufficient to have all the lanX in it. It is really puzzling to me too :( What I notice is that if I do this everything works fine and if eth1 is not included it doesn't. This sequence also works fine: ifconfig eth1 169.254.1.2 netmask 255.255.255.0 up ifconfig lan1 up ifconfig lan2 up ifconfig lan3 up ifconfig lan4 up I think the reason is that the IP address is not assigned to eth1 (the CPU port towards the switch/DSA). Maybe other DSA switches are better with this? My dmesg looks like this with eth1 included in the lan-facing interfaces: [ 52.704396] gemini-ethernet-port 6000c000.ethernet-port eth1: link flow control: both [ 53.046012] br-lan: port 1(eth1) entered blocking state [ 53.170160] br-lan: port 1(eth1) entered disabled state [ 53.253455] device eth1 entered promiscuous mode [ 53.299150] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready [ 53.388545] vsc73xx spi0.0: enable port 0 [ 53.446029] vsc73xx spi0.0 lan1: configuring for phy/gmii link mode [ 53.526483] br-lan: port 2(lan1) entered blocking state [ 53.594789] br-lan: port 2(lan1) entered disabled state [ 53.665816] device lan1 entered promiscuous mode [ 53.728728] br-lan: port 1(eth1) entered blocking state [ 53.760176] br-lan: port 1(eth1) entered forwarding state [ 53.874449] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready [ 54.000353] vsc73xx spi0.0: enable port 1 [ 54.056099] vsc73xx spi0.0 lan2: configuring for phy/gmii link mode [ 54.142223] br-lan: port 3(lan2) entered blocking state [ 54.214679] br-lan: port 3(lan2) entered disabled state [ 54.266496] device lan2 entered promiscuous mode [ 54.308593] vsc73xx spi0.0: enable port 2 [ 54.335298] vsc73xx spi0.0 lan3: configuring for phy/gmii link mode [ 54.377279] br-lan: port 4(lan3) entered blocking state [ 54.97] br-lan: port 4(lan3) entered disabled state [ 54.515791] device lan3 entered promiscuous mode [ 54.588687] vsc73xx spi0.0: enable port 3 [ 54.646048] vsc73xx spi0.0 lan4: configuring for phy/gmii link mode [ 54.726991] br-lan: port 5(lan4) entered blocking state [ 54.785910] vsc73xx spi0.0 lan1: Link is Up - 1Gbps/Full - flow control rx/tx [ 54.844478] br-lan: port 5(lan4) entered disabled state [ 54.915911] device lan4 entered promiscuous mode [ 54.976533] br-lan: port 2(lan1) entered blocking state [ 55.007954] br-lan: port 2(lan1) entered forwarding state After this I can ping the host: # ping 169.254.1.1 PING 169.254.1.1 (169.254.1.1): 56 data bytes 64 bytes from 169.254.1.1: seq=0 ttl=64 time=2.049 ms 64 bytes from 169.254.1.1: seq=6 ttl=64 time=0.913 ms 64 bytes from 169.254.1.1: seq=25 ttl=64 time=1.268 ms And the host can ping the device: $ ping 169.254.1.2 PING 169.254.1.2 (169.254.1.2) 56(84) bytes of data. 64 bytes from 169.254.1.2: icmp_seq=1 ttl=64 time=1.12 ms 64 bytes from 169.254.1.2: icmp_seq=2 ttl=64 time=0.582 ms 64 bytes from 169.254.1.2: icmp_seq=3 ttl=64 time=0.576 ms 64 bytes from 169.254.1.2: icmp_seq=4 ttl=64 time=0.654 ms But if I remove eth1 from the LAN facing interfaces it looks like this: [ 52.433253] gemini-ethernet-port 6000c000.ethernet-port eth1: link flow control: both [ 52.769503] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready [ 52.925178] device eth1 entered promiscuous mode [ 52.987672] vsc73xx spi0.0: enable port 0 [ 53.014460] vsc73xx spi0.0 lan1: configuring for phy/gmii link mode [ 53.054754] br-lan: port 1(lan1) entered blocking state [ 53.086323] br-lan: port 1(lan1) entered disabled state [ 53.119857] device lan1 entered promiscuous mode [ 53.160541] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready [ 53.250938] vsc73xx spi0.0: enable port 1 [ 53.309220] vsc73xx spi0.0 lan2: configuring for phy/gmii link mode [ 53.394269] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 53.476271] br-lan: port 2(lan2) entered blocking state [ 53.543459] br-lan: port 2(lan2) entered disabled state [ 53.604655] device lan2 entered promiscuous mode [ 53.686932] vsc73xx spi0.0: enable port 2 [ 53.744974] vsc73xx spi0.0 lan3: configuring for phy/gmii link mode [ 53.820229] br-lan: port 3(lan3) entered blocking state [ 53.893505] br-lan: port 3(lan3) entered disabled state [ 53.964682] device lan3 entered promiscuous mode [ 54.047383] vsc73xx spi0.0: enable port 3 [ 54.087228] vsc73xx spi0.0 lan4: configuring for phy/gmii link mode [ 54.128009] br-lan: port 4(lan4) entered blocking state [ 54.160537] br-lan: port 4(lan4) entered disabled state [ 54.194726] device lan4 entered promiscuous mode [ 54.284743] vsc73xx spi0.0 lan1: Link i
Re: [OpenWrt-Devel] [PATCH] gemini: Bring up DSA switches
On 7/12/19 8:07 AM, Linus Walleij wrote: > 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. > > The RTL8366RB on the DIR-685 is still under development > but this setup is a starting point but since the WAN > and the LAN ports share the same ethernet CPU port > the ethernet port should not be part of either WAN or > LAN. > > Signed-off-by: Linus Walleij > --- > .../gemini/base-files/etc/board.d/02_network | 25 +++ > 1 file changed, 25 insertions(+) > create mode 100755 target/linux/gemini/base-files/etc/board.d/02_network > > 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 ..87f888e92c28 > --- /dev/null > +++ b/target/linux/gemini/base-files/etc/board.d/02_network > @@ -0,0 +1,25 @@ > +#!/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_interfaces_lan_wan "eth1 lan1 lan2 lan3 lan4" "eth0" This will create a bridge over eth1, lan1, lan2, lan3 and lan4, but I think you do not have to put eth1 into this bridge, it should be sufficient to have all the lanX in it. > + ;; > +itian,sq201) > + # These are all connected to eth1 thru VSC7395 > + ucidef_set_interfaces_lan_wan "eth1 lan1 lan2 lan3 lan4" "eth0" > + ;; > +dlink,dir-685) > + # These are all connected to eth0 thru RTL8366RB > + ucidef_set_interface "eth" ifname "eth0" protocol "none" I think this is not needed. > + ucidef_set_interfaces_lan_wan "lan0 lan1 lan2 lan3" "wan" > + ;; > +esac > + > +board_config_flush > + > +exit 0 > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] gemini: Bring up DSA switches
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. The RTL8366RB on the DIR-685 is still under development but this setup is a starting point but since the WAN and the LAN ports share the same ethernet CPU port the ethernet port should not be part of either WAN or LAN. Signed-off-by: Linus Walleij --- .../gemini/base-files/etc/board.d/02_network | 25 +++ 1 file changed, 25 insertions(+) create mode 100755 target/linux/gemini/base-files/etc/board.d/02_network 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 ..87f888e92c28 --- /dev/null +++ b/target/linux/gemini/base-files/etc/board.d/02_network @@ -0,0 +1,25 @@ +#!/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_interfaces_lan_wan "eth1 lan1 lan2 lan3 lan4" "eth0" + ;; +itian,sq201) + # These are all connected to eth1 thru VSC7395 + ucidef_set_interfaces_lan_wan "eth1 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 -- 2.21.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
