VLAN tagging on LAN2 breaks connectivity to device on that port — GL-MT5000 (Brume 3)

Router
1

Hi all,

I'm running into what looks like a switch/driver-level issue with VLAN tagging on my Brume 3 (GL-MT5000), and I've exhausted my own troubleshooting ideas. Hoping someone here has hit the same thing.

Setup:

Brume 3 (GL-MT5000), factory reset, stock firmware 4.9.0
LAN1 → unmanaged switch (other wired devices)
LAN2 → Zyxel NWA240BE access point, static IP 192.168.8.2

Goal: add a tagged VLAN (ID 20) on LAN2 to carry a second SSID from the AP, isolated from the main LAN, while keeping the AP's own management traffic on the native/untagged VLAN 1

Problem:
The moment I add VLAN 20 as tagged on LAN2 (switch port 1) + CPU (port 17), the AP at 192.168.8.2 immediately stops responding — 100% ping loss, and ip neigh show confirms it's a Layer 2 failure (ARP FAILED state), not a routing issue. The Brume 3 itself stays fully reachable throughout (192.168.8.1 never drops). The moment I set LAN2 back to off/untagged-only for VLAN 20, the AP is instantly reachable again — no delay, no retry needed.

What I've already tried (all unsuccessful)

Standard LuCI Network → Switch page: add VLAN, LAN2 tagged → same failure, 90s auto-rollback triggers
Raw uci set + /etc/init.d/network restart via SSH → same failure (also hit an unrelated /sbin/wifi: not found error during restart, which I now understand is expected/harmless on this Wi-Fi-less hardware)
Direct swconfig dev switch0 vlan ... set ports ... + swconfig commit, bypassing the restart script entirely → same failure
Used /etc/init.d/network reload instead of restart → same failure
Followed the exact script steps provided by @bruce in this thread (tagged VLAN on LAN2/port 1, CPU port 17 tagged, PVID=1 forced on LAN2, LAN1/port 0 completely untouched) → same failure
Tried different VLAN IDs (2, 10, 20) → same failure regardless of ID
Tried with "As Native VLAN" checked and unchecked on the AP side, with matching Management VLAN ID → same failure both ways
Full factory reset on both the Brume 3 and the Zyxel AP, then retested the exact script-recommended config fresh → same failure

Current switch state when it breaks (via swconfig dev switch0 show):

VLAN 1: ports: 0 1 17t (untag=0003)
VLAN 20: ports: 1t 17t (untag=0000)

This matches the officially-provided script's intended pattern exactly, port-for-port.

Question: Is this a known limitation of the RTL8366UB switch chip/driver on this specific hardware — i.e., a port genuinely cannot be simultaneously untagged-member of one VLAN and tagged-member of another? Or is there some additional step (beyond what's in the referenced script) needed to make a single port carry both a native and a tagged VLAN successfully to a downstream device?

Happy to provide full uci show network, swconfig dev switch0 show, and logread output if useful.

Thanks in advance for any pointers.

\\CA

2

I believe this is a driver issue as discussed here:

I never got this type of setup working, if you scroll down some more under the linked post you can see a detailed post by @rthco.

My 2 cents wait for a newer firmware or a official response in the linked discussion if they fixed it the part with the glue'd wrappers.

1 Like
3

It was a bit dissapointing this wasn’t fixed in 4.9.0 to be honest but hopefully we can see a fix for it soon….

1 Like
4

I have the suspicion they might hold on this when the gl sdk get released with vlan ui support for the Brume3, I have seen some screenshots about this for other models where the gl sdk is a newer snapshot.

Eventually they will have to find a solution for this anyway because the port thing is different than regular other GL-iNet routers.

5

We confirmed with our team that the Brume 3 VLAN issue previously reported by rthco has been fixed and will be included in the next firmware release.

Please wait a little longer. Thank you for your patience.

2 Likes