82

https://bugs.openwrt.org/index.php?do=details&task_id=2317
I just found a bug of marvell DSA driver that may affect IPv6 connection..
@Ansuel @ParanoidZoid @shm0

83

this should be reported to kernel guys dsa is directly from kernel

1 Like
84

Actually I could really use the config file and a screenshot of "swconfig Dev switch0 show" I believe

Really? I have IPv6 and I have no issues with it, what happens? I read but couldn't really understand :sweat_smile::sweat_smile::sweat_smile:

85

the problems looks related to relay configuration (so ipv6 packet forward is broken in dsa? )

86

Since NDP is multicast, I think there is something wrong with multicast switching.
tcpdump does not help with debugging here because it can only capture packets that are being sent to CPU, which is a downside of DSA
And in my case I have set LAN and WAN to same MAC address, don't know if it matters

87

I wonder if anyone here could reproduce this as well..

88

Well, the day I bought my router I flashed OpenWRT I couldn't get IPv6, and I couldn't find out why, but, one day, somehow from nowhere it started working, now, I don't know if that's the same issue, but it may help, check the logs to see if there's any message from "odhcp6c".
Also I have the latest trunk of OpenWRT installed with DSA enabled and have no issues.

On another note @ParanoidZoid I can only build a transition script for a standard interface configuration, cause other user configuration is really hard to predict, is that ok? don't you think they'll accept your patch upstream without a transition script?

90

I'll have a look. The only other use cases I can really think of are assigning one vlan per switch interface.

And yes, a script will be needed.

91

I've said the problem is probably with DSA and not odhcpd

+----------------------+                       +----------------------------------------------+
|                      |                       |                                              |
|  Gateway, RA server  +-----------------------> wan 2001:db8::<eui64>/64 (SLAAC)             |
|                      |                       |   ^        Router with 88E6176 and DSA driver|
| (WITH MAC WHITELIST) |                       |   |                                          |
|                      |                       |   | odhcpd relays NDP between wan and br-lan |
|   2001:db8::1/64     |                       |   v                                          |
|                      |                       |   lan1(br-lan)            wlan0(br-lan)      |
+----------------------+                       +--------+------------------------+------------+
                                                        |                        |
                                                        |                        |
                                                        |                        |
                                                        v                        v
                                                     Client 1                 Client 2

MAC address of WAN and LAN are the same
Try pinging 2001:db8::1 from client 1, about 10s later IPv6 connection of client 1 will break.
Try pinging 2001:db8::1 from client 2, nothing happens.
ifup lan temporarily solves this issue, probably because it resets the switch.

I don't have the access to the gateway server so I don't know if some packets are "leaked" to wan

92

Imagine, for example, the default configuration is wan connected to the interface wan and lan1-4 connected to the lan interface, but once even I changed my setup, for example I set wan, lan1 and lan2 to the wan interface (as a bridge) and lan to lan3 and lan4, and for those setups like the example I gave I can't predict what people have, I hope you get me ahahah

Ok, I'll do one for the default config.

ok I see what you mean, can't it be a bug of openwrt itself ? also, are you using the latest trunk? and with which kernel version?

93

On another note, since the mvebu devicetree was bumped to 4.19 can you build a patch for the new kernel version @ParanoidZoid ?
Thanks!

94

Seems like it just needs slight modification to the patches and the kconfig. I'll see what I can do when I have the free time.

95

Ok, it seems harder than that, I've applied the changes you made last time to the new patches and it ends up in a bootloop, I wanted to see the other system's logs but don't know how to do it :sweat_smile::sweat_smile::sweat_smile:
Have you had any luck?

96

I tried the DSA patch again with WAN MAC modified, now IPv6 connection does not break anymore :slight_smile:

97

Can you show me the commit you used?

98

Ok, some news, just found out what the bootloop was, apparently if I create a bridge wan to lan1 (or other) the device crashes. Should I submit a bug report?

100

Ok got some news, I managed to make my own branch and make the changes necessary to the openwrt 4.19 kernel, but there are some issues.
If I connect a port with vlan for example "wan.12" to a interface the kernel gives an error and reverts back to the old config (sometimes, there were many times the system just started to bootloop).
Is this a Openwrt error or a kernel bug?
Also bridges between vlans don't work as traffic doesn't go through. Can someone with a Turris Omnia say if they have some of these Issues?

101

Something to report.
Some days ago i switched back to swconfig + tx queue patch applied again.
I noticed that my lan <--> wan speed was limited to ~150 Mbit/s.
cake was attached to eth0 interface (lan ports).
Switched that back to openwrt default mq + 8 fq_codel instances.
Speed went up to 250 Mbit/s.
But still not reaching full wan speed (400 Mbit/s).
Switched back to dsa and tx queue patch removed.
I now get full wan speed again.
//edit
Okay after some testing.
Seems like tx queue work around patch is still needed.
Without the patch almost all the time uploads starve but not every time.
Changing the RPS/XPS settings also seem to trigger the upload starving behavior.

102

I updated the patch for kernel 4.19

Tested and looks ok... if someone want to transition from swconfig to dsa just add lan1 lan2 lan3 lan4 to br-lan and you are good to go...

(the ip changes in other patch are not needed since i updated the blogic patch to use the mac address on slave port)

