VLAN tagging on ipq40xx (GL-B1300) no longer works

Any tips on how to make it work again?

I think you can try advice from this thread. That worked somehow for me.

Yeah, I did and that stopped working with the most recent 19.07 builds...

I think I remember that a fix was applied in GIT with a different VLAN tagging by default. So there would be a risk to upgrade the stock version to recent builds. Can you confirm or is this nonsense from me?

bug report had been created by @cwbsw on 06.08.2020:
no reaction so far, release tag with this bug :frowning:


Just git revert 8c191712558ce945993982b03abc5ce80e0fe230 on v19.04.4 you do have to resolve some conflicts here's my patchfile. It restores the old behavior and allows for port isolation on both the ea6350v3 and the GL-B1300.

I also reached out to some of the developers of the breaking patch to ask what was up. From what I understand two behaviors, nested vlans and isolated ports are simply impossible to do at the same time.

It used to be that nested vlans where impossible, now they are possible but port isolation is not. From this thread it seems that the latter is more popular than the former as usecase. I think the only real soltuion is to add a different driver package for each of the two beaviors and leave it up to the firmware builder to decide which one they wish to enable.

From 777b9fa253a6411a367b1b32163e65c99c7cec8e Mon Sep 17 00:00:00 2001
From: Justin Kilpatrick <justin@althea.net>
Date: Tue, 8 Sep 2020 20:32:50 -0400
Subject: [PATCH] Revert "ipq40xx: fix ethernet vlan double tagging"

This reverts commit 8c191712558ce945993982b03abc5ce80e0fe230.
 .../716-essedma-vlan-double-tag.patch         | 128 ------------------
 1 file changed, 128 deletions(-)
 delete mode 100644 target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch

