channel_analysis: ReferenceError: diff is not defined

[Znevna]

Channel analysis page stuck at "Starting wireless scan...". Caught in Firefox Browser Console:

Uncaught (in promise) ReferenceError: diff is not defined
    handleScanRefresh http://192.168.70.223/luci-static/resources/view/status/channel_analysis.js?v=git-22.351.50506-a27d2db:234
    handleScanRefresh http://192.168.70.223/luci-static/resources/view/status/channel_analysis.js?v=git-22.351.50506-a27d2db:232
    promise callback*handleScanRefresh http://192.168.70.223/luci-static/resources/view/status/channel_analysis.js?v=git-22.351.50506-a27d2db:180
    step http://192.168.70.223/luci-static/resources/luci.js?v=git-22.351.50506-a27d2db:1189
    setInterval handler*start http://192.168.70.223/luci-static/resources/luci.js?v=git-22.351.50506-a27d2db:1149
    add http://192.168.70.223/luci-static/resources/luci.js?v=git-22.351.50506-a27d2db:1095
    render http://192.168.70.223/luci-static/resources/view/status/channel_analysis.js?v=git-22.351.50506-a27d2db:424
    promise callback*__init__ http://192.168.70.223/luci-static/resources/luci.js?v=git-22.351.50506-a27d2db:1945
    super http://192.168.70.223/luci-static/resources/luci.js?v=git-22.351.50506-a27d2db:299
    ClassConstructor http://192.168.70.223/luci-static/resources/luci.js?v=git-22.351.50506-a27d2db:107
    compileClass http://192.168.70.223/luci-static/resources/luci.js?v=git-22.351.50506-a27d2db:2526
    promise callback*compileClass http://192.168.70.223/luci-static/resources/luci.js?v=git-22.351.50506-a27d2db:2502
    promise callback*require http://192.168.70.223/luci-static/resources/luci.js?v=git-22.351.50506-a27d2db:2541
    instantiateView http://192.168.70.223/luci-static/resources/ui.js?v=git-22.351.50506-a27d2db:4873
    <anonymous> http://192.168.70.223/cgi-bin/luci/admin/status/channel_analysis:42
    promise callback* http://192.168.70.223/cgi-bin/luci/admin/status/channel_analysis:41
luci.js:234:6

DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='SNAPSHOT'
DISTRIB_REVISION='r21559-1e375c8fbd'
DISTRIB_TARGET='ramips/mt7621'
DISTRIB_ARCH='mipsel_24kc'
DISTRIB_DESCRIPTION='OpenWrt SNAPSHOT r21559-1e375c8fbd'
DISTRIB_TAINTS='no-all'

[dhewg]

This is a bug introduced with 75dcb097547257d654e9b7f7d58578b9210968e5, so cc @Ansuel Possible fix:

diff --git a/modules/luci-mod-status/htdocs/luci-static/resources/view/status/channel_analysis.js b/modules/luci-mod-status/htdocs/luci-static/resources/view/status/channel_analysis.js
index 9f266ebef3..a24742890d 100644
--- a/modules/luci-mod-status/htdocs/luci-static/resources/view/status/channel_analysis.js
+++ b/modules/luci-mod-status/htdocs/luci-static/resources/view/status/channel_analysis.js
@@ -230,7 +230,8 @@ return view.extend({
                    results.push(scanCache[k].data);

            results.sort(function(a, b) {
-               if (a.channel - b.channel)
+               var diff = a.channel - b.channel;
+               if (diff)
                    return diff;

                if (a.ssid < b.ssid)

[castillofrancodamian]

It doesn't work directly for me.

root@archer_c60:~# cat /etc/openwrt_release 
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='SNAPSHOT'
DISTRIB_REVISION='r21569-9b6dd57a33'
DISTRIB_TARGET='ath79/generic'
DISTRIB_ARCH='mips_24kc'
DISTRIB_DESCRIPTION='OpenWrt SNAPSHOT r21569-9b6dd57a33'
DISTRIB_TAINTS='no-all'

[hnyman]

Channel analysis page stuck at "Starting wireless scan...".

Possible fix:

The "possible fix" by @dhewg works for me.
It makes the scan to work again, instead of being stuck.

(Note that after editing the js file on the live router, you likely need to clear your browser cache before you can see the new code in use)

@ansuel , could you please look into this?

Ps. Curiously, in some conditions the "local interface" is left undrawn? Note the missing pillar here...

[dhewg]

I noticed that too, I tried to look into it but the sauce is just a mess and I keep walking away from it :P But I think it's related to the channel width "logic". HE just gets ignored, even some HT/VHT nets get the wrong width. And 6Ghz isn't supported at all. If we get #6104 there're some new ubus values which can be used to clean up some of this mess I guess.

[Ansuel]

Hi sorry I will look into this ASAP.

Il Ven 23 Dic 2022, 09:15 dhewg @.***> ha scritto:

I noticed that too, I tried to look into it but the sauce is just a mess and I keep walking away from it :P But I think it's related to the channel width "logic". HE just gets ignored, even some HT/VHT nets get the wrong width. And 6Ghz isn't supported at all. If we get #6104 https://github.com/openwrt/luci/pull/6104 there're some new ubus values which can be used to clean up some of this mess I guess.

— Reply to this email directly, view it on GitHub https://github.com/openwrt/luci/issues/6167#issuecomment-1363723135, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE2ZMQXBDVYHX7J2F4IPBMDWOVNT5ANCNFSM6AAAAAATGPW4EY . You are receiving this because you were assigned.Message ID: @.***>

[Ansuel]

@hnyman well the problem is just that the thing doesn't account for HE width channel... easy fix. Also I have the fix for this error... @dhewg for wrong width it's strange everything is from ubus and parsed. Would be good to have some sample data to repro the problem!

[dhewg]

@dhewg for wrong width it's strange everything is from ubus and parsed. Would be good to have some sample data to repro the problem!

Sure, I'll collect some data and post it here, but you're probably right and the iwinfo/ubus data is off.

One thing I noticed is that one ac/ax/b/g/n radio only has one net on the 6ghz band, channel 13, which shows up on the 2.4 tab, spanning from 0 to 14 :D

But I guess it makes sense to wait for https://github.com/openwrt/openwrt/pull/11280. That gives "band", with which this should be easy to fix. And add support for the 6ghz band. And maybe even cache scan results for one radio for all bands, so one doesn't have to rescan when switching between bands on the same radio

[dhewg]

Poked around a little, the channel widths are off if wpa_supplicant is used for scanning, because its cli/socket interface doesn't provide that info :\

So that doesn't work if there's an client or mesh connection active on that radio... If I comment the wpa_supplicant scan in iwinfo, it works, but probably only because I have additional non client/mesh nets on that radio?

Without code changes: iwinfo radio1 scan: no [V]HT properties are set, hence everything looks as 20MHz. But the props are present on iwinfo phy2 scan (where iwinfo nl80211 phyname radio1 = phy2`) because that doesn't use wpa_supplicant for me.

But that may not work everywhere too, because using phyX gets one net on that phy for scanning, which in return gets the last one returned by readdir(), so it's not guaranteed to get one non client/mesh one /o\

This is all so fragile it's frustrating...

[dhewg]

I added some iwinfo patches to https://github.com/openwrt/openwrt/pull/11280 to improve this situation. Now it prefers non-supplicant-based devices, so we get e.g. HT/VHT operation infos. This doesn't fix the bug altogether, if there's just a single supplicant based device configured for one radio, HT/VHT is of course still missing. But if there're multiple radios you get that info at least, which fixes that situation for me.