diff --git a/target/linux/mvebu/base-files/etc/board.d/02_network b/target/linux/mvebu/base-files/etc/board.d/02_network
index 7acbe4bf62..b530d998fd 100755
--- a/target/linux/mvebu/base-files/etc/board.d/02_network
+++ b/target/linux/mvebu/base-files/etc/board.d/02_network
@@ -23,10 +23,13 @@ globalscale,espressobin-v7-emmc)
 	;;
 linksys,caiman|\
 linksys,cobra|\
-linksys,mamba|\
 linksys,rango|\
 linksys,shelby|\
 linksys,venom)
+	ucidef_set_interface_lan "lan1 lan2 lan3 lan4"
+	ucidef_set_interface_wan "wan"
+	;;
+linksys,mamba)
 	ucidef_set_interfaces_lan_wan "eth0.1" "eth1.2"
 	ucidef_add_switch "switch0" \
 		"0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "5@eth0" "4:wan" "6@eth1"
diff --git a/target/linux/mvebu/patches-4.19/003-add_switch_nodes.patch b/target/linux/mvebu/patches-4.19/003-add_switch_nodes.patch
deleted file mode 100644
index b208638916..0000000000
--- a/target/linux/mvebu/patches-4.19/003-add_switch_nodes.patch
+++ /dev/null
@@ -1,40 +0,0 @@
---- a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
-+++ b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
-@@ -257,6 +257,16 @@
- 			};
- 		};
- 	};
-+
-+	mvsw61xx {
-+		compatible = "marvell,88e6172";
-+		status = "okay";
-+		reg = <0x10>;
-+
-+		mii-bus = <&mdio>;
-+		cpu-port-0 = <5>;
-+		cpu-port-1 = <6>;
-+	};
- };
- 
- &pciec {
---- a/arch/arm/boot/dts/armada-385-linksys.dtsi
-+++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
-@@ -82,6 +82,18 @@
- 			linux,default-trigger = "disk-activity";
- 		};
- 	};
-+
-+	mvsw61xx {
-+		#address-cells = <1>;
-+		#size-cells = <0>;
-+		compatible = "marvell,88e6176";
-+		status = "okay";
-+		reg = <0x10>;
-+
-+		mii-bus = <&mdio>;
-+		cpu-port-0 = <5>;
-+		cpu-port-1 = <6>;
-+	};
- };
- 
- &ahci0 {
diff --git a/target/linux/mvebu/patches-4.19/075-dsa-inherit-parent-mac.patch b/target/linux/mvebu/patches-4.19/075-dsa-inherit-parent-mac.patch
new file mode 100644
index 0000000000..7169b2d114
--- /dev/null
+++ b/target/linux/mvebu/patches-4.19/075-dsa-inherit-parent-mac.patch
@@ -0,0 +1,39 @@
+From 171b14b660f35f593748ac62bbdbb43ace2c582d Mon Sep 17 00:00:00 2001
+From: John Crispin <john@phrozen.org>
+Date: Tue, 1 Nov 2016 01:44:15 +0100
+Subject: [PATCH 10/22] net: dsa: make the slave device inheret the MAC of the
+ parent
+
+This patch makes all slave devices inherit the parent devices MAC.
+
+Signed-off-by: John Crispin <john@phrozen.org>
+---
+ net/dsa/slave.c |   11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/net/dsa/slave.c
++++ b/net/dsa/slave.c
+@@ -151,6 +151,15 @@ static int dsa_slave_close(struct net_de
+ 	return 0;
+ }
+ 
++static int dsa_slave_init(struct net_device *dev)
++{
++	struct net_device *master =  dsa_slave_to_master(dev);
++	struct sockaddr sa;
++
++	ether_addr_copy(sa.sa_data, master->dev_addr);
++	return eth_mac_addr(dev, &sa);
++}
++
+ static void dsa_slave_change_rx_flags(struct net_device *dev, int change)
+ {
+ 	struct dsa_slave_priv *p = netdev_priv(dev);
+@@ -1036,6 +1046,7 @@ static const struct ethtool_ops dsa_slav
+ static const struct net_device_ops dsa_slave_netdev_ops = {
+ 	.ndo_open	 	= dsa_slave_open,
+ 	.ndo_stop		= dsa_slave_close,
++	.ndo_init		= dsa_slave_init,
+ 	.ndo_start_xmit		= dsa_slave_xmit,
+ 	.ndo_change_rx_flags	= dsa_slave_change_rx_flags,
+ 	.ndo_set_rx_mode	= dsa_slave_set_rx_mode,
diff --git a/target/linux/mvebu/patches-4.19/220-disable-untested-dsa-boards.patch b/target/linux/mvebu/patches-4.19/220-disable-untested-dsa-boards.patch
index 9cc7a113f6..a51c0bb512 100644
--- a/target/linux/mvebu/patches-4.19/220-disable-untested-dsa-boards.patch
+++ b/target/linux/mvebu/patches-4.19/220-disable-untested-dsa-boards.patch
@@ -1,13 +1,3 @@
---- a/arch/arm/boot/dts/armada-385-linksys.dtsi
-+++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
-@@ -171,6 +171,7 @@
- 	status = "okay";
- 
- 	switch@0 {
-+		status = "disabled";
- 		compatible = "marvell,mv88e6085";
- 		#address-cells = <1>;
- 		#size-cells = <0>;
 --- a/arch/arm/boot/dts/armada-388-clearfog.dts
 +++ b/arch/arm/boot/dts/armada-388-clearfog.dts
 @@ -161,6 +161,7 @@
103

Haven't you noticed the issues I mentioned?