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

No luck for me adding port 5 to the config either Pilot6, but thank you for the suggestion. Since the VOIP box is working plugged into a port on the main lan, I think I'll just leave it there and save my debug time for DSA when it replaces swconfig.

Edit: And...the 5GHz wifi interface lost access to the VLAN today, so I flashed 19.07.3 stable to the EA6350 and all is good. I can't say I wasn't warned - the Downloads page clearly advises not to experiment with snapshot for a main home device. Did I listen? Of course not!

@blogic is there a chance you can look into the commit https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=8c191712558ce945993982b03abc5ce80e0fe230 that broke VLAN in ipq40xx ?

show me your config. the switch basically allows you to do vlaning from netdev rather than having to play with the switch config

1 Like

This is it. It used to give me eth1.3 and eth1.4 so that I can create interfaces for them.

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '3'
	option vid '3'
	option ports '3 0t'

config switch_vlan
	option device 'switch0'
	option vlan '4'
	option vid '4'
	option ports '4 0t'

related post.

I have a similar problem with my Aruba InstantON AP11 / AP-303.

This device does not have an internal switch, it just has a single ethernet port. Software VLANs (eth0.10 and the like) are not working with latest master, the only thing that reaches the software VLAN interface is DCHP, ICMPv6 and ARP traffic, nothing else.

config interface 'v10'
	option proto 'none'
	option type 'bridge'
	option ifname 'eth0.10'

I usually bridge the software VLAN interface with a wifi-iface (to bind seperate SSIDs to individual VLANs):

config wifi-iface 'wifinet2'
	option device 'radio1'
	option mode 'ap'
	option ssid 'OpenWrt'
	option encryption 'sae'
	option wpa_disable_eapol_key_retries '1'
	option network 'v10'

I am running a GliNet B1300 with stock OpenWRT and need to add tagging a seperate VLAN. Shall I wait until the dust comes down?

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.


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.