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

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.

Is there an end-user friendly way to use an openwrt image with working VLAN tagging on a Fritzbox 4040?
I am not sure what this DSA support is and anyway I am at the moment not able to compile an own image.
This also means it is necessary to compile a special branch with working VLAN support for each and every update in the future...
Or will this be resolved in a future major release that comes with that DSA support? So I could stay on 19.07.3 as long as a new working major release appears on the horizon?

Sorry for all my stupid questions. I am not so much familiar with all the details and things like reverting git commits / compiling images is asked to much on me...

Yep. :slight_smile: Just wait for 20.X and working DSA support and you will be happy. I don't have build infrastructure, but probably we could just compile working images for all ipq40xx socs with 19.07.4 by applying a patch, I already linked somewhere.

1 Like

There is pretty much no way for DSA to be in 20.x
It's still buggy and extremely hacky.

There is a lack of docs and manpower.

So the next version will probably just feature a revert of the commit, right?

Well not unless someone makes a PR or sends the patch to the mailing list.

A PR for what? From what I've read, that commit has already been rolled back, there is simply no build yet with that change in it.
Anyway, I don't have anywhere near enough skills to work on DSA myself.

Well, feel free to check the git log but its not reverted.

2 Likes

You can have port isolation or nested vlans. Current OpenWrt Version supports nested vlans. Maybe we can have two seperated images? :S

I doubt that as that will require 2 kernel trees to be built and will waste quite a lot of buildbots resources.

I understand what port isolation is, but this thing here escapes me. Anyway, it basically means no upgrades until DSA is usable... or I roll my own image, right?