luci-mod-status: channel_analysis: error when representing 40 MHz networks

[castillofrancodamian]

In channel analysis, the graph does not display correctly when representing 40 MHz networks and shows them as 20 MHz. This appears when the interfaces do not have any clients connected.

Channel analysis on mr70x. The device uses 40 MHz and sees the Archer C60 as if it were 20 MHz and has no clients connected.

Channel analysis on the Archer C60 and watching the mr70x with a client connected.

Channel analysis on Archer C60 watching the mr70x with a client connected.

Apparently the channel analysis represents the networks at 40 MHz if it has clients and at 20 MHz if it does not. Or maybe it's another reason. I think it has to do with this and this.

root@mr70x:~# cat /etc/openwrt_release DISTRIB_ID='OpenWrt' DISTRIB_RELEASE='SNAPSHOT' DISTRIB_REVISION='r24806-735efbfb7c' DISTRIB_TARGET='ramips/mt7621' DISTRIB_ARCH='mipsel_24kc' DISTRIB_DESCRIPTION='OpenWrt SNAPSHOT r24806-735efbfb7c' DISTRIB_TAINTS=''

root@archer_c60:~# cat /etc/openwrt_release DISTRIB_ID='OpenWrt' DISTRIB_RELEASE='SNAPSHOT' DISTRIB_REVISION='r24806-735efbfb7c' DISTRIB_TARGET='ath79/generic' DISTRIB_ARCH='mips_24kc' DISTRIB_DESCRIPTION='OpenWrt SNAPSHOT r24806-735efbfb7c' DISTRIB_TAINTS=''

[systemcrash]

@knarrff Any ideas on this one?

[knarrff]

PR #6728 could be the reason the OP sees this. If so, I could see two possibilities why:

1) if the station in fact does only advertise as 20MHz until a client connected and then tries to go higher. I could imagine maybe power savings to be a reason for something like that. However, the mentioned PR should not have changed that. Can the OP confirm that the PR is indeed causing this?

• In this case there would not be anything we could do, other than the owner trying to let the station advertise 40MHz bandwidth capability from the start, even without clients connected. 2) if the station does not advertise the 40 MHz capability using the HT frame fields at all.
• This case would be more subtle. As I read the code, the channel_analysis script itself only uses what the underlying framework passes to it, and that specifically says that a "40 MHz VHT" flag only means "<=40 MHz" and to look at the HT flag in that case. However, I would expect the station to not change such behaviour based on whether a client is connected or not, but I am really not an expert there.

