hi please test the configs on the native interfaces also, i’ve done a lot of testing last few days. Its not possible to have 2 nic’s up at the same time, if you start traffic over one of the interfaces. connection will die. strange thing is, i have a /22 network. my bpi-r2 has 172.16.203.1/22, i can ping to a device directly attached to the same switch at ip 172.16.202.1/22. but when i ping the router at 172.16.200.1/22, my connection is lost…and the nic only see’s broadcast packets…
I guess i will not find time for this till end of year 
You can ping r2,but if you ping from r2 connection dies with more than 1 device?
i tried not changing the mac address an then both interfaces died. If i change one mac address, only 1 interface dies then.
yes, to r2 is ok, from r2 is ok to device on same switch, when pinging device to other switch. it dies…
so im sure its MAC / ARP related
i tried to reproduce on r64, but i got crash after enabling vlan-support, was related to load kernel from tftp with local modules 
vlan on r64 5.4 with dsa-driver does also not work, but seems not breaking anything
both switchports are set to trunk-mode allowing untagged (vlan1) and tagged vlan 500 (my vlan i try to realize)
i made some tests on lan1 with kernel 5.4-main and vlan (lan0 still connected to my lan working all the time).
may basic setup on r2:
root@bpi-r2:~# ip addr show lan1
6: lan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether e6:b1:a0:07:db:91 brd ff:ff:ff:ff:ff:ff
inet 192.168.20.2/24 scope global lan1
valid_lft forever preferred_lft forever
inet6 fe80::e4b1:a0ff:fe07:db91/64 scope link
valid_lft forever preferred_lft forever
root@bpi-r2:~# ip addr show vlan500
9: vlan500@lan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 02:01:02:13:04:18 brd ff:ff:ff:ff:ff:ff
inet 192.168.50.10/24 scope global vlan500
valid_lft forever preferred_lft forever
inet6 fe80::1:2ff:fe13:418/64 scope link
valid_lft forever preferred_lft forever
directly connected (without switch) my client with ip-adress 192.168.20.1/24 untagged and 192.168.50.1/24 vlan500
untagged is working so far
vlan is a bit strange:
- if i ping from R2 i see on r2 only ARP Requests (and icmp outgoing), but no reply (good so far), the other side look strange: i see the arp request on main interface (not the vlan) and so no reply is sent
- if i ping from client, i see on r2 ARP request (both interfaces = full broadcast) and reply only on main interface
conclusion: outgoing vlan-traffic (from r2) seems not to be tagged! incoming seems to work
wan seems not working directly connected to client in my last test (tested without vlan)…i see up-message on r2, but no carrier on my client (tried different cables, also crosslink, because i don not know if mdix is supported…at least i canoot set it via ethtool).
if i connect wan to my switch (and need reboot) i can ping my main-router after moving ip-adress to wan (from lan0 set by interfaces-file)
i reverted my change routing wan to second gmac and now it works like the lan-ports…but also no tagged frames from r2 to client
have verified with kernel 4.14, that both devices support vlan and my setup is right (don not need to set separate mac-adress because it’s other lan-segment)
it looks like on 4.16 wan was completely broken (no carrier without gmac-patches), lan0 works
on 4.18, wan works again, but vlan-issue ist already there
on 4.15 vlan was still working…so vlan is broken between 4.15 and 4.18, as wan does completely not works in 4.16 i guess it’s introduced there, on 4.17 wan is still broken.
as far as i see between 4.15 and 4.16 then bridge vlan_filtering was added
mt7530_415-416.diff (14,1 KB)
something here breaks wan and vlan-handling (maybe because tag is only added if vlan is set on bridge)
mt7530_415-418.diff (15,7 KB)
between 4.16 and 4.18 (something is happen to let wan work again, but without vlan) only some 0 => NULL and stringset changes are done in the mt7530 driver
after a new test in 4.18, wan was not working ;(
comparing with 4.19-without2ndgmac (where wan works) i’ve found only this dts-changes:
switch@0 {
compatible = "mediatek,mt7530";
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0>;
- pinctrl-names = "default";
reset-gpios = <&pio 33 0>;
core-supply = <&mt6323_vpa_reg>;
io-supply = <&mt6323_vemc3v3_reg>;
@@ -171,7 +220,6 @@
ports {
#address-cells = <1>;
#size-cells = <0>;
- reg = <0>;
port@0 {
reg = <0>;
i guess reg=<0> in ports breaks wan-port…removed it and now it works 
and it is proofed, that vlan-issue begins with 4.16
root@bpi-r2:~# ip link add link wan name vlan500 type vlan id 500
root@bpi-r2:~# ip addr add 192.168.50.10/24 dev vlan500
root@bpi-r2:~# ip link set vlan500 up
which brings me to this commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=83163f7dca5684816d01c8ccf4857aa74801e7b7
tried reverting it, but this seems not enough…vlan still not working. else only module_alias/Module_device_table is changed in mt7530 driver
so i guess there are some core-net changes which break vlan…but hard to find
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=80e023607982faa6245507c45acf93bb0feb0ded may be also related, but this i cannot revert so easily it seems to depend on another Patch in switch.c, reverted all changes in drivers/net/dsa to state of 4.15, but vlan still not working…so something in net-core is changed
@ryder.lee @moore @linkerosa has something changed with vlan-handling with 4.16, which requires only a additional config-option? or is there any change which breaks vlan-handling without bridge?
Friends
I have similar problem and I don’t want create a new thread. Basically all works when interfaces are plugged to different hubs - if at least two of them are plugged to the same hub they stop to work and the Banana needs to be rebooted.
What is worse if the wan interface and at least one one of lan interfaces are plugged to the same hub they stop to work , although they use separate GMACs.
Can you confirm ? … This is simple case, no dhcp, no vlan, just two IP networks on two interfaces. Once separate works - once connected to the same hub stops.
root@bpi-r2:~# cat /etc/debian_ver*
9.11
root@bpi-r2:~# uname -r
4.14.80-bpi-r2-main
root@bpi-r2:~# cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
pre-up ip link set $IFACE up
post-down ip link set $IFACE down
auto eth1
iface eth1 inet manual
pre-up ip link set $IFACE up
post-down ip link set $IFACE down
auto wan
iface wan inet static
address 192.168.4.9
netmask 255.255.255.0
pre-up ip link set $IFACE up
post-down ip link set $IFACE down
auto lan0
iface lan0 inet static
address 10.0.253.254
netmask 255.255.255.0
pre-up ip link set $IFACE address 02:01:02:03:04:02 up
post-down ip link set $IFACE down
auto lan1
iface lan1 inet static
address 10.0.254.254
netmask 255.255.255.0
pre-up ip link set $IFACE address 02:01:02:03:04:04 up
post-down ip link set $IFACE down
auto lan2
iface lan2 inet static
address 192.168.0.9
netmask 255.255.255.0
pre-up ip link set $IFACE up
pre-up ip link set $IFACE address 02:01:02:03:04:06 up
post-down ip link set $IFACE down
auto lan3
iface lan3 inet static
address 192.168.2.19
gateway 192.168.2.254
pre-up ip link set $IFACE up
pre-up ip link set $IFACE address 02:01:02:03:04:08 up
post-down ip link set $IFACE down
source-directory /etc/network/interfaces.d
root@bpi-r2:~#
root@bpi-r2:~# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group defaul
t qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP gr
oup default qlen 1000
link/ether aa:07:2f:82:b2:04 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP gr
oup default qlen 1000
link/ether da:aa:50:13:f5:3a brd ff:ff:ff:ff:ff:ff
4: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP g
roup default qlen 1000
link/ether da:aa:50:13:f5:3a brd ff:ff:ff:ff:ff:ff
inet 192.168.4.9/24 brd 192.168.4.255 scope global wan
valid_lft forever preferred_lft forever
5: lan0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
group default qlen 1000
link/ether 02:01:02:03:04:02 brd ff:ff:ff:ff:ff:ff
inet 10.0.253.254/24 brd 10.0.253.255 scope global lan0
valid_lft forever preferred_lft forever
6: lan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
group default qlen 1000
link/ether 02:01:02:03:04:04 brd ff:ff:ff:ff:ff:ff
inet 10.0.254.254/24 brd 10.0.254.255 scope global lan1
valid_lft forever preferred_lft forever
7: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state L
OWERLAYERDOWN group default qlen 1000 #### Intentionally disconnected
link/ether 02:01:02:03:04:06 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.9/24 brd 192.168.0.255 scope global lan2
valid_lft forever preferred_lft forever
8: lan3@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
group default qlen 1000
link/ether 02:01:02:03:04:08 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.19/24 brd 192.168.2.255 scope global lan3
valid_lft forever preferred_lft foreverIt may be also an MT7530 problem. The chip is indeed a layer2 switch. I read the following in google :
Loopback Detection (LBD) provides protection against loops by transmitting loop protocol packets out of ports on which loop protection has been enabled. When the switch sends out a loop protocol packet, and then receives the same packet, it shuts down the port that received the packet.
So all our problems might be explained by this.