luci-mod-status: channel analysis shows more radios than expected on BPI R4

[EPinci]

Is there an existing issue for this?

• I have searched the existing issues

screenshots or captures

Actual behaviour

In OpenWRT 24.10-RC2+, using a BPI r4, the radio stack is not identified correctly in the status -> channel analisys page resulting in multiple detection of radios. Also channel analisys is misbehaving.

Expected behaviour

Expected behavior is 3 tabs, one per radio/band (as opposed to one per radio per band) as it was in earlier builds.
This started happening after the "option path" identifier has been changed for the BPI r4 radios.

Steps to reproduce

Just run a normal openwrt build on a BPI r4.

Additional Information

OpenWrt 24.10-SNAPSHOT r0-f0ff244 / LuCI openwrt-24.10 branch 24.351.75331~8b3c13f

What browsers do you see the problem on?

Microsoft Edge

Relevant log output

No response

[systemcrash]

Could this be similarly related to symptoms we saw in #7482? What do you think @rmandrad ?

[EPinci]

Repros also on 24.10.0-rc4.
Channel analisys does not show any data after scanning.

[hauke]

Which LuCI version are you using? Did you use the image from downloads.openwrt.org or did you use the image builder?
The Image builder might still use an older LuCI version.

For me it is working with this version:
Powered by LuCI openwrt-24.10 branch (24.357.59006~41cbd31) /[ OpenWrt 24.10-SNAPSHOT (r28210-654c9732dc)](https://openwrt.org/)

[EPinci]

OpenWrt 24.10.0-rc4 r28211-d55754ce0d / LuCI openwrt-24.10 branch 24.357.59006~41cbd31 built from the branch.
Not working - empty channel graph.

[hauke]

hmm strange.

I used a Linksys E8450 (UBI) and accessed LuCi using Firefox.

[EPinci]

On BPI r4, both Chrome and Edge, this is broken.

[rmandrad]

I don't have 24.10 (using snapshot / my own build) however there have been changes both on mtk (by having a single physical device and "logical" radios using the following naming standard "phy.ap" and new ucode code that may be causing issues with luci (I actually noticed a new bug) however
@EPinci could you share your /etc/config/wifi ? otherwise use @hauke suggestion of using latest

[EPinci]

My wireless config isn't super fancy:

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'soc/11300000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option radio '0'
        option band '2g'
        option channel '9'
        option htmode 'EHT20'
        option country 'IT'
        option cell_density '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'REDACTED'
        option encryption 'sae-mixed'
        option key 'REDACTED'
        option ocv '0'
        option ieee80211k '1'
        option ieee80211r '1'
        option mobility_domain 'REDACTED'
        option ft_over_ds '0'
        option bss_transition '1'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'soc/11300000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option radio '1'
        option band '5g'
        option channel 'auto'
        option htmode 'EHT160'
        option country 'IT'
        option cell_density '0'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'REDACTED'
        option encryption 'sae-mixed'
        option key 'REDACTED'
        option ocv '0'
        option ieee80211k '1'
        option ieee80211r '1'
        option mobility_domain 'REDACTED'
        option ft_over_ds '0'
        option bss_transition '1'

config wifi-device 'radio2'
        option type 'mac80211'
        option path 'soc/11300000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option radio '2'
        option band '6g'
        option channel '81'
        option htmode 'EHT160'
        option country 'IT'
        option cell_density '0'

config wifi-iface 'default_radio2'
        option device 'radio2'
        option network 'lan'
        option mode 'ap'
        option ssid 'REDACTED'
        option encryption 'sae'
        option key 'REDACTED'
        option ocv '0'
        option ieee80211k '1'
        option ieee80211r '1'
        option mobility_domain 'REDACTED'
        option ft_over_ds '0'
        option bss_transition '1'

config wifi-iface 'guest'
        option device 'radio0'
        option mode 'ap'
        option ssid 'REDACTED'
        option encryption 'sae-mixed'
        option isolate '1'
        option key 'REDACTED'
        option network 'guest'
        option ocv '0'

also ToT of 24.10 doesn't seem to have any relevant commits on top of RC4 but I'll give it a try nevertheless...

[rmandrad]

so did some troubleshooting and I suspect the root cause is with iwinfo

the code is querying radio 0 via a rpc call to iwinfo

iwinfo radio0 info points to the 5Ghz radio (it should be the 2GHz radio)

the same for radio1

the same for the scan

so the rpc call should be against the interface like
iwinfo phy0.1-ap0 scan

radio0-2 always points to the 5GHz

[systemcrash]

Somewhere luci pulls this info. It gets the 'radios' here (radio0 etc), I think:

luci/modules/luci-mod-status/htdocs/luci-static/resources/view/status/channel_analysis.js

Line 388 in 527acd5

network.getWifiDevices().then(L.bind(function(data) {

which calls:

luci/modules/luci-base/htdocs/luci-static/resources/network.js

Lines 1376 to 1388 in 527acd5

	getWifiDevices: function() {
	return initNetworkState().then(L.bind(function() {
	var uciWifiDevices = uci.sections('wireless', 'wifi-device'),
	rv = [];
	for (var i = 0; i < uciWifiDevices.length; i++) {
	var devname = uciWifiDevices[i]['.name'];
	rv.push(this.instantiateWifiDevice(devname, _state.radios[devname] || {}));
	}
	return rv;
	}, this));
	},

So this depends entirely on what is already in /etc/config/wireless, per wifi-device.

Three radios, each capable of 3 spectra.

[fridtjof]

so did some troubleshooting and I suspect the root cause is with iwinfo

Yeah, I think the trouble lies with iwinfo as well. It seems to be written with the assumption that every phy maps to exactly one radio (and therefore that every separate radio must be a separate phy). However:

# iw phy phy0 info
Wiphy phy0:
[...snip...]
	wiphy radio 0:
		freq range: 2400.0 MHz - 2500.0 MHz
		valid interface combinations:
			 * #{ AP, mesh point } <= 16, #{ managed } <= 19,
			   total <= 19, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 160 MHz }

	wiphy radio 1:
		freq range: 5000.0 MHz - 5900.0 MHz
		valid interface combinations:
			 * #{ AP, mesh point } <= 16, #{ managed } <= 19,
			   total <= 19, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 160 MHz }

	wiphy radio 2:
		freq range: 5900.0 MHz - 7200.0 MHz
		valid interface combinations:
			 * #{ AP, mesh point } <= 16, #{ managed } <= 19,
			   total <= 19, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 160 MHz }

This seems to be a relatively new feature introduced to support MLO, see:

• https://lore.kernel.org/all/cover.8f108602e7f90e91332f131cc9fa115a669a2bf4.1720514221.git-series.nbd@nbd.name/
• https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/

[fridtjof]

I spent some time since yesterday learning about the various innerworkings of linux wireless and OpenWRT's wifi config stack.

From what I can tell, the crucial part is how iwinfo goes from a UCI device name (e.g. radio0), or a PHY name (e.g. phy0) to an interface name (e.g. phy0.X-apY by default, with X = radio index and Y = VIF index), which it then uses to scan.

Currently, given a UCI name 'radio0', iwinfo will look up that config section through UCI, then attempt to find a PHY index (always 0 in this case) through 'path', 'macaddr' and lastly 'phy' options. Crucially, all this will always just resolve to index 0 for all radios, because they belong to the same PHY.

nl80211_phy2ifname, which is used for iwinfo's scan function, then uses that phy index to look up the last network interface matching that PHY index through sysfs (by iterating through /sys/class/net/*/phy80211/index until it finds a match).
Of course, it will always use the same one here (phy0.1-ap0 in my case) regardless.

UCI wifi-device sections are distinguished on this board through a relatively new option ('radio') specifying the radio index to use.

Unfortunately, looking through e.g. /sys/class/net/phy0.1-ap0/, there is a phy80211 symlink pointing to the phy, but there seems to be no way to find out the radio index from an interface, not even through netlink (which does otherwise expose information about the radios belonging to a PHY).

Deducing the radio index from the interface name is not a good solution, because the prefix (consisting of the phy0.0 part) may be overridden by configuration (openwrt/openwrt@a9ff3ba).

From what I can tell, the expectation from netlink seems to be that you can uniquely address a specific radio by using an interface name. Because having multiple radios per PHY is a pretty recent feature, not being able to address a radio (for scanning etc) by just a (phy,radio) index pair seems like an oversight.

The best solution would probably be to add something like an ieee80211_radio_index node to /sys/class/net/* for ieee80211 interfaces that would allow for identifying the radio a network interface is assigned to.