Re: [BUG] vlan-aware bridge breaks vlan on another port on same gmac

[Vladimir Oltean <olteanv@gmail.com>]

Hi Frank,

On Fri, Jan 20, 2023 at 05:45:35PM +0100, Frank Wunderlich wrote:
> Hi,
> 
> noticed a bug while testing systemd, but it is reproducable with iproute2
> 
> tested on bananapi-r2 with kernel 5.15.80 and bananapi-r3 with kernel 6.2-rc1,
> both use mt7530 dsa driver but different configs (mt7530 vs. mt7531).
> have no other devices to test.
> 
> first create vlan on wan-port (wan and lan0 are dsa-user-ports on same gmac)
> 
> netif=wan
> ip link set $netif up
> ip link add link $netif name vlan110 type vlan id 110
> ip link set vlan110 up
> ip addr add 192.168.110.1/24 dev vlan110
> 
> vlan works now, other side pingable, vlan-tagged packets visible in tcpdump on both sides

VLAN 110 is a software VLAN, it is never committed to hardware in the
switch.

> now create the vlan-sware bridge (without vlan_filtering it works in my test)
> 
> BRIDGE=lanbr0
> ip link add name ${BRIDGE} type bridge vlan_filtering 1 vlan_default_pvid 1
> ip link set ${BRIDGE} up
> ip link set lan0 master ${BRIDGE}
> ip link set lan0 up
> 
> takes some time before it is applied and ping got lost
> 
> packets are received by other end but without vlan-tag

What happens in mt7530_port_vlan_filtering() is that the user port (lan0)
*and* the CPU port become VLAN aware. I guess it is the change on the
CPU port that affects the traffic to "wan". But I don't see yet why this
affects the traffic in the way you mention (the CPU port strips the tag
instead of dropping packets with VLAN 110).

I have 2 random things to suggest you try.

First is this

From 2991f704e6f341bd81296e91fbb4381f528f8c7f Mon Sep 17 00:00:00 2001
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Fri, 20 Jan 2023 19:17:16 +0200
Subject: [PATCH] mt7530 don't make the CPU port a VLAN user port

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 drivers/net/dsa/mt7530.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 616b21c90d05..7265c120c767 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1524,7 +1524,7 @@ mt7530_port_vlan_filtering(struct dsa_switch *ds, int port, bool vlan_filtering,
 		 * for becoming a VLAN-aware port.
 		 */
 		mt7530_port_set_vlan_aware(ds, port);
-		mt7530_port_set_vlan_aware(ds, cpu_dp->index);
+//		mt7530_port_set_vlan_aware(ds, cpu_dp->index);
 	} else {
 		mt7530_port_set_vlan_unaware(ds, port);
 	}

If this works, I expect it will break VLAN tagged traffic over lan0 now :)
So I would then like you to remove the first patch and try the next one

From 1b6842c8fc57f6fda28db576170173f5c146e470 Mon Sep 17 00:00:00 2001
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Fri, 20 Jan 2023 19:17:51 +0200
Subject: [PATCH 2/2] tag_mtk only combine VLAN tag with MTK tag is user port
 is VLAN aware

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 net/dsa/tag_mtk.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/net/dsa/tag_mtk.c b/net/dsa/tag_mtk.c
index 40af80452747..ab027c233bee 100644
--- a/net/dsa/tag_mtk.c
+++ b/net/dsa/tag_mtk.c
@@ -35,14 +35,13 @@ static struct sk_buff *mtk_tag_xmit(struct sk_buff *skb,
 	 * the both special and VLAN tag at the same time and then look up VLAN
 	 * table with VID.
 	 */
-	switch (skb->protocol) {
-	case htons(ETH_P_8021Q):
+	if (dsa_port_is_vlan_filtering(dp) &&
+	    skb->protocol == htons(ETH_P_8021Q)) {
 		xmit_tpid = MTK_HDR_XMIT_TAGGED_TPID_8100;
-		break;
-	case htons(ETH_P_8021AD):
+	} else if (dsa_port_is_vlan_filtering(dp) &&
+		   skb->protocol == htons(ETH_P_8021AD)) {
 		xmit_tpid = MTK_HDR_XMIT_TAGGED_TPID_88A8;
-		break;
-	default:
+	} else {
 		xmit_tpid = MTK_HDR_XMIT_UNTAGGED;
 		skb_push(skb, MTK_HDR_LEN);
 		dsa_alloc_etype_header(skb, MTK_HDR_LEN);