Skip to content

luci-mod-network: switch-vlan: ignore wireless bridge members - #9170

Open
str0g wants to merge 1 commit into
openwrt:masterfrom
str0g:bpi4Pro8x-bridgevlan-regression
Open

str0g wants to merge 1 commit into
openwrt:masterfrom
str0g:bpi4Pro8x-bridgevlan-regression

Conversation

@str0g

@str0g str0g commented Oct 30, 2026 •

Copy link
Copy Markdown

findActiveBridge() rejects a vlan-aware bridge unless every member resolves to a switch or ethernet device, and collectBridgePorts() builds that member list from the UCI ports option, the ports named in bridge-vlan sections and the runtime members reported by luci-rpc getNetworkDevices.

Any wireless network attached to the bridge ("option network 'lan'") makes netifd join its AP pseudo-interfaces to the bridge, so those members report type "wifi", the every() check fails and the view falls back to the "No managed switch found" placeholder. DSA lan ports plus Wi-Fi inside a VLAN aware br-lan is the stock OpenWrt layout, so the view is unreachable on most devices and not only on the Bananapi BPI-R4 Pro 8X where this was observed.

Drop members of type "wifi" from collectBridgePorts() instead of rejecting the bridge: their VLAN role is derived from the wireless configuration (netifd adds them as ":*" to the runtime bridge-vlans), so they are neither a reason to hide the view nor something to offer as an editable T/U tile. Genuine virtual members - nested bridges, VLAN sub-interfaces, tunnels, wireguard - still veto the bridge, and a bridge without any physical member still finds no match.

Also correct the view header comment and the blocker text, which so far claimed that wireless members intentionally exclude a bridge.

Replayed the view logic offline against the board's /etc/config/network plus its live "ubus call luci-rpc getNetworkDevices" payload: before the change findActiveBridge() returned null with br-lan members lan1..lan6 and phy0.0-ap0, phy0.1-ap0, phy0.1-ap1, phy0.2-ap0; afterwards it selects br-lan with ports lan1..lan6 and checkUnsupportedConfig() stays empty. Adding br-lan.10 as a bridge member still vetoes the bridge.

This patch must be merged first (support for Bananapi BPI-R4 Pro 8X both10G + WiFi)

openwrt/openwrt#25841

Tested on

{
"kernel": "6.18.55",
"hostname": "Cerberon",
"system": "ARMv8 Processor rev 0",
"model": "Bananapi BPI-R4 Pro 8X",
"board_name": "bananapi,bpi-r4-pro-8x",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "SNAPSHOT",
"firmware_url": "https://downloads.openwrt.org/",
"revision": "r0-a31dd90f",
"target": "mediatek/filogic",
"manufacturer": "OpenWrt",
"description": "OpenWrt SNAPSHOT r0-a31dd90f",
"builddate": "1793380224"
}
}

@openwrt-ai openwrt-ai left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 1 new commits; no new issues found.


Generated by Claude Code

@str0g
str0g force-pushed the bpi4Pro8x-bridgevlan-regression branch from e0bbb19 to bd3eee3 Compare November 7, 2026 22:50
findActiveBridge() rejects a vlan-aware bridge unless every member
resolves to a switch or ethernet device, and collectBridgePorts() builds
that member list from the UCI ports option, the ports named in
bridge-vlan sections and the *runtime* members reported by
luci-rpc getNetworkDevices.

Any wireless network attached to the bridge ("option network 'lan'")
makes netifd join its AP pseudo-interfaces to the bridge, so those
members report type "wifi", the every() check fails and the view falls
back to the "No managed switch found" placeholder. DSA lan ports plus
Wi-Fi inside a VLAN aware br-lan is the stock OpenWrt layout, so the
view is unreachable on most devices and not only on the Bananapi
BPI-R4 Pro 8X where this was observed.

Drop members of type "wifi" from collectBridgePorts() instead of
rejecting the bridge: their VLAN role is derived from the wireless
configuration (netifd adds them as ":*" to the runtime bridge-vlans), so
they are neither a reason to hide the view nor something to offer as an
editable T/U tile. Genuine virtual members - nested bridges, VLAN
sub-interfaces, tunnels, wireguard - still veto the bridge, and a bridge
without any physical member still finds no match.

Also correct the view header comment and the blocker text, which so far
claimed that wireless members intentionally exclude a bridge.

Replayed the view logic offline against the board's /etc/config/network
plus its live "ubus call luci-rpc getNetworkDevices" payload: before the
change findActiveBridge() returned null with br-lan members lan1..lan6
and phy0.0-ap0, phy0.1-ap0, phy0.1-ap1, phy0.2-ap0; afterwards it selects
br-lan with ports lan1..lan6 and checkUnsupportedConfig() stays empty.
Adding br-lan.10 as a bridge member still vetoes the bridge.

Signed-off-by: Łukasz Buśko <lukasz.busko@guns4hire.cc>
Assisted-by: LLM
@str0g
str0g force-pushed the bpi4Pro8x-bridgevlan-regression branch from bd3eee3 to 95c0867 Compare November 12, 2026 10:21

@openwrt-ai openwrt-ai left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 1 new commits; no new issues found.


Generated by Claude Code

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants