Repository navigation
Conversation
openwrt-ai
reviewed
Oct 31, 2026
str0g
force-pushed
the
bpi4Pro8x-bridgevlan-regression
branch
from
November 7, 2026 22:50
e0bbb19 to
bd3eee3
Compare
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
force-pushed
the
bpi4Pro8x-bridgevlan-regression
branch
from
November 12, 2026 10:21
bd3eee3 to
95c0867
Compare
openwrt-ai
reviewed
Nov 12, 2026
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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"
}
}