Since the analysis script gets its info from iwinfo: could you see what that reports for those cases? (https://openwrt.org/packages/pkgdata/iwinfo)

[systemcrash]

@castillofrancodamian if reverting the PR (and going back to the older js on your unit) resolves the problem, it may warrant further investigation.

[castillofrancodamian]

@castillofrancodamian if reverting the PR (and going back to the older js on your unit) resolves the problem, it may warrant further investigation.

I do not know how to do that.

[systemcrash]

Something like this in channel_analysis.js

+               if (res.vht_operation != null) {
-               /* if channel_width <= 40, refer to HT (above) for actual channel width,
-                * as vht_operation.channel_width == 40 really only means that the used
-                * bandwidth is <= 40 and could be 20 Mhz as well */
-               if (res.vht_operation != null && res.vht_operation.channel_width > 40) {

[castillofrancodamian]

Something like this in channel_analysis.js

+             if (res.vht_operation != null) {
-             /* if channel_width <= 40, refer to HT (above) for actual channel width,
-              * as vht_operation.channel_width == 40 really only means that the used
-              * bandwidth is <= 40 and could be 20 Mhz as well */
-             if (res.vht_operation != null && res.vht_operation.channel_width > 40) {

I have tried that line change and now I have both errors. The channel width is not displayed correctly and the 20 MHz channel is moved two boxes from where it should be. The PR mentioned above solved the second.

[JimMatthew]

can you use a wifi scanning tool on your phone to confirm if it sees the channel at 20 or 40 MHz when nothing is connected?

[castillofrancodamian]

can you use a wifi scanning tool on your phone to confirm if it sees the channel at 20 or 40 MHz when nothing is connected?

I already got a client that supports 5 GHz.

The test router is an Archer C60 v1 with SNAPSHOT r26631-4fdc7bb8f1. Image compiled from source including the patches that are in this PR to enable the 5 GHz radio.

config.buildinfo

``` CONFIG_TARGET_ath79=y CONFIG_TARGET_ath79_generic=y CONFIG_TARGET_ath79_generic_DEVICE_tplink_archer-c60-v1=y CONFIG_ATH10K_LEDS=y CONFIG_LUCI_LANG_es=y CONFIG_PACKAGE_ath10k-firmware-qca9888=y # CONFIG_PACKAGE_ath10k-firmware-qca9888-ct is not set CONFIG_PACKAGE_cgi-io=y CONFIG_PACKAGE_gre=y CONFIG_PACKAGE_iperf3=y # CONFIG_PACKAGE_kmod-ath10k-ct-smallbuffers is not set CONFIG_PACKAGE_kmod-ath10k-smallbuffers=y CONFIG_PACKAGE_kmod-gre=y CONFIG_PACKAGE_kmod-gre6=y # CONFIG_PACKAGE_kmod-hwmon-core is not set CONFIG_PACKAGE_kmod-ip6-tunnel=y CONFIG_PACKAGE_kmod-iptunnel=y CONFIG_PACKAGE_kmod-iptunnel6=y CONFIG_PACKAGE_libatomic=y CONFIG_PACKAGE_libiperf3=y CONFIG_PACKAGE_liblucihttp=y CONFIG_PACKAGE_liblucihttp-ucode=y CONFIG_PACKAGE_luci-app-commands=y CONFIG_PACKAGE_luci-app-firewall=y CONFIG_PACKAGE_luci-app-opkg=y CONFIG_PACKAGE_luci-base=y CONFIG_PACKAGE_luci-i18n-base-es=y CONFIG_PACKAGE_luci-i18n-commands-es=y CONFIG_PACKAGE_luci-i18n-firewall-es=y CONFIG_PACKAGE_luci-i18n-opkg-es=y CONFIG_PACKAGE_luci-light=y CONFIG_PACKAGE_luci-mod-admin-full=y CONFIG_PACKAGE_luci-mod-network=y CONFIG_PACKAGE_luci-mod-status=y CONFIG_PACKAGE_luci-mod-system=y CONFIG_PACKAGE_luci-proto-gre=y CONFIG_PACKAGE_luci-proto-ipv6=y CONFIG_PACKAGE_luci-proto-ppp=y CONFIG_PACKAGE_luci-proto-relay=y CONFIG_PACKAGE_luci-ssl=y CONFIG_PACKAGE_luci-theme-bootstrap=y CONFIG_PACKAGE_luci-theme-openwrt-2020=y CONFIG_PACKAGE_px5g-mbedtls=y CONFIG_PACKAGE_relayd=y CONFIG_PACKAGE_resolveip=y CONFIG_PACKAGE_rpcd=y CONFIG_PACKAGE_rpcd-mod-file=y CONFIG_PACKAGE_rpcd-mod-iwinfo=y CONFIG_PACKAGE_rpcd-mod-luci=y CONFIG_PACKAGE_rpcd-mod-rrdns=y CONFIG_PACKAGE_rpcd-mod-ucode=y CONFIG_PACKAGE_ucode-mod-html=y CONFIG_PACKAGE_ucode-mod-math=y CONFIG_PACKAGE_uhttpd=y CONFIG_PACKAGE_uhttpd-mod-ubus=y # CONFIG_PACKAGE_wpad-basic-mbedtls is not set CONFIG_PACKAGE_wpad-mbedtls=y ```

openwrt-ath79-generic-tplink_archer-c60-v1.manifest

``` ath10k-board-qca9888 - 20240513-r1 ath10k-firmware-qca9888 - 20240513-r1 base-files - 1602~4fdc7bb8f1 busybox - 1.36.1-r1 ca-bundle - 20240203-r1 cgi-io - 2022.08.10~901b0f04-r21 dnsmasq - 2.90-r2 dropbear - 2024.85-r1 firewall4 - 2024.05.21~4c01d1eb-r1 fstools - 2024.01.22~08cd7083-r1 fwtool - 2019.11.12~8f7fe925-r1 getrandom - 2024.04.26~85f10530-r1 gre - 13 hostapd-common - 2024.03.09~695277a5-r1 iperf3 - 3.17.1-r2 iw - 5.19-r1 iwinfo - 2024.03.23~79a96150-r1 jansson4 - 2.14-r3 jshn - 2024.03.29~eb9bcb64-r1 jsonfilter - 2024.01.23~594cfa86-r1 kernel - 6.6.32~b4d36a11373e7247bc1ce59afccbba2c-r1 kmod-ath - 6.6.32.6.6.15-r2 kmod-ath10k-smallbuffers - 6.6.32.6.6.15-r2 kmod-ath9k - 6.6.32.6.6.15-r2 kmod-ath9k-common - 6.6.32.6.6.15-r2 kmod-cfg80211 - 6.6.32.6.6.15-r2 kmod-crypto-aead - 6.6.32-r1 kmod-crypto-ccm - 6.6.32-r1 kmod-crypto-cmac - 6.6.32-r1 kmod-crypto-crc32c - 6.6.32-r1 kmod-crypto-ctr - 6.6.32-r1 kmod-crypto-gcm - 6.6.32-r1 kmod-crypto-geniv - 6.6.32-r1 kmod-crypto-gf128 - 6.6.32-r1 kmod-crypto-ghash - 6.6.32-r1 kmod-crypto-hash - 6.6.32-r1 kmod-crypto-hmac - 6.6.32-r1 kmod-crypto-manager - 6.6.32-r1 kmod-crypto-null - 6.6.32-r1 kmod-crypto-rng - 6.6.32-r1 kmod-crypto-seqiv - 6.6.32-r1 kmod-crypto-sha3 - 6.6.32-r1 kmod-crypto-sha512 - 6.6.32-r1 kmod-gpio-button-hotplug - 6.6.32-r3 kmod-gre - 6.6.32-r1 kmod-gre6 - 6.6.32-r1 kmod-ip6-tunnel - 6.6.32-r1 kmod-iptunnel - 6.6.32-r1 kmod-iptunnel6 - 6.6.32-r1 kmod-lib-crc-ccitt - 6.6.32-r1 kmod-lib-crc32c - 6.6.32-r1 kmod-mac80211 - 6.6.32.6.6.15-r2 kmod-nf-conntrack - 6.6.32-r1 kmod-nf-conntrack6 - 6.6.32-r1 kmod-nf-flow - 6.6.32-r1 kmod-nf-log - 6.6.32-r1 kmod-nf-log6 - 6.6.32-r1 kmod-nf-nat - 6.6.32-r1 kmod-nf-reject - 6.6.32-r1 kmod-nf-reject6 - 6.6.32-r1 kmod-nfnetlink - 6.6.32-r1 kmod-nft-core - 6.6.32-r1 kmod-nft-fib - 6.6.32-r1 kmod-nft-nat - 6.6.32-r1 kmod-nft-offload - 6.6.32-r1 kmod-ppp - 6.6.32-r1 kmod-pppoe - 6.6.32-r1 kmod-pppox - 6.6.32-r1 kmod-random-core - 6.6.32-r1 kmod-slhc - 6.6.32-r1 libatomic1 - 13.3.0-r4 libblobmsg-json20240329 - 2024.03.29~eb9bcb64-r1 libc - 1.2.5-r4 libgcc1 - 13.3.0-r4 libiperf3 - 3.17.1-r2 libiwinfo-data - 2024.03.23~79a96150-r1 libiwinfo20230701 - 2024.03.23~79a96150-r1 libjson-c5 - 0.17-r1 libjson-script20240329 - 2024.03.29~eb9bcb64-r1 liblucihttp-ucode - 2023.03.15~9b5b683f-r1 liblucihttp0 - 2023.03.15~9b5b683f-r1 libmbedtls21 - 3.6.0-r1 libmnl0 - 1.0.5-r1 libnftnl11 - 1.2.6-r1 libnl-tiny1 - 2023.12.05~965c4bf4-r1 libpthread - 1.2.5-r4 libubox20240329 - 2024.03.29~eb9bcb64-r1 libubus20231128 - 2023.11.28~f84eb599-r1 libuci20130104 - 2023.08.10~5781664d-r1 libuclient20201210 - 2024.04.19~e8780fa7-r1 libucode20230711 - 2024.05.09~0d823e70-r1 libudebug - 2023.12.06~6d3f51f9 libustream-mbedtls20201210 - 2024.04.19~524a76e5-r1 logd - 2024.04.26~85f10530-r1 luci-app-commands - 24.148.86114~fbbfdb4 luci-app-firewall - 24.148.86114~fbbfdb4 luci-app-opkg - 24.148.86114~fbbfdb4 luci-base - 24.158.03388~a6f8361 luci-i18n-base-es - 24.163.67634~860b321 luci-i18n-commands-es - 24.148.74106~ea6ac8b luci-i18n-firewall-es - 24.159.54210~5292eff luci-i18n-opkg-es - 24.159.54210~5292eff luci-light - 24.029.49472~fed7a5c luci-mod-admin-full - 24.029.49472~fed7a5c luci-mod-network - 24.149.31337~7226e13 luci-mod-status - 24.141.29261~e7f2e6b luci-mod-system - 24.165.47464~37ea60d luci-proto-gre - 24.079.44556~02fc28d luci-proto-ipv6 - 24.148.86114~fbbfdb4 luci-proto-ppp - 24.148.86114~fbbfdb4 luci-proto-relay - 24.148.86114~fbbfdb4 luci-ssl - 24.029.49472~fed7a5c luci-theme-bootstrap - 24.123.27749~3e967fd luci-theme-openwrt-2020 - 24.079.45461~be212dd mtd - 26 netifd - 2024.01.04~f01345ec-r1 nftables-json - 1.0.9-r1 odhcp6c - 2023.05.12~bcd28363-r20 odhcpd-ipv6only - 2024.05.08~a2988231-r1 openwrt-keyring - 2022.03.25~62471e69-r2 opkg - 2022.02.24~d038e5b6-r2 ppp - 2.4.9_git20210104-r5 ppp-mod-pppoe - 2.4.9_git20210104-r5 procd - 2024.03.30~946552a7-r1 procd-seccomp - 2024.03.30~946552a7-r1 procd-ujail - 2024.03.30~946552a7-r1 px5g-mbedtls - 10 relayd - 2023.01.28~f646ba40-r1 resolveip - 2 rpcd - 2024.02.22~8ef4c258-r1 rpcd-mod-file - 2024.02.22~8ef4c258-r1 rpcd-mod-iwinfo - 2024.02.22~8ef4c258-r1 rpcd-mod-luci - 20240305-r1 rpcd-mod-rrdns - 20170710 rpcd-mod-ucode - 2024.02.22~8ef4c258-r1 swconfig - 12 uboot-envtools - 2024.01-r3 ubox - 2024.04.26~85f10530-r1 ubus - 2023.11.28~f84eb599-r1 ubusd - 2023.11.28~f84eb599-r1 uci - 2023.08.10~5781664d-r1 uclient-fetch - 2024.04.19~e8780fa7-r1 ucode - 2024.05.09~0d823e70-r1 ucode-mod-fs - 2024.05.09~0d823e70-r1 ucode-mod-html - 1 ucode-mod-math - 2024.05.09~0d823e70-r1 ucode-mod-nl80211 - 2024.05.09~0d823e70-r1 ucode-mod-rtnl - 2024.05.09~0d823e70-r1 ucode-mod-ubus - 2024.05.09~0d823e70-r1 ucode-mod-uci - 2024.05.09~0d823e70-r1 ucode-mod-uloop - 2024.05.09~0d823e70-r1 uhttpd - 2023.06.25~34a8a74d-r3 uhttpd-mod-ubus - 2023.06.25~34a8a74d-r3 urandom-seed - 3 urngd - 2023.11.01~44365eb1-r1 usign - 2020.05.23~f1f65026-r1 wifi-scripts - 1.0-r1 wireless-regdb - 2024.05.08-r1 wpad-mbedtls - 2024.03.09~695277a5-r1 ```

cat /etc/config/wireless

``` root@OpenWrt:~# cat /etc/config/wireless config wifi-device '5g' option type 'mac80211' option path 'pci0000:00/0000:00:00.0' option channel '100' option band '5g' option htmode 'VHT40' option country 'US' option cell_density '0' config wifi-iface '5g_fdc' option device '5g' option network 'lan' option mode 'ap' option ssid 'FDC' option encryption 'psk2+ccmp' option ifname '5g_fdc' option macaddr 'random' option key 'password' config wifi-device '2g' option type 'mac80211' option path 'platform/ahb/18100000.wmac' option channel '1' option band '2g' option htmode 'HT20' option disabled '1' option country 'US' option cell_density '0' ```

iw dev

``` root@OpenWrt:~# iw dev phy#0 Interface 5g_fdc ifindex 12 wdev 0x1 addr 96:e7:f7:66:b0:82 ssid FDC type AP channel 100 (5500 MHz), width: 40 MHz, center1: 5510 MHz txpower 24.00 dBm multicast TXQ: qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets 0 0 35 0 0 0 0 8994 35 ```

iw reg get

``` root@OpenWrt:~# iw reg get global country US: DFS-FCC (902 - 904 @ 2), (N/A, 30), (N/A) (904 - 920 @ 16), (N/A, 30), (N/A) (920 - 928 @ 8), (N/A, 30), (N/A) (2400 - 2472 @ 40), (N/A, 30), (N/A) (5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW (5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW (5470 - 5730 @ 160), (N/A, 24), (0 ms), DFS (5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW (5850 - 5895 @ 40), (N/A, 27), (N/A), NO-OUTDOOR, AUTO-BW, PASSIVE-SCAN (5925 - 7125 @ 320), (N/A, 12), (N/A), NO-OUTDOOR, PASSIVE-SCAN (57240 - 71000 @ 2160), (N/A, 40), (N/A) phy#1 country US: DFS-FCC (902 - 904 @ 2), (N/A, 30), (N/A) (904 - 920 @ 16), (N/A, 30), (N/A) (920 - 928 @ 8), (N/A, 30), (N/A) (2400 - 2472 @ 40), (N/A, 30), (N/A) (5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW (5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW (5470 - 5730 @ 160), (N/A, 24), (0 ms), DFS (5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW (5850 - 5895 @ 40), (N/A, 27), (N/A), NO-OUTDOOR, AUTO-BW, PASSIVE-SCAN (5925 - 7125 @ 320), (N/A, 12), (N/A), NO-OUTDOOR, PASSIVE-SCAN (57240 - 71000 @ 2160), (N/A, 40), (N/A) phy#0 country US: DFS-FCC (902 - 904 @ 2), (N/A, 30), (N/A) (904 - 920 @ 16), (N/A, 30), (N/A) (920 - 928 @ 8), (N/A, 30), (N/A) (2400 - 2472 @ 40), (N/A, 30), (N/A) (5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW (5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW (5470 - 5730 @ 160), (N/A, 24), (0 ms), DFS (5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW (5850 - 5895 @ 40), (N/A, 27), (N/A), NO-OUTDOOR, AUTO-BW, PASSIVE-SCAN (5925 - 7125 @ 320), (N/A, 12), (N/A), NO-OUTDOOR, PASSIVE-SCAN (57240 - 71000 @ 2160), (N/A, 40), (N/A) ```

Scanning 5 GHz Wi-Fi networks from a Moto G5.

App WiFiman. In the first screenshot you can see the graph of the "FDC" test network. In the second screenshot you can see another 80 MHz network to compare and see that it is twice as wide as the test network.

App WiFi Data. You can observe the same previous result as with WiFiman. The width of the channel is correctly represented.

From a MERCUSYS MR70X v1 with OpenWrt SNAPSHOT r26581-33db914607 the channel width is incorrectly represented.

I tried with the 2.4 GHz band and the same problem occurs.

cat /etc/config/wireless

``` root@OpenWrt:~# cat /etc/config/wireless config wifi-device '5g' option type 'mac80211' option path 'pci0000:00/0000:00:00.0' option channel '100' option band '5g' option htmode 'VHT40' option country 'US' option cell_density '0' config wifi-iface '5g_fdc' option device '5g' option network 'lan' option mode 'ap' option ssid 'FDC' option encryption 'psk2+ccmp' option ifname '5g_fdc' option macaddr 'random' option key 'password' config wifi-device '2g' option type 'mac80211' option path 'platform/ahb/18100000.wmac' option channel '11' option band '2g' option htmode 'HT40' option country 'US' option cell_density '0' option noscan '1' config wifi-iface '2g_fdc' option device '2g' option mode 'ap' option ssid 'FDC' option encryption 'psk2+ccmp' option ifname '2g_fdc' option macaddr 'random' option key 'password' option network 'lan' ```

With a client connected to the test network.