diff --git a/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch b/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
deleted file mode 100644
index e268351273..0000000000
--- a/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
+++ /dev/null
@@ -1,128 +0,0 @@
-From: Sven Eckelmann <sven@narfation.org>
-Date: Wed, 8 Feb 2017 16:26:00 +0100
-Subject: [PATCH] ipq40xx: Fix ar40xx port separation
-It is currently not possible to submit (or receive) VLAN tagged frames over
-the ar40xx PHY switch and the edma ethernet device.
-This can be worked around by disabling enable_vlan. The separation of the
-eth0 and eth1 ports is then done by the vlan_tag information from the
-device tree. But the ar40xx PHY switch then also has to parse the word3
-port bitmap (word3) from the TDP when data was received from the CPU port
-IssueID: #2857
-Forwarded: no
- The ar40xx.c change was forwarded to Xiaofei Shen <xiaofeis@codeaurora.org>
- (QCA). But John Crispin will rewrite the driver anyway and we have to check
- later if this change is required in his driver too.
- drivers/net/phy/ar40xx.c | 6 +++++-
- 1 file changed, 5 insertions(+), 1 deletion(-)
---- a/drivers/net/phy/ar40xx.c
-+++ b/drivers/net/phy/ar40xx.c
-@@ -1200,7 +1200,11 @@ ar40xx_init_port(struct ar40xx_priv *pri
- 	ar40xx_rmw(priv, AR40XX_REG_PORT_STATUS(port),
--	ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0);
-+	/* CPU port is setting headers to limit output ports */
-+	if (port == 0)
-+		ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0x8);
-+	else
-+		ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0);
- 	ar40xx_write(priv, AR40XX_REG_PORT_VLAN0(port), 0);
-@@ -1243,6 +1247,10 @@ ar40xx_init_globals(struct ar40xx_priv *
- 	t = (AR40XX_PORT0_FC_THRESH_ON_DFLT << 16) |
- 	ar40xx_write(priv, AR40XX_REG_PORT_FLOWCTRL_THRESH(0), t);
-+	/* set service tag to 802.1q */
-+	ar40xx_write(priv, AR40XX_ESS_SERVICE_TAG, t);
- }
- static void
-@@ -1568,7 +1576,11 @@ ar40xx_setup_port(struct ar40xx_priv *pr
- 	u32 pvid = priv->vlan_id[priv->pvid[port]];
- 	if (priv->vlan) {
-+		if (priv->vlan_tagged & BIT(port))
-+			egress = AR40XX_PORT_VLAN1_OUT_MODE_TAG;
-+		else
- 		ingress = AR40XX_IN_SECURE;
- 	} else {
-@@ -1579,8 +1591,17 @@ ar40xx_setup_port(struct ar40xx_priv *pr
- 	t |= pvid << AR40XX_PORT_VLAN0_DEF_CVID_S;
- 	ar40xx_write(priv, AR40XX_REG_PORT_VLAN0(port), t);
--	t |= egress << AR40XX_PORT_VLAN1_OUT_MODE_S;
-+	t = egress << AR40XX_PORT_VLAN1_OUT_MODE_S;
-+	/* set CPU port to core port */
-+	if (port == 0)
-+	if (priv->vlan_tagged & BIT(port))
-+	else
- 	ar40xx_write(priv, AR40XX_REG_PORT_VLAN1(port), t);
- 	t = members;
---- a/drivers/net/ethernet/qualcomm/essedma/edma_axi.c
-+++ b/drivers/net/ethernet/qualcomm/essedma/edma_axi.c
-@@ -970,7 +970,6 @@ static int edma_axi_probe(struct platfor
- 		edma_netdev[i]->netdev_ops = &edma_axi_netdev_ops;
- 		edma_netdev[i]->max_mtu = 9000;
- 		edma_netdev[i]->features = NETIF_F_HW_CSUM | NETIF_F_RXCSUM
--				      | NETIF_F_HW_VLAN_CTAG_TX
- 				      | NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_SG |
- 				      NETIF_F_TSO | NETIF_F_GRO;
- 		edma_netdev[i]->hw_features = NETIF_F_HW_CSUM | NETIF_F_RXCSUM |
-@@ -982,10 +981,10 @@ static int edma_axi_probe(struct platfor
- 					     NETIF_F_TSO | NETIF_F_GRO;
--		edma_netdev[i]->features |=  NETIF_F_RXHASH | NETIF_F_NTUPLE;
--		edma_netdev[i]->hw_features |=  NETIF_F_RXHASH | NETIF_F_NTUPLE;
--		edma_netdev[i]->vlan_features |= NETIF_F_RXHASH | NETIF_F_NTUPLE;
--		edma_netdev[i]->wanted_features |= NETIF_F_RXHASH | NETIF_F_NTUPLE;
-+		edma_netdev[i]->features |=  NETIF_F_NTUPLE;
-+		edma_netdev[i]->hw_features |=  NETIF_F_NTUPLE;
-+		edma_netdev[i]->vlan_features |= NETIF_F_NTUPLE;
-+		edma_netdev[i]->wanted_features |= NETIF_F_NTUPLE;
- #endif
- 		edma_set_ethtool_ops(edma_netdev[i]);
---- a/drivers/net/phy/ar40xx.h
-+++ b/drivers/net/phy/ar40xx.h
-@@ -151,6 +151,9 @@ struct ar40xx_mib_desc {
- #define   AR40XX_MIB_FUNC_NO_OP		0x0
- #define   AR40XX_MIB_FUNC_FLUSH		0x1
-+#define AR40XX_ESS_SERVICE_TAG		0x48
- #define AR40XX_REG_PORT_STATUS(_i)		(0x07c + (_i) * 4)
- #define   AR40XX_PORT_SPEED			BITS(0, 2)
- #define   AR40XX_PORT_STATUS_SPEED_S	0
-@@ -179,6 +182,8 @@ struct ar40xx_mib_desc {
- #define   AR40XX_PORT_VLAN0_DEF_CVID_S		16
- #define AR40XX_REG_PORT_VLAN1(_i)		(0x424 + (_i) * 0x8)
-+#define   AR40XX_PORT_VLAN1_CORE_PORT		BIT(9)
- #define   AR40XX_PORT_VLAN1_OUT_MODE		BITS(12, 2)
- #define   AR40XX_PORT_VLAN1_OUT_MODE_S		12

1 Like

Here's hoping if and when DSA is implemented on ipq40xx we can have our cake and eat it too again.

Before the change disabling port isolation, segregated wifi networks (guest, IOT, etc.) and restricting a port to a single VLAN (for IOT) both worked simultaneously on my EA6350v3. That was my home usecase.

Out of curiosity, can someone describe the usecase for a nested VLAN?

With all respect to core developers, breaking backwards compatibility should not be done so easily. They make outside contributors jump through the hoops before their changes are accepted, yet adding a config parameter here to choose one mode or the other while making the existing behaviour the default, never crossed anyone’s mind. I have hit several of these over the last several years across several router models and I have now given up on running OpenWrt; it takes too much time and effort to constantly monitor for changes and is mostly due to periodic backwards incompatible improvements in the core or some very popular packages. Not fun any more to discover that a relative’s router does not work after the upgrade because of these.
Will be replacing everything by the end of the year.


Personally I'm a little confused as to why this change was put into master and then backported into openwrt-19.04 in just a few days! that's hardly stable branch behavior.

I work professionally on a downstream firmware project. This is my full time job. This caught me by surprise and snuck into a release because I thought 'oh it's the stable branch no big changes are getting in'.

1 Like

Neither you nor I paid anything to OpenWrt to demand/expect anything, so everyone is at their mercy. You are free not to use OpenWrt :slight_smile: and move onto something else while paying for support to your vendor. That is what I am gonna do.

1 Like

I too would like to know this. What was the patch that ended up in 19.07.4 instead to do? I am staying on 19.07.3 for now, as I use multiple VLANs on the lan ports of an EA6350v3 router (based on ipq40xx).

1 Like

OpenWrt Master with 4.19 kernel seems to work again? (Fritz!Box 4040, Fritz!Box 7530)
Not sure what happened.

Kernel 4.19 is no official kernel of upcoming OpenWrt, so not sure why Kernel 4.19 on master should be relevant, 5.4 is the master branch kernel used for the next release.

If the master is working, we can probably backport the stuff.

  1. master is not working, master is not using kernel 4.19 and it did not use 4.x kernel on ipq40xx since march 2020
  2. 19.07 branch uses kernel 4.14, not 4.19

there is nothing to backport IMO, you can simply revert the commit which broke it.

You can easily switch to 4.19 kernel on master. :wink: The patchset is still deployed.
But now I saw that this is a backport from 5.4 kernel and it was never applied for the 4.19 master.

I had the same problem with Fritzbox 4040. After an Upgrade from 19.07.3 to 19.07.4 the Hardware LAN Ports with configured VLAN tagging stopped working.
I flashed back to 19.07.3 and imported the backup configuration. Now it is again working.

Is there hope that this VLAN bug is fixed in a future service release? Or do I have to stay with 19.07.3 forever as the last working version?

You have to revert the nested vlan commit. Soon there will be DSA support for the IP40xx and then everything should work fine.

but we need a fix for the 19.07 branch, DSA support won't be backported...

A fix is not possible... :confused: You have to compile your own image.