IPQ40xx Switch Config "Strangeness" (swconfig)

I have a GL-S1300 and had the same question as @JFlo. After mucking around all morning wondering why my vlan id=2 setting was not working for WAN, I found this thread.

I am using OpenWrt SNAPSHOT, r14966-7330348f2d (Linux 5.4.75), and for this version it's possible to reassign the internal vlan id used for the virtual wan interface. I changed it from 2 to 3 with sysctl:

# /etc/sysctl.conf

# Use vlan id=3 for virtual wan interface hack.

Then I set up my switch like this (port 0 is cpu and port 5 is wan):

# /etc/config/network

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

# this vlan is used internally by the driver for lan
config switch_vlan
        option device 'switch0'
        option vlan '1'
        option vid '1'
        option ports '0t 1 2 3 4'

# this vlan is the one my isp requires for pppoe
config switch_vlan
        option device 'switch0'
        option vlan '2'
        option vid '2'
        option ports '0t 5t'

# this vlan is used internally by the driver for wan
config switch_vlan
        option device 'switch0'
        option vlan '3'
        option vid '3'
        option ports '0t 5'


1 Like

I tested the vlan tag 2 with the current stable release 19.07.5.
Now it's possible to use vlan 2 together with the wan port, but the performance is only about 65% of the stock Asus firmware.

A "for me too" posting from me as I was directed here from my thread

The hardware is a D-Link DAP-2610 (got it wrong in the initial posting over there) and I would like to ask what I can try to make VLANs work with that hardware.

Checkout this link:

Thanks, will do.
In the meantime I made progress and got 3 VLANs working, I assume.
Right now I am waiting for the (remote) tester of the Wifis bridged to the interfaces.
I can't test that myself as I am a few hundred kms away from that hardware (yeah, that makes configuration extra fun).
In a few hours I should know more.

Any progress on this?
I can't got working WAN VLAN 35 on my GL-B1300, on pure OpenWRT.
It works fine on GL.iNet QSDK pure OpenWRT.

Follow and read what I linked in my reply a few posts up.

1 Like

If I will setup VLAN like this can I enter PPPoE settings via Luci?


You’ll only be creating a VLAN on the WAN port.

1 Like

Didn't worked for me.
I tried this on latest openwrt.org snapshot and eko.one.pl latest build.
I put in /etc/config/network this:

config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
Was already there.

Next I tried to run PPPoE session on both: eth0.35 and eth1.35, none of them worked.

Interestingly enough, I found those options on kernel 4.14 on my Meraki MR33 as well, on 19.07 build.

Were you able to get 2 VLANs working with that?

Haven't tried yet so far, but will surely do in future.

Just use latest snapshot, it seems to be working properly with that.

I will, though I wonder which commit did fix this, is it cdc8d4b46f08: ("ipq40xx: revert usage of VLAN S-TAG") or something else. It seems that on MR33, which has one port, tagging has chance to work because it behaves as if it were a "LAN" port, but for WAN this would not work as in #69.

If you ask me then it's probably this one: https://github.com/openwrt/openwrt/commit/2e6c236abd0bebe82bf9020941f34344acb3ae1f

Would you consider merging these patches in the upstream Openwrt? :slight_smile:

1 Like

Oh well, I wish but those patches left out a lot of devices in 02_network. I removed those devices since I have no way to test them. That's why I slowly add them to my custom build upon a requester willing to test them there.

1 Like

I'm working with an EA8300 and trying to get the WAN port set up as my VLAN trunk. The WAN port does not show up in the switch section of LuCI: is it still OK to tag '5t' in switch_vlan and bridge eth1 (presumably the edma VLAN'd WAN port), without getting my config borked by LuCI/uci? I'm using VLAN 2 tags successfully on the LAN ports so that is in opposition to some of the information in this thread (possibly this has changed recently in 21.02). Perhaps other things have also recently changed? How does this "double VLAN" shenanigans impact performance on the eth1 WAN (port 5) -- maybe I should just avoid it altogether, at least as a trunk (but it's blue! :grinning:)?

Here is my trunk'd VLAN on port 1 using VLAN 2 on ports 2/3, no issues:

I opened now again a bug report: