DSA Unmanaged VLANS no longer connect

GwaiTsi · October 12, 2025, 8:26pm

I previously had WIFI and LAN VLANs in unmanaged forward to upstream DHCP servers.
Now, my backup configs no longer work (even if i revert to older openwrt versions).

I am using a comfast e395ax (MT7981AA) AP with the wan getting untagged address for local management. then various vlans for wifi and the lan port.

I reset back to factory and created the below minimalist config to test.
Never the lan nor wifi get an IP. however, if i set up a dhcp server on interfaces the clients do get an ip. i disabled the firewall for testing.

onfig interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd79:5296:bf26::/48'
        option packet_steering '1'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        option bridge_empty '1'
        option ipv6 '0'

config interface 'lan'
        option device 'br-lan.26'
        option proto 'none'
        option delegate '0'

config interface 'wan'
        option device 'eth1'
        option proto 'dhcp'

config interface 'wan6'
        option device 'eth1'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix 'auto'

config bridge-vlan
        option device 'br-lan'
        option vlan '1'
        list ports 'lan1'

config bridge-vlan
        option device 'br-lan'
        option vlan '26'

config bridge-vlan
        option device 'br-lan'
        option vlan '40'

config interface 'wifi'
        option proto 'none'
        option device 'br-lan.40'
        option delegate '0'

config device
        option name 'br-lan.26'
        option type '8021q'
        option ifname 'br-lan'
        option vid '26'
        option ipv6 '0'

config device
        option name 'br-lan.40'
        option type '8021q'
        option ifname 'br-lan'
        option vid '40'
        option ipv6 '0'

psherman · October 12, 2025, 10:33pm

This is not valid but should be relatively easy to resolve.

Remove he bridge empty and IPv6 lines below

I'm assuming VLAN 1 is untagged on the uplink... specify that explicitly by adding :u* like this:

config bridge-vlan
        option device 'br-lan'
        option vlan '1'
        list ports 'lan1:u*'

These don't have a port associated:

To fix those, add the following to each of the stanzas:

        list ports 'lan1:t'

Delete these:

GwaiTsi:

config device
        option name 'br-lan.26'
        option type '8021q'
        option ifname 'br-lan'
        option vid '26'
        option ipv6 '0'

config device
        option name 'br-lan.40'
        option type '8021q'
        option ifname 'br-lan'
        option vid '40'
        option ipv6 '0'

Reboot and test again.

GwaiTsi · October 13, 2025, 6:28am

Hi Peter,

I made those mods per below, but neither wifi (40) nor lan(26) get an id.
You are correct, the wan port should be untagged with dhcp for device mgmt.

I think it might have something to do with the below?

github.com/openwrt/openwrt

MT7981 (OpenWrt One): Bridge VLAN filtering fails to process untagged ingress traffic on PVID port (post port-disable fix)

opened 02:37PM - 23 Apr 25 UTC

ricardomfmsousa

target/mediatek bug Official Image Supported Device release/24.10

### Describe the bug **Platform:** * **Device:** OpenWrt One * **SoC:** Med…iaTek MT7981 (Filogic 820) * **Tested OpenWrt Versions:** * `24.10.0 - r28427-6df0e3d02a` (Port `eth1` entered `disabled` state) * `24.10.1 - r28597-0425664679` (Port `eth1` stays `UP`, but traffic fails) **Description:** When configuring bridge VLAN filtering on `br-lan` with the built-in LAN port (`eth1`) set as an untagged member of a specific VLAN (e.g., VLAN 10) using PVID, communication with the router via that port fails. * On older snapshot `24.10.0-r28427`, enabling this configuration caused the kernel to put `eth1` into a `disabled` state (see log snippet below). * On newer snapshot `24.10.1-r28597`, the port `eth1` remains `UP` and `LOWER_UP`, but untagged ingress traffic (e.g., ARP requests from a client) arriving on `eth1` is not delivered to the corresponding logical VLAN interface (`br-lan.10`). This prevents ARP resolution and any communication with the router's IP on that VLAN interface. * Disabling `option vlan_filtering '1'` on `br-lan` and attaching the `lan` interface directly to `br-lan` works correctly, allowing communication. ### OpenWrt version r28597-0425664679 ### OpenWrt release 24.10.1 ### OpenWrt target/subtarget mediatek/filogic ### Device OpenWrt One ### Image kind Official downloaded image ### Steps to reproduce 1. Factory reset OpenWrt One running a recent snapshot (e.g., `24.10.1`). 2. Configure `/etc/config/network` similar to the following relevant sections: ```uci config device 'br_lan' option type 'bridge' option name 'br-lan' list ports 'eth1' option vlan_filtering '1' # Add CPU tags list vlan_config 'vid=10 local=1' # ... other CPU tags if needed ... # Configure eth1 as untagged access port for VLAN 10 list vlan_config 'vid=10 port=eth1 pvid=1 untagged=1' config interface 'lan' option device 'br-lan.10' # Use VLAN interface option proto 'static' option ipaddr '192.168.10.1' option netmask '255.255.255.0' # ... other lan options ... ``` 3. Reload network: `service network reload` 4. Connect a client computer directly to `eth1`. 5. Configure a static IP on the client (e.g., `192.168.10.10/24`, gateway `192.168.10.1`). 6. Attempt to ping the router: `ping 192.168.10.1` ### Actual behaviour * Ping fails (Destination Host Unreachable or timeout). * `tcpdump -i eth1 -n arp` shows ARP requests arriving from the client. * `tcpdump -i br-lan.10 -n arp` shows **no** ARP requests arriving on the VLAN interface. * `ip neigh show dev br-lan.10` shows no entries for the client. * (Secondary Issue) The command `ip bridge vlan show` fails with "Object 'bridge' is unknown". ### Expected behaviour * Ping should succeed. * ARP requests seen on `eth1` should also be seen on `br-lan.10`. * `ip neigh show dev br-lan.10` should show the client's entry after successful ARP. * `ip bridge vlan show` should ideally display the bridge VLAN configuration. ### Additional info **Diagnostic Log Snippet (from older firmware `r28427` showing port disable):** kern.info kernel: [ 20.843392] br-lan: port 1(eth1) entered blocking state kern.info kernel: [ 20.848629] br-lan: port 1(eth1) entered disabled state This appears to be a regression or remaining driver issue specifically related to handling untagged ingress traffic on PVID ports when bridge VLAN filtering is enabled on the MT7981 SoC. ### Diffconfig ```text ``` ### Terms - [x] I am reporting an issue for OpenWrt, not an unsupported fork.


config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd79:5296:bf26::/48'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'

config interface 'lan'
	option device 'br-lan.26'
	option proto 'none'
	option delegate '0'

config interface 'wan'
	option device 'eth1'
	option proto 'dhcp'

config bridge-vlan
	option device 'br-lan'
	option vlan '1'
	list ports 'lan1:u*'

config bridge-vlan
	option device 'br-lan'
	option vlan '26'
	list ports 'lan1:t'

config bridge-vlan
	option device 'br-lan'
	option vlan '40'
	list ports 'lan1:t'

config interface 'wifi'
	option proto 'none'
	option device 'br-lan.40'
	option delegate '0'

results of tests

root@OpenWrt:/etc/config# cat /sys/class/net/br-lan/bridge/vlan_filtering
1
root@OpenWrt:/etc/config# bridge vlan show
-ash: bridge: not found
root@OpenWrt:/etc/config# dmesg | grep -i bridge
[    1.476667] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
root@OpenWrt:/etc/config# dmesg | grep -i vlan
[    1.489869] 8021q: 802.1Q VLAN Support v1.8
root@OpenWrt:/etc/config# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc mq state UP qlen 1000
    link/ether 40:a5:ef:0e:1f:79 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 40:a5:ef:0e:1f:7a brd ff:ff:ff:ff:ff:ff
4: lan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 40:a5:ef:0e:1f:79 brd ff:ff:ff:ff:ff:ff
13: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 40:a5:ef:0e:1f:79 brd ff:ff:ff:ff:ff:ff
14: br-lan.26@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 40:a5:ef:0e:1f:79 brd ff:ff:ff:ff:ff:ff
15: br-lan.40@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 40:a5:ef:0e:1f:79 brd ff:ff:ff:ff:ff:ff
16: phy0-ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 40:a5:ef:0e:1f:7b brd ff:ff:ff:ff:ff:ff
root@OpenWrt:/etc/config# bridge link show
-ash: bridge: not found
root@OpenWrt:/etc/config#

GwaiTsi · October 14, 2025, 1:31pm

Hi Peter,
it seems the bug report I referenced goes back even further.

I am using a Comfast E395AX which has an MT7531 switch plus MT7981AA CPU with the architecture below. There is only a single LAN port and single WAN port despite the chip capabilities.

my setup on the wan port was connected untagged to the upstream switch.
my manage network was the untagged ethernet. the wan dhcp received 20.x net
The lan ports are unmanaged as receive 26.x from the vlan26 and pvid 26
The wifi bridge was unmanaged and receive 40.x from vlan40

with swconfig i never had a problem connecting to the APs on the 20.x net
when I first setup after the DSA change, i created a bridge for each network and paired it with a separate vlan for eth1.26, eth1.40.
This seemed to work with the last config backup end 08.25
after the attendsysupgrade, i lost connection to the device. using your guidance above I setup a test environment and added a specific mgmt vlan with a static ip.
I can see the same issue describe in above, in 23.05.04. If eth1 is part of the br-lan bridge, the untagged wan port never gets a dhcp, but all other functionality works.
the setup below only works when eth1 and lan1 are part of the bridge. but dhcp doesn’t
i am doing something wrong? ideally i would like the management on the dhcp address so i don’t have to change my whole network


config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fdc0:a06c:5306::/48'

config device
	option type 'bridge'
	option name 'br-lan'
	list ports 'eth1'
	list ports 'lan1'

config bridge-vlan
	option device 'br-lan'
	option vlan '10'
	list ports 'lan1:t'

config bridge-vlan
	option device 'br-lan'
	option vlan '26'
	list ports 'eth1:t'
	list ports 'lan1'

config bridge-vlan
	option device 'br-lan'
	option vlan '40'
	list ports 'eth1:t'

config interface 'wan'
	option device 'eth1'
	option proto 'dhcp'

config interface 'lan26'
	option device 'br-lan.26'
	option proto 'none'

config interface 'wifi'
	option proto 'none'
	option device 'br-lan.40'

config interface 'mgmt'
	option proto 'static'
	option device 'br-lan.10'
	option ipaddr '192.168.10.15'
	option netmask '255.255.255.0'

EDIT: I fixed it by adding below

config bridge-vlan
	option device 'br-lan'
	option vlan '1'
	list ports 'eth1:u'
    option pvid '1'

and changing

config interface 'wan'
	option device 'eth1'
	option proto 'dhcp'

TO
config interface 'wan'
	option device 'br-lan.1'
	option proto 'dhcp'

psherman · October 14, 2025, 3:11pm

I'll review this a bit more later, but...

The last line above is not how you designate PVID.... instead, you use a * like this:

config bridge-vlan
	option device 'br-lan'
	option vlan '1'
	list ports 'eth1:u*'

This was the big one...

The reason this was necessary is that you put the eth1 port into the bridge, so it was no longer available for use as a unique device.