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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 20 Jan 2023 19:21:32 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Frank Wunderlich <frank-w@...lic-files.de>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Landen Chao <Landen.Chao@...iatek.com>,
        Sean Wang <sean.wang@...iatek.com>,
        DENG Qingfang <dqfext@...il.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Daniel Golle <daniel@...rotopia.org>
Subject: Re: [BUG] vlan-aware bridge breaks vlan on another port on same gmac

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@....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@....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@....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@....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);