netdev - [PATCH net-next 5/8] net: dsa: rtl8366: Disable "4K" VLANs

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:   Mon, 13 Sep 2021 16:42:57 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, Linus Walleij <linus.walleij@...aro.org>,
        Mauri Sandberg <sandberg@...lfence.com>,
        Alvin Šipraga <alsi@...g-olufsen.dk>,
        DENG Qingfang <dqfext@...il.com>
Subject: [PATCH net-next 5/8] net: dsa: rtl8366: Disable "4K" VLANs

I have to disable this feature to have working VLANs on the
RTL8366RB at least, probably on all of them.

It appears that the very custom VLAN set-up was using this
feature by setting up one VLAN per port for a reason: when
using "4K" VLAN, every frame transmitted by the switch
MUST have a VLAN tag.

This is the reason that every port had its own VLAN,
including the CPU port, and all of them had PVID turned on:
this way every frame going in or out of the switch will
indeed have a VLAN tag.

However the way Linux userspace like to use VLANs such as
by default assigning all ports on a bridge to the same VLAN
this does not work at all because PVID is not set for these,
and all packets get lost.

Therefore we have to do with 16 VLAN for now, the "4K"
4096 VLAN feature is clearly only for switches in
environments where everything is a VLAN.

This was discovered when testing with OpenWrt that join
the LAN ports lan0 ... lan3 into a bridge and then assign
each of them into VLAN 1 with PVID set on each port: without
this patch this will not work and the bridge goes numb.

Cc: Vladimir Oltean <olteanv@...il.com>
Cc: Mauri Sandberg <sandberg@...lfence.com>
Cc: Alvin Šipraga <alsi@...g-olufsen.dk>
Cc: Florian Fainelli <f.fainelli@...il.com>
Cc: DENG Qingfang <dqfext@...il.com>
Signed-off-by: Linus Walleij <linus.walleij@...aro.org>
---
ChangeLog v1->v4:
- New patch after discovering that the VLAN configuration in
  OpenWrt was not working.
---
 drivers/net/dsa/rtl8366.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/net/dsa/rtl8366.c b/drivers/net/dsa/rtl8366.c
index fae14c448fe4..9652323167c2 100644
--- a/drivers/net/dsa/rtl8366.c
+++ b/drivers/net/dsa/rtl8366.c
@@ -313,13 +313,15 @@ int rtl8366_vlan_add(struct dsa_switch *ds, int port,
 		untagged = true;

-	/* Enable VLAN in the hardware
-	 * FIXME: what's with this 4k business?
-	 * Just rtl8366_enable_vlan() seems inconclusive.
+	/* Enable VLAN in the hardware, do NOT enable VLAN4K, because the
+	 * 4K VLAN will activate a 4096 entries VID table, but has the side
+	 * effect that every processed frame MUST have a VID, meaning non-VLAN
+	 * traffic will now work at all. So we will let the 16 VLAN entries
+	 * suffice.
 	 */
-	ret = rtl8366_enable_vlan4k(smi, true);
+	ret = rtl8366_enable_vlan(smi, true);
 	if (ret) {
-		NL_SET_ERR_MSG_MOD(extack, "Failed to enable VLAN 4K");
+		NL_SET_ERR_MSG_MOD(extack, "Failed to enable VLAN");
 		return ret;
 	}

-- 
2.31.1