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

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=''

@knarrff Any ideas on this one?

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

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.

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.

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)

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

@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.

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) {

@systemcrash I have tried changing those lines in my build and it still shows the network as if it were 20 MHz.

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.

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?

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 - <IP_ADDRESS>.6.15-r2
kmod-ath10k-smallbuffers - <IP_ADDRESS>.6.15-r2
kmod-ath9k - <IP_ADDRESS>.6.15-r2
kmod-ath9k-common - <IP_ADDRESS>.6.15-r2
kmod-cfg80211 - <IP_ADDRESS>.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 - <IP_ADDRESS>.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.

@castillofrancodamian Execute these two commands on the console and paste the output:
iw dev <netwirk interface name> scan
iwinfo <network interface name> scan

@castillofrancodamian Execute these two commands on the console and paste the output:
iw dev <netwirk interface name> scan
iwinfo <network interface name> scan

AP on Archer C60 v1 with OpenWrt 23.05.5 r24106-10cc5fcd00
root@archer-c60:~# 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 cell_density '1'
        option country 'AR'
        option country_ie '1'
        option require_mode 'n'

config wifi-device '2g'
        option type 'mac80211'
        option path 'platform/ahb/18100000.wmac'
        option channel '11'
        option band '2g'
        option cell_density '1'
        option country 'AR'
        option disabled '0'
        option hwmode '11g'
        option htmode 'HT20'
        option country_ie '1'
        option require_mode 'n'

config wifi-iface 'wifinet0'
        option device '5g'
        option mode 'ap'
        option ssid 'OpenWrt'
        option encryption 'none'
        option network 'lan'

Scanning from an MR70X v1 with OpenWrt SNAPSHOT r27910-1dc86af356
root@mr70x:~# iw dev phy1 scan
command failed: No such device (-19)
root@mr70x:~# iwinfo phy1 scan
Cell 01 - Address: 50:C7:BF:75:81:AF
          ESSID: "OpenWrt"
          Mode: Master  Frequency: 5.500 GHz  Band: 5 GHz  Channel: 100
          Signal: -34 dBm  Quality: 70/70
          Encryption: none
          HT Operation:
                    Primary Channel: 100
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 102
                    Center Frequency 2: 0
                    Channel Width: 20 or 40 MHz

Cell 02 - Address: 78:8A:20:18:05:E0
          ESSID: unknown
          Mode: Master  Frequency: 5.240 GHz  Band: 5 GHz  Channel: 48
          Signal: -92 dBm  Quality: 18/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 48
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher
          VHT Operation:
                    Center Frequency 1: 48
                    Center Frequency 2: 0
                    Channel Width: 20 or 40 MHz

Cell 03 - Address: 6C:55:E8:BF:DE:A8
          ESSID: "Personal-551"
          Mode: Master  Frequency: 5.260 GHz  Band: 5 GHz  Channel: 52
          Signal: -61 dBm  Quality: 49/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 52
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 58
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 04 - Address: F4:92:BF:F0:10:B9
          ESSID: unknown
          Mode: Master  Frequency: 5.300 GHz  Band: 5 GHz  Channel: 60
          Signal: -93 dBm  Quality: 17/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 60
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher
          VHT Operation:
                    Center Frequency 1: 60
                    Center Frequency 2: 0
                    Channel Width: 20 or 40 MHz

Cell 05 - Address: A0:39:EE:B0:C8:27
          ESSID: "Fibertel WiFi690 5.8GHz"
          Mode: Master  Frequency: 5.500 GHz  Band: 5 GHz  Channel: 100
          Signal: -89 dBm  Quality: 21/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 100
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 106
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 06 - Address: 8C:FD:DE:90:A1:EB
          ESSID: "Fibertel WiFi008. 5.8GHz"
          Mode: Master  Frequency: 5.660 GHz  Band: 5 GHz  Channel: 132
          Signal: -78 dBm  Quality: 32/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 132
                    Secondary Channel Offset: above
                    Channel Width: 40 MHz or higher
          VHT Operation:
                    Center Frequency 1: 138
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 07 - Address: 20:B8:2B:2D:E5:0A
          ESSID: "Telecentro-e504"
          Mode: Master  Frequency: 5.745 GHz  Band: 5 GHz  Channel: 149
          Signal: -93 dBm  Quality: 17/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 149
                    Secondary Channel Offset: above
                    Channel Width: 40 MHz or higher
          VHT Operation:
                    Center Frequency 1: 155
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 08 - Address: 22:B8:2B:2D:E7:0C
          ESSID: "TeleCentro Wifi"
          Mode: Master  Frequency: 5.745 GHz  Band: 5 GHz  Channel: 149
          Signal: -93 dBm  Quality: 17/70
          Encryption: none
          HT Operation:
                    Primary Channel: 149
                    Secondary Channel Offset: above
                    Channel Width: 40 MHz or higher
          VHT Operation:
                    Center Frequency 1: 155
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 09 - Address: 22:B8:2B:2D:E7:0E
          ESSID: unknown
          Mode: Master  Frequency: 5.745 GHz  Band: 5 GHz  Channel: 149
          Signal: -95 dBm  Quality: 15/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 149
                    Secondary Channel Offset: above
                    Channel Width: 40 MHz or higher
          VHT Operation:
                    Center Frequency 1: 155
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 10 - Address: 22:B8:2B:30:96:D9
          ESSID: "TeleCentro Wifi"
          Mode: Master  Frequency: 5.745 GHz  Band: 5 GHz  Channel: 149
          Signal: -69 dBm  Quality: 41/70
          Encryption: none
          HT Operation:
                    Primary Channel: 149
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 155
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 11 - Address: 22:B8:2B:30:96:DB
          ESSID: unknown
          Mode: Master  Frequency: 5.745 GHz  Band: 5 GHz  Channel: 149
          Signal: -69 dBm  Quality: 41/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 149
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 155
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 12 - Address: 20:B8:2B:30:94:DF
          ESSID: "Telecentro-94d9"
          Mode: Master  Frequency: 5.745 GHz  Band: 5 GHz  Channel: 149
          Signal: -70 dBm  Quality: 40/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 149
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 155
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 13 - Address: DA:D7:75:ED:72:81
          ESSID: "TeleCentro Wifi"
          Mode: Master  Frequency: 5.745 GHz  Band: 5 GHz  Channel: 149
          Signal: -94 dBm  Quality: 16/70
          Encryption: none
          HT Operation:
                    Primary Channel: 149
                    Secondary Channel Offset: above
                    Channel Width: 40 MHz or higher
          VHT Operation:
                    Center Frequency 1: 155
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 14 - Address: F8:08:4F:7E:3E:EB
          ESSID: "Teleisa-5G"
          Mode: Master  Frequency: 5.785 GHz  Band: 5 GHz  Channel: 157
          Signal: -82 dBm  Quality: 28/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 157
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 155
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 15 - Address: FA:08:4F:7E:3F:EC
          ESSID: unknown
          Mode: Master  Frequency: 5.785 GHz  Band: 5 GHz  Channel: 157
          Signal: -82 dBm  Quality: 28/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 157
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 155
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 16 - Address: FA:08:4F:7E:3F:ED
          ESSID: "TeleCentro Wifi"
          Mode: Master  Frequency: 5.785 GHz  Band: 5 GHz  Channel: 157
          Signal: -82 dBm  Quality: 28/70
          Encryption: none
          HT Operation:
                    Primary Channel: 157
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 155
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

On the provided scan, I can't see the network with SSID wifinet0 and wifinet1. Maybe it is truncated?

It looks like some APs present support for 40MHz as a 20MHz channel with secondary channel set to above or below. I don't know yet if this is a standard or a workaround.

It looks like some APs present support for 40MHz as a 20MHz channel with secondary channel set to above or below. I don't know yet if this is a standard or a workaround.

I have updated the previous comment with the information with or without clients connected to the AP.

Test this patch if you can: https://github.com/abajk/luci/commit/6260489fad4efc7573b5b97d3ff3d83211d783e6

I have tested your commit https://github.com/abajk/luci/commit/6260489fad4efc7573b5b97d3ff3d83211d783e6 and it seems to work as expected. The 40 MHz channels can be seen on both 2.4 and 5 GHz without having any clients connected on the test AP.
[franco@pc openwrt]$ awk 'NR==290, NR==310' feeds/luci/modules/luci-mod-status/htdocs/luci-static/resources/view/status/channel_analysis.js
                                if (chan_analysis.offset_tbl[res.channel] == null)
                                        continue;

                                res.channel_width = "20 MHz";
                                if (res.ht_operation != null)
                                        if (res.ht_operation.secondary_channel_offset == "below") {
                                                res.channel_width = "40 MHz";
                                                chan_width = 4; /* 40 MHz Channel Used */
                                                center_channels[0] -= 2;
                                        } else if (res.ht_operation.secondary_channel_offset == "above") {
                                                res.channel_width = "40 MHz";
                                                chan_width = 4; /* 40 MHz Channel Used */
                                                center_channels[0] += 2;
                                        } else {
                                                if (res.ht_operation.channel_width == 2040) { /* 40 MHz Channel Enabled */
                                                        res.channel_width = "20 MHz (40 MHz Intolerant)";
                                                }
                                        }

                                        /* if channel_width <= 40, refer to HT (above) for actual channel width,
                                         * as vht_operation.channel_width == 40 really only means that the used

Scan from MR70X with OpenWrt SNAPSHOT r28041-a7bc6bf7db.
iwinfo phy0 scan

root@OpenWrt:~# iwinfo phy0 scan
Cell 01 - Address: E4:C0:E2:95:2A:B8
          ESSID: "Correntino Wifi 2.4 Ghz"
          Mode: Master  Frequency: 2.437 GHz  Band: 2.4 GHz  Channel: 6
          Signal: -83 dBm  Quality: 27/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 6
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 02 - Address: FA:08:4F:7E:40:EB
          ESSID: "TeleCentro Wifi"
          Mode: Master  Frequency: 2.437 GHz  Band: 2.4 GHz  Channel: 6
          Signal: -65 dBm  Quality: 45/70
          Encryption: none
          HT Operation:
                    Primary Channel: 6
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 03 - Address: F8:08:4F:7E:3E:EA
          ESSID: "Teleisa"
          Mode: Master  Frequency: 2.437 GHz  Band: 2.4 GHz  Channel: 6
          Signal: -64 dBm  Quality: 46/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 6
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 04 - Address: 6C:55:E8:BF:DE:A0
          ESSID: "Personal-551"
          Mode: Master  Frequency: 2.462 GHz  Band: 2.4 GHz  Channel: 11
          Signal: -73 dBm  Quality: 37/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 11
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 05 - Address: 40:3F:8C:DD:CC:24
          ESSID: "TP-Link_CC24"
          Mode: Master  Frequency: 2.462 GHz  Band: 2.4 GHz  Channel: 11
          Signal: -68 dBm  Quality: 42/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 11
                    Secondary Channel Offset: no secondary
                    Channel Width: 20 MHz

Cell 06 - Address: BA:D9:4D:68:77:15
          ESSID: "TeleCentro Wifi"
          Mode: Master  Frequency: 2.462 GHz  Band: 2.4 GHz  Channel: 11
          Signal: -72 dBm  Quality: 38/70
          Encryption: none
          HT Operation:
                    Primary Channel: 11
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 07 - Address: 6E:55:E8:BF:DE:A4
          ESSID: "Personal Wifi Zone"
          Mode: Master  Frequency: 2.462 GHz  Band: 2.4 GHz  Channel: 11
          Signal: -73 dBm  Quality: 37/70
          Encryption: none
          HT Operation:
                    Primary Channel: 11
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 08 - Address: 50:C7:BF:75:81:B0
          ESSID: "OpenWrt"
          Mode: Master  Frequency: 2.472 GHz  Band: 2.4 GHz  Channel: 13
          Signal: -37 dBm  Quality: 70/70
          Encryption: none
          HT Operation:
                    Primary Channel: 13
                    Secondary Channel Offset: below
                    Channel Width: 20 MHz

Cell 09 - Address: E6:C0:E2:94:DB:3A
          ESSID: "TeleCentro Wifi"
          Mode: Master  Frequency: 2.427 GHz  Band: 2.4 GHz  Channel: 4
          Signal: -80 dBm  Quality: 30/70
          Encryption: none
          HT Operation:
                    Primary Channel: 4
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 10 - Address: DA:A7:56:F4:F7:B2
          ESSID: "TeleCentro Wifi"
          Mode: Master  Frequency: 2.412 GHz  Band: 2.4 GHz  Channel: 1
          Signal: -93 dBm  Quality: 17/70
          Encryption: none
          HT Operation:
                    Primary Channel: 1
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 11 - Address: 8E:FD:DE:90:A2:EE
          ESSID: "Personal Wifi Zone"
          Mode: Master  Frequency: 2.412 GHz  Band: 2.4 GHz  Channel: 1
          Signal: -70 dBm  Quality: 40/70
          Encryption: none
          HT Operation:
                    Primary Channel: 1
                    Secondary Channel Offset: no secondary
                    Channel Width: 20 MHz

Cell 12 - Address: A2:39:EE:B0:C9:2A
          ESSID: "Personal Wifi Zone"
          Mode: Master  Frequency: 2.437 GHz  Band: 2.4 GHz  Channel: 6
          Signal: -88 dBm  Quality: 22/70
          Encryption: none
          HT Operation:
                    Primary Channel: 6
                    Secondary Channel Offset: no secondary
                    Channel Width: 20 MHz

Cell 13 - Address: F6:C1:14:9C:27:4C
          ESSID: "Personal Wifi Zone"
          Mode: Master  Frequency: 2.437 GHz  Band: 2.4 GHz  Channel: 6
          Signal: -80 dBm  Quality: 30/70
          Encryption: none
          HT Operation:
                    Primary Channel: 6
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 14 - Address: F4:C1:14:9C:27:48
          ESSID: "Fibertel WiFi577 2.4GHz"
          Mode: Master  Frequency: 2.437 GHz  Band: 2.4 GHz  Channel: 6
          Signal: -80 dBm  Quality: 30/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 6
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 15 - Address: 22:B8:2B:2D:E6:0B
          ESSID: "TeleCentro Wifi"
          Mode: Master  Frequency: 2.447 GHz  Band: 2.4 GHz  Channel: 8
          Signal: -74 dBm  Quality: 36/70
          Encryption: none
          HT Operation:
                    Primary Channel: 8
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 16 - Address: FA:08:4F:7E:13:6B
          ESSID: "TeleCentro Wifi"
          Mode: Master  Frequency: 2.412 GHz  Band: 2.4 GHz  Channel: 1
          Signal: -91 dBm  Quality: 19/70
          Encryption: none
          HT Operation:
                    Primary Channel: 1
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 17 - Address: D8:A7:56:F4:F5:B1
          ESSID: "TeleCentro-f5ac"
          Mode: Master  Frequency: 2.412 GHz  Band: 2.4 GHz  Channel: 1
          Signal: -93 dBm  Quality: 17/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 1
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 18 - Address: 8C:FD:DE:90:A1:EA
          ESSID: "Fibertel WiFi008. 2.4GHz"
          Mode: Master  Frequency: 2.412 GHz  Band: 2.4 GHz  Channel: 1
          Signal: -70 dBm  Quality: 40/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 1
                    Secondary Channel Offset: no secondary
                    Channel Width: 20 MHz

Cell 19 - Address: 20:9A:7D:A7:0D:D0
          ESSID: "Telecentro-0dcb"
          Mode: Master  Frequency: 2.432 GHz  Band: 2.4 GHz  Channel: 5
          Signal: -90 dBm  Quality: 20/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 5
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 20 - Address: 74:3A:EF:9D:D7:3E
          ESSID: "TeleRed-d73b"
          Mode: Master  Frequency: 2.412 GHz  Band: 2.4 GHz  Channel: 1
          Signal: -79 dBm  Quality: 31/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 1
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 21 - Address: AC:84:C6:D1:CF:08
          ESSID: "GTS"
          Mode: Master  Frequency: 2.427 GHz  Band: 2.4 GHz  Channel: 4
          Signal: -88 dBm  Quality: 22/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 4
                    Secondary Channel Offset: above
                    Channel Width: 40 MHz or higher

Cell 22 - Address: A4:22:49:AE:9D:34
          ESSID: "Telecentro-9d2f"
          Mode: Master  Frequency: 2.427 GHz  Band: 2.4 GHz  Channel: 4
          Signal: -89 dBm  Quality: 21/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 4
                    Secondary Channel Offset: no secondary
                    Channel Width: 20 MHz

Cell 23 - Address: 20:B8:2B:30:94:DE
          ESSID: "Telecentro-94d9"
          Mode: Master  Frequency: 2.432 GHz  Band: 2.4 GHz  Channel: 5
          Signal: -69 dBm  Quality: 41/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 5
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 24 - Address: 44:D4:54:B7:85:86
          ESSID: "Fibertel WiFi008 2.4GHz"
          Mode: Master  Frequency: 2.437 GHz  Band: 2.4 GHz  Channel: 6
          Signal: -87 dBm  Quality: 23/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 6
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 25 - Address: 20:B8:2B:2D:E5:09
          ESSID: "Telecentro-e504"
          Mode: Master  Frequency: 2.447 GHz  Band: 2.4 GHz  Channel: 8
          Signal: -74 dBm  Quality: 36/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 8
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 26 - Address: B8:D9:4D:68:75:14
          ESSID: "TeleCentro-750f"
          Mode: Master  Frequency: 2.462 GHz  Band: 2.4 GHz  Channel: 11
          Signal: -73 dBm  Quality: 37/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 11
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 27 - Address: E6:C0:E2:95:2B:BC
          ESSID: "Personal Wifi Zone"
          Mode: Master  Frequency: 2.437 GHz  Band: 2.4 GHz  Channel: 6
          Signal: -83 dBm  Quality: 27/70
          Encryption: none
          HT Operation:
                    Primary Channel: 6
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 28 - Address: 58:2F:F7:95:4C:91
          ESSID: "Personal-C8C 2.4Ghz"
          Mode: Master  Frequency: 2.437 GHz  Band: 2.4 GHz  Channel: 6
          Signal: -94 dBm  Quality: 16/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 6
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 29 - Address: F6:CF:A2:F5:2F:76
          ESSID: "DX CONTROL"
          Mode: Master  Frequency: 2.412 GHz  Band: 2.4 GHz  Channel: 1
          Signal: -93 dBm  Quality: 17/70
          Encryption: none
          HT Operation:
                    Primary Channel: 0
                    Secondary Channel Offset: no secondary
                    Channel Width: 20 MHz

Cell 30 - Address: D8:D7:75:ED:71:86
          ESSID: "TeleCentro-7181"
          Mode: Master  Frequency: 2.412 GHz  Band: 2.4 GHz  Channel: 1
          Signal: -81 dBm  Quality: 29/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 1
                    Secondary Channel Offset: no secondary
                    Channel Width: 20 MHz

Cell 31 - Address: DA:D7:75:ED:73:87
          ESSID: "TeleCentro Wifi"
          Mode: Master  Frequency: 2.412 GHz  Band: 2.4 GHz  Channel: 1
          Signal: -81 dBm  Quality: 29/70
          Encryption: none
          HT Operation:
                    Primary Channel: 1
                    Secondary Channel Offset: no secondary
                    Channel Width: 20 MHz

Cell 32 - Address: A6:22:49:AE:9E:36
          ESSID: "TeleCentro Wifi"
          Mode: Master  Frequency: 2.427 GHz  Band: 2.4 GHz  Channel: 4
          Signal: -91 dBm  Quality: 19/70
          Encryption: none
          HT Operation:
                    Primary Channel: 4
                    Secondary Channel Offset: no secondary
                    Channel Width: 20 MHz

Cell 33 - Address: E4:C0:E2:94:DA:38
          ESSID: "Telecentro-da33"
          Mode: Master  Frequency: 2.427 GHz  Band: 2.4 GHz  Channel: 4
          Signal: -80 dBm  Quality: 30/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 4
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 34 - Address: EC:BE:DD:A6:59:C8
          ESSID: "TeleCentro-59c3"
          Mode: Master  Frequency: 2.437 GHz  Band: 2.4 GHz  Channel: 6
          Signal: -88 dBm  Quality: 22/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 6
                    Secondary Channel Offset: no secondary
                    Channel Width: 20 MHz

Cell 35 - Address: 4A:29:52:3F:26:6B
          ESSID: "Personal Wifi Zone"
          Mode: Master  Frequency: 2.437 GHz  Band: 2.4 GHz  Channel: 6
          Signal: -90 dBm  Quality: 20/70
          Encryption: none
          HT Operation:
                    Primary Channel: 6
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher

Cell 36 - Address: 5A:2F:F7:0D:60:70
          ESSID: "Personal Wifi Zone"
          Mode: Master  Frequency: 2.462 GHz  Band: 2.4 GHz  Channel: 11
          Signal: -93 dBm  Quality: 17/70
          Encryption: none
          HT Operation:
                    Primary Channel: 11
                    Secondary Channel Offset: no secondary
                    Channel Width: 20 MHz

Cell 37 - Address: 58:2F:F7:0D:5F:74
          ESSID: "vence Herrera 2.4"
          Mode: Master  Frequency: 2.462 GHz  Band: 2.4 GHz  Channel: 11
          Signal: -93 dBm  Quality: 17/70
          Encryption: mixed WPA/WPA2 PSK (TKIP, CCMP)
          HT Operation:
                    Primary Channel: 11
                    Secondary Channel Offset: no secondary
                    Channel Width: 20 MHz

iwinfo phy1 scan

root@OpenWrt:~# iwinfo phy1 scan
Cell 01 - Address: 6C:55:E8:BF:DE:A8
          ESSID: "Personal-551"
          Mode: Master  Frequency: 5.260 GHz  Band: 5 GHz  Channel: 52
          Signal: -61 dBm  Quality: 49/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 52
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 58
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 02 - Address: A0:39:EE:B0:C8:27
          ESSID: "Fibertel WiFi690 5.8GHz"
          Mode: Master  Frequency: 5.500 GHz  Band: 5 GHz  Channel: 100
          Signal: -90 dBm  Quality: 20/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 100
                    Secondary Channel Offset: no secondary
                    Channel Width: 40 MHz or higher
          VHT Operation:
                    Center Frequency 1: 100
                    Center Frequency 2: 0
                    Channel Width: 20 or 40 MHz

Cell 03 - Address: 50:C7:BF:75:81:AF
          ESSID: "OpenWrt"
          Mode: Master  Frequency: 5.580 GHz  Band: 5 GHz  Channel: 116
          Signal: -35 dBm  Quality: 70/70
          Encryption: none
          HT Operation:
                    Primary Channel: 116
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 118
                    Center Frequency 2: 0
                    Channel Width: 20 or 40 MHz

Cell 04 - Address: 8C:FD:DE:90:A1:EB
          ESSID: "Fibertel WiFi008. 5.8GHz"
          Mode: Master  Frequency: 5.660 GHz  Band: 5 GHz  Channel: 132
          Signal: -75 dBm  Quality: 35/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 132
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 138
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 05 - Address: 22:B8:2B:30:96:D9
          ESSID: "TeleCentro Wifi"
          Mode: Master  Frequency: 5.745 GHz  Band: 5 GHz  Channel: 149
          Signal: -80 dBm  Quality: 30/70
          Encryption: none
          HT Operation:
                    Primary Channel: 149
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 155
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 06 - Address: 22:B8:2B:30:96:DB
          ESSID: unknown
          Mode: Master  Frequency: 5.745 GHz  Band: 5 GHz  Channel: 149
          Signal: -80 dBm  Quality: 30/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 149
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 155
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 07 - Address: 20:B8:2B:30:94:DF
          ESSID: "Telecentro-94d9"
          Mode: Master  Frequency: 5.745 GHz  Band: 5 GHz  Channel: 149
          Signal: -80 dBm  Quality: 30/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 149
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 155
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 08 - Address: F8:08:4F:7E:3E:EB
          ESSID: "Teleisa-5G"
          Mode: Master  Frequency: 5.785 GHz  Band: 5 GHz  Channel: 157
          Signal: -81 dBm  Quality: 29/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 157
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 155
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 09 - Address: FA:08:4F:7E:3F:EC
          ESSID: unknown
          Mode: Master  Frequency: 5.785 GHz  Band: 5 GHz  Channel: 157
          Signal: -81 dBm  Quality: 29/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 157
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 155
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 10 - Address: FA:08:4F:7E:3F:ED
          ESSID: "TeleCentro Wifi"
          Mode: Master  Frequency: 5.785 GHz  Band: 5 GHz  Channel: 157
          Signal: -82 dBm  Quality: 28/70
          Encryption: none
          HT Operation:
                    Primary Channel: 157
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 155
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 11 - Address: 22:B8:2B:2D:E7:0C
          ESSID: "TeleCentro Wifi"
          Mode: Master  Frequency: 5.745 GHz  Band: 5 GHz  Channel: 149
          Signal: -93 dBm  Quality: 17/70
          Encryption: none
          HT Operation:
                    Primary Channel: 149
                    Secondary Channel Offset: above
                    Channel Width: 40 MHz or higher
          VHT Operation:
                    Center Frequency 1: 155
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

Cell 12 - Address: E4:C0:E2:94:DA:39
          ESSID: "Telecentro-da33"
          Mode: Master  Frequency: 5.745 GHz  Band: 5 GHz  Channel: 149
          Signal: -94 dBm  Quality: 16/70
          Encryption: WPA2 PSK (CCMP)
          HT Operation:
                    Primary Channel: 149
                    Secondary Channel Offset: above
                    Channel Width: 20 MHz
          VHT Operation:
                    Center Frequency 1: 155
                    Center Frequency 2: 0
                    Channel Width: 80 MHz

AP C60 v1 for testing with OpenWrt 23.05.5 r24106-10cc5fcd00.
cat /etc/config/wireless

root@archer-c60:~# cat /etc/config/wireless

config wifi-device '5g'
        option type 'mac80211'
        option path 'pci0000:00/0000:00:00.0'
        option channel '116'
        option band '5g'
        option htmode 'VHT40'
        option cell_density '1'
        option country 'AR'
        option country_ie '1'
        option require_mode 'n'

config wifi-device '2g'
        option type 'mac80211'
        option path 'platform/ahb/18100000.wmac'
        option channel '13'
        option band '2g'
        option cell_density '1'
        option country 'AR'
        option hwmode '11g'
        option htmode 'HT40'
        option country_ie '1'
        option require_mode 'n'
        option noscan '1'

config wifi-iface 'wifinet0'
        option device '5g'
        option mode 'ap'
        option ssid 'OpenWrt'
        option encryption 'none'
        option network 'lan'

config wifi-iface 'wifinet1'
        option device '2g'
        option mode 'ap'
        option ssid 'OpenWrt'
        option encryption 'none'
        option network 'lan'

Great. I will open MR.

@abajk I've seen that in another commit like this you removed a line. Does it make any difference to have it like in the first commit?

@abajk I've seen that in another commit like this you removed a line. Does it make any difference to have it like in the first commit?

It doesn't make any difference.


[Proposal] Experimental mutable Failable

We've been experimenting with using MobX and it definitely shows that Failable has more room for a MobX-friendly API. The proposal is thus: make Failable more object-oriented and @observable friendly.
declare class Failable<T> {
  readonly isSuccess: boolean;
  readonly isFailure: boolean;
  readonly isPending: boolean;

  success(data: T): this;
  failure(error: Error): this;
  pending(): this;

  match<A, B, C>(options: Failable.MatchOptions<T, A, B, C>): A | B | C;

  map<U>(f: (in: T) => U): Failable<U>;
  rescue(f: (error: Error) => T): this;
}

declare namespace Failable {
  export interface MatchOptions<T, A, B, C> {
    success: (data: T) => A;
    failure: (error: Error) => B;
    pending: () => C;
  }
}

An example usage would be:
const magicNumber = new Failable<number>();
// magicNumber.isPending === true;

// declare function fetchMagic(): Promise<number>;
fetchMagic().then(
  magicNumber.success,
  magicNumber.failure
);

// some time later:
const normalizedMagicPlusOne = magicNumber.match({
  pending: () => -1,
  failure: (_error) => 0,
  success: i => i + 1
});

Another advantage this gives us is subclassability. For example, if we wanted to log every error that's funneled through a Failable, simply subclass Failable and use that instead:
export class LoggedFailable<T> extends Failable<T> {
  failure(error: Error): this {
    super.failure(error);
    Raven.logException(error);
  }
}

I think this a great idea!

I'm soliciting more feedback on two other possible abstractions. Take a look at fromPromise in mobx-utils. We can more or less replicate that functionality with the following code:
function fromPromise<T>(p: PromiseLike<T>): Failable<T> {
  const f = new Failable<T>();
  p.then(f.success, f.failure);
  return f;
}

This means in comparison to fromPromise, Failable<T> sits slightly lower in terms of abstraction level. From a composability standpoint, however, fromPromise is less useful. Suppose we have a function that already fetches a user and gives back a promise:
declare function getUser(id: string): Promise<User>;

Let's start with immutable Failable, and how you'd manage fetches with it in a store:
class UserStore {
  @observable user: Failable<User> = pending;

  @action update = (id: string) => {
    getUser(id).then(user => {
      this.user = success(user);
    }, error => {
      this.user = failure(error);
    });
  };
}

With a mutable Failable, assuming the API suggestion in the top post, this becomes much simpler:
class UserStore {
  @observable user = new Failable<User>();

  @action update = (id: string) => {
    getUser(id).then(this.user.success, this.user.failure);
  };
}

If we were to use fromPromise, it would in turn look like this:
class UserStore {
  @observable user = new Failable<User>();

  @action update = (id: string) => {
    this.user = fromPromise(getUser(id));
  };
}

This continues to work, but only if someone is observing a UserStore instance as a whole. Let store: UserStore. In MobX parlance, for the updates to be propagated, you need to observe(store) or observe(store, 'user'). Simply doing observe(store.user) will not work. (See the docs on observe for a more in-depth explanation as to how these things are different.)
My question is: is this a big enough problem that we want to tackle it? I imagine a solution to this looks like:
class SourcedFailable<T> extends Failable<T> {
  absorb(promise: PromiseLike<T>): this {
    promise.then(this.success, this.failure);
    return this;
  }
}

class UserStore {
  @observable user = new SourcedFailable<User>();

  @action update = (id: string) => {
    this.user.absorb(getUser(id));
  };
}

what is the usage in the ui like?  are we still doing
Failable.when(user, {
  pending: () => ...,
  failure: error => ...,
  success: user => ...
}```

maybe i missed this part somewhere?

The usage would look very similar:
store.user.match({
  pending: () => ...,
  failure: error => ...,
  success: user => ...
})

Closed via #17.


The links are not working and redirect to page not found

SEVERITY:  Major
MODULE: Bubble Chart
PLATFORM:

Windows 7 / Chrome 52.0

STEPS TO REPRODUCE:

Navigate to the URL: http://tools-stage.gapminderdev.org
Scroll down the page
Click on videos link

ACTUAL RESULTS:
The user redirect to page not found web page
EXPECTED RESULTS:
The user should redirect to the appropriate page
SCREENSHOT:

see the fix here https://github.com/Gapminder/vizabi/issues/1896#issuecomment-238229791


Suggestion: Possible formatting update for Ramda defs

I've only recently been made aware of Flow's leading pipe syntax:
type Foo =
  | 'bar'
  | 'baz'

Which is pretty cool. When futzing around with some other libdefs I found out this works too:
type Bar =
  & Baz
  & Qux

Right now the libdefs for ramda's partial come from this generator. I could make a small adjustment and it might make our multitude of function overrides easier to grok. We could also employ that pattern going forward for other libdefs as well.
Thoughts?
cc @AndrewSouthpaw

Totally, I tried it on for size back in #1756, and think it's a great idea for defs moving forward. I've been meaning to write it up in the contribute doc, once I get around to fixing that PR... 😅There's like four things I've been wanting to do that are all gated serially.


Video mode not restored for secondary monitor

Fedora 21: 3.17.7-300
NVidia driver 343-36
Dual 24" monitors @ 1920 x 1200, as 1 virtual desktop.
glfw 3.1.1
Tested with glfw compiled as shared library and static library.
Running the reopen test exec does not restore desktop on the non-primary monitor either when running or when closed. The primary monitor is restored OK.
I use the NVidia settings app to reset the non-primary monitor to 1920x1200 from the 640x480 that reopen uses for windowed display.
Also to note:
I had to use the NVidia app to set the monitor so that the left monitor is the primary.
On boot up one can see this setting being applied - ie the natural setup is for the right monitor to be the primary.

Please post the output of the monitors test program.

Name: DVI-I-3 (primary)
Current mode: 1920 x 1200 x 24 (8 8 8) 59 Hz
Virtual position: 0 0
Physical size: 518 x 324 mm (94 dpi)
Modes:
0: 640 x 480 x 24 (8 8 8) 59 Hz
1: 640 x 480 x 24 (8 8 8) 75 Hz
2: 800 x 600 x 24 (8 8 8) 60 Hz
3: 800 x 600 x 24 (8 8 8) 75 Hz
4: 1024 x 768 x 24 (8 8 8) 60 Hz
5: 1024 x 768 x 24 (8 8 8) 75 Hz
6: 1152 x 864 x 24 (8 8 8) 75 Hz
7: 1280 x 1024 x 24 (8 8 8) 60 Hz
8: 1280 x 1024 x 24 (8 8 8) 75 Hz
9: 1600 x 1200 x 24 (8 8 8) 60 Hz
10: 1920 x 1200 x 24 (8 8 8) 59 Hz (current mode)
Name: DVI-I-2 (secondary)
Current mode: 1920 x 1200 x 24 (8 8 8) 59 Hz
Virtual position: 1920 0
Physical size: 518 x 324 mm (94 dpi)
Modes:
0: 640 x 480 x 24 (8 8 8) 59 Hz
1: 640 x 480 x 24 (8 8 8) 75 Hz
2: 800 x 600 x 24 (8 8 8) 60 Hz
3: 800 x 600 x 24 (8 8 8) 75 Hz
4: 1024 x 768 x 24 (8 8 8) 60 Hz
5: 1024 x 768 x 24 (8 8 8) 75 Hz
6: 1152 x 864 x 24 (8 8 8) 75 Hz
7: 1280 x 1024 x 24 (8 8 8) 60 Hz
8: 1280 x 1024 x 24 (8 8 8) 75 Hz
9: 1600 x 1200 x 24 (8 8 8) 60 Hz
10: 1920 x 1200 x 24 (8 8 8) 59 Hz (current mode)

Cannot reproduce.

I've redone test and still get my original result.
However, I'm not going to pursue or investigate this.

Fair enough. I'll leave this open in case something turns up.


Create deployer user at build time

This moves the deployer user creation to build time instead of 1st boot. A post build script creates the token, but this PR doesn't alter the rc.local so it's still backwards compatible.

It's in education-builds

@binford2k https://github.com/puppetlabs/education-builds/blob/master/scripts/master_build.sh#L25


Can't add new WeChatWork webhook into Organization

Gitea Version
1.16.0+dev-339-gee73d8409
Git Version
No response
Operating System
No response
How are you running Gitea?
docker
Database
SQLite
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Description
http://host/org/ORGNAME/settings/hooks/wechatwork/new
Screenshots
No response

I have tried the page (/org/repo/settings/hooks/wechatwork/new), it can add a wechat work webhook into the repository.
You need to describe your problem more clearly. What errors do you meet? How to reproduce it?

You must provide us with logs or else we cannot help you.
We will close this issue in 14 days if you do not provide us with logs and some way to replicate your issue.

HERE IS THE REQUEST
curl 'http://MYHOST/org/MYORG/settings/hooks/wechatwork/new'
-H 'Connection: keep-alive'
-H 'Cache-Control: max-age=0'
-H 'Upgrade-Insecure-Requests: 1'
-H 'Origin: null'
-H 'Content-Type: application/x-www-form-urlencoded'
-H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4621.0 Safari/537.36'
-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9'
-H 'Accept-Language: zh-CN,zh;q=0.9,en;q=0.8'
-H 'Cookie: gitea_awesome=MYUSERNAME; gitea_incredible=a10d652b5c90bbb2319987e9a75d1e5a3c3593b342bec046a9b1c883923976ff; i_like_gitea=ce721507c1b8beb0; _csrf=Cy0StSbRBmtcLdE-kwhJSkuU_Bs6MTYzNzEzNDcxMzk2MTI4NTY3Ng'
--data-raw '_csrf=Cy0StSbRBmtcLdE-kwhJSkuU_Bs6MTYzNzEzNDcxMzk2MTI4NTY3Ng&payload_url=https%3A%2F%2Fqyapi.weixin.qq.com%2Fcgi-bin%2Fwebhook%2Fsend%3Fkey%3DMYROBOTID&events=push_only&branch_filter=*&active=on'
--compressed
--insecure
RESPONSE:
404

Sorry, the problem indeed exists, will be fixed in https://github.com/go-gitea/gitea/pull/17810


Cannot query keyboard state in linux terminal

Hi, I'm trying to use this crate in a TUI I'm developing as a way to detect key-up events but it seems to not detect anything when the terminal is in focus on Linux. Actually, it seems to not work at all unless I have certain other applications in focus--seemingly ones that aren't capturing text input. I'm not sure how to proceed.
Ubuntu 22.04.1 LTS
device_query v1.1.1

I believe Ubuntu 22.04 uses Wayland by default. This application doesn't work with Wayland. Have you installed the X11 dev libraries?
sudo apt install libx11-dev

Yes, I have.

Good news is that I'm able to reproduce the issue so I can start working on a fix. Thanks for letting me know!


Mod logs not working in saws?

Can confirm this issue. It appears along with the Hardcore Lumber fix, basic mod compat was lost for mod woods.
Currently in my instance any forestry log can be crafted normally into 4 planks.
drops a log when punched.
does not have a crafting grid axe recipe.
And does not interact with the saw in any way.
If one cannot HCLumber cannot be had with mod compat automatically, a craft tweaker recipe that adds a log to all of the above behavior would be an ideal alternative.

Looks like it's firing on preInit, causing it to miss pretty much everything.


OCPBUGS-35878: No PDBs creation on ControllerAvailability SingleReplica policy

Which issue(s) this PR fixes:
Fixes #OCPBUGS-35878

/test e2e-aws

/hold #4857 (comment)
This pdbs prevent CI from going flake because of autoscaling relocating pods. If we get rid of the PDBs we need to prevent the pods from being drained by autoscaling in CI. To that end we could e.g. use the "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" annotation can use PTAL @sjenning

Yep I already talked about this with Seth, this is still in WIP, we were thinking too in read the pod logs, check for leader election losses and also kas disruption issues. With that we can differentiate the real crashes from the not relevant ones.

/test e2e-aws


Address SignalR disconnects

Test this by turning off your internet or closing your laptop or just leaving the tab open for, like, an hour, which seems to semi-regularly disconnect me!?
Possible points of discussion:

Do we care about people leaving the tabs open forever, which will both perpetually reconnect and eat up cycles on their computer if their internet is bad? It's not many cycles, mind, but...

Oh actually I just remembered that we have a timeout - but I don't remember how it works, and also, I'm pretty sure it doesn't provide feedback to the client, which means that to the player it's invisible? uh, yeah, deserves discussion

By the time it reaches the SignalR disconnected callback you've probably already been disconnected for a good twenty, thirty seconds, and you'll drop messages in between since we have no server playback. This is...fine, right?

Awesome, this all seems reasonable!
Assuming you mean our "ping" system re: timeouts, I'm trying to remember how that works. IIRC it forcibly closes connections if the client is in a weird state where it's still connected to SignalR but isn't processing incoming messages. I'm not sure how that will or won't intersect with this (and seems separate from the question of idle clients continually trying to reconnect via this new modal)
I suspect an item to investigate for next year is shifting to Azure PubSub Service (a new similar service that uses vanilla websockets instead of SignalR, introduced in the last year), since we don't actually care about the complexity of SignalR -- we're only using SignalR because we want persistent connections to a serverless backend, which was previously only doable on Azure with SignalR Service. We're obviously not going to throw out our entire transport layer one week before the event, but calling that out here since it does seem like part of this jank is SignalR being so complex in ways that don't benefit us.


Probe Class

Closes #827

Hi there!
I have marked this issue as stale because it has not had activity for 45 days.
Consider the following options:

If the issue refers to a large task, break it in smaller issues that can be solved in
less than 45 days;
Label the issue as wontfix or wontfix for now and close it.

@raphaeltimbo, this PR is almost finished. It is lacking the tests and a few modifications that you asked for, @karenperezz is about to implement that.

@raphaeltimbo, do you think we can merge this PR, after forcing update with master.


Upcoming releases of NVIDIA HPC SDK compilers no longer support the -tp p7-64 flag

There has been a recent change to the NVIDIA HPC SDK compilers to drop support for the -tp p7-64 flag on x86_64 platforms.  This is tied to a recent decision to drop support in the compilers for any architectures that do not support at least AVX instructions, i.e. anything older than Intel Sandy Bridge.  OpenBLAS uses this flag to produce architecture-neutral object files when compiling with the HPC SDK compilers.
The preferred flag is now -tp px.
Note that the pre-AVX architecture kernels will still build with the HPC SDK compilers, but they will no longer be as useful, as the interface code may have at minimum AVX instructions in it now.
Could you update the OpenBLAS build to change -tp p7-64 to -tp px now?
I can send along a patch if needed, but this should be a fairly trivial change.  Thanks in advance.

Strange, I do not recall seeing that in the release notes, should probably prevent use of 21.9 for DYNAMIC_ARCH builds then.

This is actually a new change for the upcoming 21.11 release - sorry, I should have made that more clear up above.  I encountered it during some of our nightly testing.  I think 21.9 and earlier are fine as-is.

I was experimenting around hwcaps, but did not manage much further than copying limited dynamic_arch to respective lib dirs. Is the change matching glibc caps v3 ? https://hackweek.opensuse.org/20/projects/support-glibc-hwcaps-and-micro-architecture-package-generation

I'm not 100% sure, but I think the decision was coincidental to this.  But I would have to check with our product managers for confirmation.

This is actually a new change for the upcoming 21.11 release - sorry, I should have made that more clear up above. I encountered it during some of our nightly testing. I think 21.9 and earlier are fine as-is.

Thank you for the clarification - indeed the 21.9 nvc still accepts -tp p7-64 (now that I actually installed it) although it no longer advertises that argument in its help message.
However, what do you make of this strange ICE while compiling interface/gemm.c - is something wrong with my installation of 21.9 (on Ryzen5-4600H running OpenSUSE 15.2) or should I report this through some other channel:
nvc -DCBLAS -c -O2 -DSMALL_MATRIX_OPT -DMAX_STACK_ALLOC=2048 -tp p7-64 -DF_INTERFACE_PGI -fPIC -DSMP_SERVER -DNO_WARMUP -DMAX_CPU_NUMBER=12 -DMAX_PARALLEL_NUMBER=1 -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 -DVERSION=\"0.3.18.dev\" -msse3 -mssse3 -msse4.1 -mavx -mavx2 -DASMNAME=cblas_sgemm -DASMFNAME=cblas_sgemm_ -DNAME=cblas_sgemm_ -DCNAME=cblas_sgemm -DCHAR_NAME=\"cblas_sgemm_\" -DCHAR_CNAME=\"cblas_sgemm\" -DNO_AFFINITY -I.. -I. -UDOUBLE  -UCOMPLEX gemm.c -o cblas_sgemm.o
NVC++-F-0000-Internal compiler error. get_call_sptr(): indirect call not via LDA/ACON     154  (gemm.c: 239)
NVC++/x86-64 Linux 21.9-0: compilation aborted
make[1]: *** [Makefile:1295: sgemm.o] Error 2
make[1]: *** Waiting for unfinished jobs....
NVC++-F-0000-Internal compiler error. get_call_sptr(): indirect call not via LDA/ACON     154  (gemm.c: 438)
NVC++/x86-64 Linux 21.9-0: compilation aborted
make[1]: *** [Makefile:1883: cblas_sgemm.o] Error 2

(both source lines have trivial assignments to variables of type int, the first one is conditional, the second is literally just info =-1; , error persists with -tp px or -tp zen)

This is actually a new change for the upcoming 21.11 release - sorry, I should have made that more clear up above. I encountered it during some of our nightly testing. I think 21.9 and earlier are fine as-is.

Thank you for the clarification - indeed the 21.9 nvc still accepts -tp p7-64 (now that I actually installed it) although it no longer advertises that argument in its help message. However, what do you make of this strange ICE while compiling interface/gemm.c - is something wrong with my installation of 21.9 (on Ryzen5-4600H running OpenSUSE 15.2) or should I report this through some other channel:
nvc -DCBLAS -c -O2 -DSMALL_MATRIX_OPT -DMAX_STACK_ALLOC=2048 -tp p7-64 -DF_INTERFACE_PGI -fPIC -DSMP_SERVER -DNO_WARMUP -DMAX_CPU_NUMBER=12 -DMAX_PARALLEL_NUMBER=1 -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 -DVERSION=\"0.3.18.dev\" -msse3 -mssse3 -msse4.1 -mavx -mavx2 -DASMNAME=cblas_sgemm -DASMFNAME=cblas_sgemm_ -DNAME=cblas_sgemm_ -DCNAME=cblas_sgemm -DCHAR_NAME=\"cblas_sgemm_\" -DCHAR_CNAME=\"cblas_sgemm\" -DNO_AFFINITY -I.. -I. -UDOUBLE  -UCOMPLEX gemm.c -o cblas_sgemm.o
NVC++-F-0000-Internal compiler error. get_call_sptr(): indirect call not via LDA/ACON     154  (gemm.c: 239)
NVC++/x86-64 Linux 21.9-0: compilation aborted
make[1]: *** [Makefile:1295: sgemm.o] Error 2
make[1]: *** Waiting for unfinished jobs....
NVC++-F-0000-Internal compiler error. get_call_sptr(): indirect call not via LDA/ACON     154  (gemm.c: 438)
NVC++/x86-64 Linux 21.9-0: compilation aborted
make[1]: *** [Makefile:1883: cblas_sgemm.o] Error 2

(both source lines have trivial assignments to variables of type int, the first one is conditional, the second is literally just info =-1; , error persists with -tp px or -tp zen) Edited to add: problem persists at -O0 and with TARGET=GENERIC, i.e. just -tp px and none of the GCC-style sse and avx flags. Also when trying a cmake build, CMAKE fails to identify a usable CMAKE_ASM_COMPILER on its own, still fails when I supply nvc, but succeeds when I tell it to use gcc. I do not remember this being a problem for earlier versions of the HPC SDK.

Hi Martin - apologies for the delayed response, but I have been having some Internet connectivity problems with my ISP for the last few days.
Yes, this ICE is a known issue.  I have filed a bug report against it internally, and it should be fixed when 21.11 comes out.  Unfortunately I do not have a good workaround for this at the moment.
I have not experimented much with using CMAKE to build here, but our compilers are built on top of LLVM.  I believe nvc passes most assembly files along to the clang assembler.  We would have to dig in further here and see why it is failing here.  I have encountered a few other bugs with inline assembly in our compilers over the years, and have filed bugs internally against them.


Program tests

Testing for the program services is complete. Additionally, tests that were affected by the schema change have been fixed.

LGTM!


The feedback option should automatically start a new issue and fill in version/OS information like vscode does

Storage Explorer Version:
1.0

We also had this idea, but the consensus from above was that we should send users to the "Issues" page so they are encouraged to search for existing issues first.


[Archetype builder] Make archetype construction more lazy

Another checkpoint along the road toward lazily-constructed archetypes, which includes:

Teaching GenericEnvironment how to use an ArchetypeBuilder to lazily fill in context types, rather than computing them prior to creation of the GenericEnvironment.
Push the "create all the archetypes" logic as late as we can in ArchetypeBuilder::getGenericEnvironment(). To make it truly lazy, we need the archetype builder to persist for the life of the AST (which requires still more work)
Go through the normal substitution logic when mapping interface types to context types in the archetype builder, rather than a specialized Type::transform().
Adding a new variant of Type::subst() that uses an arbitrary callback to map substitutable types to their replacement types, which is necessary when the mapping might be lazily constructed (see GenericEnvironment's use of Type::subst().
As a bonus, the new variable of Type::subst() makes it easy to introduce alternate storage mechanisms for the substitutable type -> replacement type mapping, so use a tail-allocated flat array of context types in GenericEnvironment that is parallel with the generic parameters list.

@swift-ci  please smoke test and merge

@swift-ci please smoke test and merge

@swift-ci please smoke test and merge


Cron: don't create minutely workflow on spec error

Pre-requisites

[X] I have double-checked my configuration
[X] I have tested with the :latest image tag (i.e. quay.io/argoproj/workflow-controller:latest) and can confirm the issue still exists on :latest. If not, I have explained why, in detail, in my description below.
[X] I have searched existing issues and could not find a match for this bug
[ ] I'd like to contribute the fix myself (see contributing guide)

What happened? What did you expect to happen?
if we push new cron workflow with some errors, argo could replace it with default one dummy workflow which will run every minute
https://github.com/argoproj/argo-workflows/blob/ba75efb228fa3fbab91e2b1c7689f6db3f3c3b62/ui/src/app/shared/examples.ts#L79-L87
We need option to change this default workflow to some invalid one, to prevent unnecessary dummy jobs run.
this is noted in a comment of the 3.6 blog post but i have also noticed this
Version(s)
3.5.11
Paste a minimal workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
n/a

Logs from the workflow controller
kubectl logs -n argo deploy/workflow-controller | grep ${workflow}

Logs from in your workflow's wait container
kubectl logs -n argo -c wait -l workflows.argoproj.io/workflow=${workflow},workflow.argoproj.io/phase!=Succeeded

Could you provide further information on the exact steps to reproduce this?
I tried:

Create a bad CronWorkflow using kubectl it does not replace it with the one you linked.
Create a bad CronWorkflow using argo cli it just reports it as bad, does not submit it and does not replace it
Create a bad CronWorkflow using the web userinterface it reports it as bad in the user interface and does not submit it and does not replace it

🦀

run every minute

This is also intentional for an example, so that you can easily see it execute

metadata:
  name: d-bear3
  namespace: argo
  labels:
    example: "true"
spec:
  workflowMetadata:
    labels:
      example: "true"
  schedule: "2 2 * * *"
  workflowSpec:
    entrypoint: argosay
    arguments:
      parameters:
        - name: message
          value: hello argo
    templates:
      - name: argosay
        inputs:
          parameters:
            - name: message
              value: {{`{{workflow.parameters.message}}`}}
        container:
          name: main
          image: argoproj/argosay:v2
          command:
            - /argosay
          args:
            - echo
            - {{`{{workflow.parameters.message}}`}}
    ttlStrategy:
      secondsAfterCompletion: 300
    podGC:
      strategy: OnPodCompletion


CRITICAL: Module won't resolve on version 3.6.0

@HaithemMosbahi Latest version is broken. Unable to import the module with latest version. see the stackblitz:
https://stackblitz.com/edit/ngx-avatar-demo-zdqn85
Downgrading to 3.5.0 works.

I did a mistake when I published version 3.6.0. Thank you for raising the issue.
I just fixed it, please use version 3.7.0


Basic test

See included readme for details what is this about

We can always move it in later if it works, I prefer bazaars to cathedrals though


no response

https://github.com/rofixro/vue3-realworld-app/blob/f42c3756f6cc2281d4b28691672d5a3f2cabac44/src/utils/request.ts#L22
in this code, is there any response as a return value?

https://github.com/rofixro/vue3-realworld-app/blob/f42c3756f6cc2281d4b28691672d5a3f2cabac44/src/utils/request.ts#L22
在这段代码中，是否有任何响应作为返回值？

Yes, there is a return value in the success case. The interceptor returns data from the response object. In the error case, it doesn't return a response, but rejects a Promise with error information.


Server crashes when using wire cutters

Upon using wire cutters on any type of wired fence in survival, the server crashes with a nosuchmethoderror. Probably due to a reference to non-server code.
Notably the crash does not occur in creative mode.

Crash would be useful but your most likely right.

https://gist.github.com/Hennamann/c13151ec76aed78c6f2f1adf0fcc2d9a

Block.getItem(World, int, int, int) is a client side only method
https://github.com/BuiltBrokenModding/MilitaryBaseDecor/blob/master/src/main/java/com/builtbroken/militarybasedecor/modules/worldwar1/content/block/BlockWireFence.java#L94

Yup noticed that as well, changing it to Item.getitemfromblock instead, just need to work metadata into it.

no, just pass in 'this'. The ItemStack constructor can take a block as a param.

That's true, I'll test it and then commit the changes


Add Collection API to Replicator (No Impl)

Added Collection API to Replicator without implementation.

Deprecate the old API will be done separately.

CBL-3186


feat(docker): integrate cuda/no-cuda jobs into single job

Description
Resolved #5082
As a result of the activity https://github.com/autowarefoundation/autoware.universe/issues/8695, the only packages dependent on CUDA are the sensing/perception components of autoware.universe. Therefore, the container images with the -cuda suffix are actually only needed for universe-sensing-perception-devel and universe-sensing-perception.
Additionally, since there is currently only one arm64 self-hosted runner, the no-cuda/cuda jobs in the docker-build-and-push-arm64 workflow experience double the waiting time.
This PR consolidates the no-cuda/cuda jobs and changes the process so that only the CUDA dependent packages in the sensing/perception component are built in an additional stage.

Tests performed
https://github.com/autowarefoundation/autoware/actions/runs/11718481450
https://github.com/autowarefoundation/autoware/actions/runs/11718483615
Effects on system behavior

Not applicable.
Interface changes

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

@oguzkaganozt Please review this.
I'm not sure but https://github.com/autowarefoundation/autoware/actions/runs/11489943171 was failed. It is likely that the build cache has become corrupted. I think the issue can be resolved by clearing the build cache and re-running the process.
@xmfcx @mitsudome-r  Could you please clear the build cache?
https://github.com/autowarefoundation/autoware/pkgs/container/autoware-buildcache/294255076?tag=amd64-upstream-refine-cuda-workflow

@youtalk Sorry for the inconvenience, I believe that the workflow will fail as the commits are not signed.

@wenrir Thank you for your detail review. It's very insightful for me. I can fix the CI fails.

@wenrir

Additionally, have you considered using matrix instead? In order to combine the cude and non-cuda workflows? they seem to do basically the same thing.

One of the purposes of this PR is rather to stop the matrix, because in this organization, there is currently only one arm64 self-hosted runner available, and using the matrix would require double the execution time.
https://github.com/autowarefoundation/autoware/pull/5363/files#diff-de0ada9957e6211b26d1e4d4d49c0525a9f36224a5b8c743b5ff7339130f2aabL17-L34

@youtalk, thank you for the quick action and response, I understand (and agree) with the feedback.
(I'm unable to resolve my own comments, sorry)

Removed :heavy_check_mark:

@youtalk -san, docker-build is a composite action, not a workflow.
Do you mean to add docker-build-and-push as a required workflow?
But that workflow only runs on:
on:
  push:
    branches:
      - main
    tags:
  workflow_dispatch:
``` not every PR.

What should I do then?

Sorry, I've just realized it was part of the health-check.
I've added it to the required checks, tested in:

https://github.com/autowarefoundation/autoware/pull/5414

@xmfcx Thank you!


Add tile statistics to mbtiles, e.g. bbox, number of tiles, ...

mbtiles currently has meta-all to show the content of the metadata table. In addition to that, we should have a feature, either a new command like stats, or just expand meta-all (less favored) to compute the following:

compute rough bbox based on the available tiles - i.e. compute min/max X and Y for tile index, and convert it into a bbox. It should be able to update the metadata table with the new value
compute the number of the tiles in the mbtiles, with the breakdown by zoom level

Example
> mbtiles stats myfile.mbtiles

zoom
count
smallest
largest
average
bbox

0
1
48KB
48KB
48KB
-180,-86,180,86

1
4
30KB
50KB
38KB
-180,-86,180,86

2
25
10KB
70KB
15KB
-180,-86,180,86

---
---
---
---
---

all
7,247
15B
2.3MB
50KB
-180,-86,180,86

May I take this issue and get your help if needed? @nyurik

Sure, should be fairly straightforward :)

i updated the example output, just to give some rough expectations


No default jsDelivr CDN file set

This package doesn't have a default file set. You can set it via jsdelivr, browser, or main field in package.json

The package.json format defaults the "index.js" as the default when not specified. I don't specify the fields in which the default value is the one I want to use :)
You can see what I mean at https://nodejs.org/dist/latest-v12.x/docs/api/modules.html

If there is no package.json file present in the directory, or if the 'main' entry is missing or cannot be resolved, then Node.js will attempt to load an index.js or index.node file out of that directory.

I'm not sure about jsDeliver, but this is just a module meant for Node.js consumption and I just publish it to npm registry.


Uncaught Sync Token not found

Hello,
First, thank you for this very interesting MPEG1 decoder. I used it for some days and it was working ok despite an error on the browser log :
Uncaught Sync Token not found
Now it isn't working anymore with that same error repeated indefinitely.

Perhaps you were running the old websocket server with SOCKET_MAGIC_BYTES while websocket opening?
I've tested this issue for a week and found it is a miss behavior with old websocket server.
The new websocket-relay.js no loger has SOCKET_MAGIC_BYTES.

Yes I did the update and the error is displayed only once and I am getting the stream again.
Thanks


Add MsgPack support

vmihailenco/msgpack has a fairly decent and easy to use golang msgpack implementation it would be great to see native support in air, I've used echo and gin in the past and it would have been nice to see msgpack being handled natively the same way JSON is.
// WriteMsgPack responds to the client with the "application/msgpack" content v.
func (r *Response) WriteMsgPack(v interface{}) error {
	var (
		b   []byte
		err error
	)

	b, err = msgpack.Marshal(v)
	if err != nil {
		return err
	}

	r.Headers["content-type"] = &Header{
		Name:   "content-type",
		Values: []string{"application/msgpack"},
	}

	return r.WriteBlob(b)
}

Also maybe there is a way to stream json and msgpack.
Streaming might be more performant and memory efficient than writing blobs.
But I'm not sure how to do it right and handle stream failures properly.
I'm using these functions in my Gin application
// SendMsgpack send a msgpack encoded response with a status code
func SendMsgpack(c ctx, code int, msg interface{}) error {
	c.Status(code)
	c.Header("Content-Type", "application/msgpack")
	return msgpack.NewEncoder(c.Writer).Encode(msg)
}

// SendJSON send a json encoded response with a status code
func SendJSON(c ctx, code int, msg interface{}) error {
	c.Status(code)
	c.Header("Content-Type", "application/json")
	return json.NewEncoder(c.Writer).Encode(msg)
}

ps. air 很牛,真的,谢谢你创造它

Hi @SaulDoesCode,
I'm so glad to hear that you like this framework.
In fact, I don't know how powerful the MessagePack is, because I haven't used it in actual projects (but I've used Protocol Buffers and it works very well). So I'm not sure if we should add support for the MessagePack. Is that necessary?
And, of course, this framework supports streaming responses. Just call the Response#Write().

Please see commit 7c1d8e0e4853c29e806cf7fcdcf8f20bca0a3721. You can now write like this: json.NewEncoder(res.Body).Encode(...).

Hmm yeah, adding message pack support would add an extra dependency, one more thing to update and keep track off, and I suppose it is pretty niche, not that many people use it. That's ok yeah, I totally understand, I did add it in my fork just for convenience.
7c1d8e0, ah great, yes wonderful, this helps. I like streaming things 😝👍.
Oh one more thing, tdewolff/minify, and subsequently tdewolff/parse, need to be updated, they were throwing errors when I updated go.mod.
They seem to be working now with these versions:
github.com/tdewolff/minify v2.3.8-0.20181101065125-1920ee718c16+incompatible h1:NUIFjRnhP477SvkomaFBfYS4nvKUiaZkY1LUverjcmc=
github.com/tdewolff/minify v2.3.8-0.20181101065125-1920ee718c16+incompatible/go.mod h1:9Ov578KJUmAWpS6NeZwRZyT56Uf6o3Mcz9CEsg8USYs=
github.com/tdewolff/parse v2.3.5-0.20181101065215-3b56c4a41542+incompatible h1:qnrYarRqs7sDpm0h86oZX7wfVWeCG/0XT5aIa4w4PTY=
github.com/tdewolff/parse v2.3.5-0.20181101065215-3b56c4a41542+incompatible/go.mod h1:8oBwCsVmUkgHO8M5iCzSIDtpzXOT0WXX9cWhz+bIzJQ=

@SaulDoesCode
About tdewolff/parse and tdewolff/minify... sigh... I'm working on that (see tdewolff/parse#42).


Crafters outputting wrong items

Issue description:
Crafters are changing what is input into them.
What happens:
Lapis turns to yellow dye, and cobble to flint in any crafter outputting to a machine.  There are a few others I've noticed so far. Exporters work as expected (lapis exported to a chest is lapis).  I've done some further testing and yellow dye also takes over coal dust. Autocrafting recipes in crafters works fine, it's just when exporting to a machine. Most crafting recipes still work fine so far.
What you expected to happen:
Crafters producing the item as in the pattern.
Steps to reproduce:
1.make a pattern of Cobble=gravel
2.Put in to crafter pointing to a pulverizer
3.flint is input
...
Version (make sure you are on the latest version before reporting):

Minecraft:1.12.2
Forge:2715
Refined Storage:1.5.34

Does this issue occur on a server? [yes/no] yes
Just a added note, and I don't know if its related, but I am running notenoughids on the clients/server as this is a very large custom modpack. I don't know if its your mod causing it, but I though I'd try here first.
Thanks in advance!

This is most likely fixed for RS 1.6 ! Coming out soon


Refactor tests

Use a convention similar to the one commonly used for Go tests: keep data separate from test logic. This makes the tests more readable and easier to add new test cases.

Also see this comment for improving tests that came from stagehand: https://github.com/GoogleCloudPlatform/functions-framework-dart/pull/87#discussion_r547533340


Enable automatic reboots on CI slaves

Enables automatic reboots on CI slaves, which is useful for picking up and
installing Apt updates. Reboots should occur overnight.

I don't think you need all the individual entries on the role.ci-slave-N.yaml files.  All the slaves get the role.ci-slave.yaml data.

@alext Okay, I was trying to make it more obvious what's what, and then be able to turn it off on a per-machine basis should we need to (given not all slaves are created equal)...?

I think using role.ci-slave.yaml makes sense here.

Okay; fixed.

Is this mergeable?

Yes :+1:

Someone should merge this... @alexmuller  @jamiecobbett

:+1:


Fix a buffer leak in Thrift client

Motivation:
If an HTTP decorator such as CircuitBreakerClient throw an exception when Thrift client calls,
the HttpRequest is not aborted which lead to a buffer leak.
Modification:

Abort HttpRequest in THttpClientDelegate if an HTTP decorator throw an exception.

Result:

You no longer see the buffer leak when Thrift client is used with ClientBreakerClient.

Thanks for reviewing. 😉


Add steps

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: christopherroberthardy sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Remove JS and CSS assets from the repository

@padrino/core-members #1579 is a hot mess +4,759 −8,510. We really should not have copies of the standard assets in the repository. What would be the most appropriate way to handle this?

Closing as not a good idea until having a passable asset pipeline.


cache for View

new Sirius.View must return already create view, if it created.

https://github.com/fntzr/sirius/commit/ff9c3799796fc5f9afb8b2c0f8effdf3c60d37a3


Allows passed API key to be a callback function

Pull Request
Related issue
Fixes #765
What does this PR do?

Adds support for passing function as API key
Documents this feature in the README
Adds validation for instantMeiliSearch parameters

Ensures hostUrl is a string and throws an error if otherwise
Ensures apiKey is a string or a function that returns a string, throws errors if otherwise

Adds tests for instantMeiliSearch parameters validation

PR checklist
Please check if your PR fulfills the following requirements:

[x] Does this PR fix an existing issue, or have you listed the changes applied in the PR description (and why they are needed)?
[x] Have you read the contributing guidelines?
[x] Have you made sure that the title is accurate and descriptive of the changes?

Thank you so much for contributing to Meilisearch!

Hello @a11rew,
Thank you very much for contributing to Meilisearch :heart:.
However, I am not available on the weekend, but I will be back on Monday :blush:.
PS: This message was sent automatically!

bors merge

This message is sent automatically
Thanks again for contributing to Meilisearch :heart:
If you are participating in Hacktoberfest, and you would like to receive some gift from Meilisearch too, please complete this form.


Metric domain: include metric's metadata in the query result

Prometheus stores metadata about collected metrics such as help text and metric type (gauge, counter, ...). When evaluating a metric query, korrel8r could process the PromQL expression, extract metric names and return metadata information associated to these metrics in the query result.

For correlation purposes, the metric labels provide all the information that links a metric to other resources.
Re-open if there's still a use case for this, with examples of how counts etc. might be used in correlation.


[WIP] parallel-order test fixes

Difference between start and end should be at least 8 seconds. Now they are the same:
{ stats:
   { suites: 3,
     tests: 4,
     passes: 3,
     pending: 0,
     failures: 1,
     start: '2015-12-14T19:40:47.159Z',
     end: '2015-12-14T19:40:47.159Z',

Аа, ну подожди, рано же еще!
WIP - work in progress: https://github.com/blog/1943-how-to-write-the-perfect-pull-request


Getting error (after upgrade to 5.13.29?)

In the last couple days this has stopped working for me.
The error I'm getting is:
Error: write EPROTO<PHONE_NUMBER>04776:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:../deps/openssl/openssl/ssl/record/rec_layer_s3.c:1544:SSL alert number 70
I'm wondering if this has anything to do with the last item in the Ubiquiti release notes regarding the regeneration of self-signed certificates. When I navigate to the controller in my browser, the certificate is TLS 1.0.
Full log below:
[6/13/2020, 12:10:37 PM] [UniFi] Error, logging in and trying again
[6/13/2020, 12:10:37 PM] [UniFi] Error: write EPROTO<PHONE_NUMBER>04776:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:../deps/openssl/openssl/ssl/record/rec_layer_s3.c:1544:SSL alert number 70

    at WriteWrap.onWriteComplete [as oncomplete] (internal/stream_base_commons.js:92:16) {
  errno: 'EPROTO',
  code: 'EPROTO',
  syscall: 'write',
  config: {
    url: 'api/login',
    method: 'post',
    data: '{"username":"homebridge","password":"L2&Lq%2m%yScgr"}',
    headers: {
      Accept: 'application/json, text/plain, */*',
      'Content-Type': 'application/json;charset=utf-8',
      cookie: '',
      'User-Agent': 'axios/0.19.2',
      'Content-Length': 53
    },
    baseURL: 'https://<IP_ADDRESS>:8443',
    transformRequest: [ [Function: transformRequest] ],
    transformResponse: [ [Function: transformResponse] ],
    timeout: 0,
    adapter: [Function: httpAdapter],
    xsrfCookieName: 'XSRF-TOKEN',
    xsrfHeaderName: 'X-XSRF-TOKEN',
    maxContentLength: -1,
    validateStatus: [Function: validateStatus],
    httpsAgent: Agent {
      _events: [Object: null prototype],
      _eventsCount: 2,
      _maxListeners: undefined,
      defaultPort: 443,
      protocol: 'https:',
      options: [Object],
      requests: {},
      sockets: [Object],
      freeSockets: {},
      keepAliveMsecs: 1000,
      keepAlive: false,
      maxSockets: Infinity,
      maxFreeSockets: 256,
      maxCachedSessions: 100,
      _sessionCache: [Object],
      [Symbol(kCapture)]: false
    }
  },
  request: Writable {
    _writableState: WritableState {
      objectMode: false,
      highWaterMark: 16384,
      finalCalled: false,
      needDrain: false,
      ending: false,
      ended: false,
      finished: false,
      destroyed: false,
      decodeStrings: true,
      defaultEncoding: 'utf8',
      length: 0,
      writing: false,
      corked: 0,
      sync: true,
      bufferProcessing: false,
      onwrite: [Function: bound onwrite],
      writecb: null,
      writelen: 0,
      afterWriteTickInfo: null,
      bufferedRequest: null,
      lastBufferedRequest: null,
      pendingcb: 0,
      prefinished: false,
      errorEmitted: false,
      emitClose: true,
      autoDestroy: false,
      bufferedRequestCount: 0,
      corkedRequestsFree: [Object]
    },
    writable: true,
    _events: [Object: null prototype] {
      response: [Function: handleResponse],
      error: [Function: handleRequestError]
    },
    _eventsCount: 2,
    _maxListeners: undefined,
    _options: {
      protocol: 'https:',
      maxRedirects: 21,
      maxBodyLength: 10485760,
      path: '/api/login',
      method: 'POST',
      headers: [Object],
      agent: [Agent],
      agents: [Object],
      auth: undefined,
      hostname: '<IP_ADDRESS>',
      port: '8443',
      nativeProtocols: [Object],
      pathname: '/api/login'
    },
    _redirectCount: 0,
    _redirects: [],
    _requestBodyLength: 53,
    _requestBodyBuffers: [ [Object] ],
    _onNativeResponse: [Function],
    _currentRequest: ClientRequest {
      _events: [Object: null prototype],
      _eventsCount: 6,
      _maxListeners: undefined,
      outputData: [],
      outputSize: 0,
      writable: true,
      _last: true,
      chunkedEncoding: false,
      shouldKeepAlive: false,
      useChunkedEncodingByDefault: true,
      sendDate: false,
      _removedConnection: false,
      _removedContLen: false,
      _removedTE: false,
      _contentLength: null,
      _hasBody: true,
      _trailer: '',
      finished: true,
      _headerSent: true,
      socket: [TLSSocket],
      connection: [TLSSocket],
      _header: 'POST /api/login HTTP/1.1\r\n' +
        'Accept: application/json, text/plain, */*\r\n' +
        'Content-Type: application/json;charset=utf-8\r\n' +
        'cookie: \r\n' +
        'User-Agent: axios/0.19.2\r\n' +
        'Content-Length: 53\r\n' +
        'Host: <IP_ADDRESS>:8443\r\n' +
        'Connection: close\r\n' +
        '\r\n',
      _onPendingData: [Function: noopPendingOutput],
      agent: [Agent],
      socketPath: undefined,
      method: 'POST',
      insecureHTTPParser: undefined,
      path: '/api/login',
      _ended: false,
      res: null,
      aborted: false,
      timeoutCb: null,
      upgradeOrConnect: false,
      parser: null,
      maxHeadersCount: null,
      reusedSocket: false,
      _redirectable: [Circular],
      [Symbol(kCapture)]: false,
      [Symbol(kNeedDrain)]: false,
      [Symbol(corked)]: 0,
      [Symbol(kOutHeaders)]: [Object: null prototype]
    },
    _currentUrl: 'https://<IP_ADDRESS>:8443/api/login',
    [Symbol(kCapture)]: false
  },
  response: undefined,
  isAxiosError: true,
  toJSON: [Function]
}
(node:4064) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'data' of undefined
    at UniFiDevice.setProperties (/homebridge/node_modules/homebridge-unifi-led-control/src/UniFiDevice.js:121:40)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
(node:4064) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 43)

I haven't run into this myself on controller version 5.14.9, but I think you're on the right path with the TLS version. Mine is using TLS 1.2 and it looks like nodejs currently sets 1.2 as the minimum version.
I'm wondering if you have some outdated settings in your controller's config. I found this old thread that might help bump up the TLS version on your controller.
Otherwise I might be able to tell NodeJS to accept an older TLS version but it would probably be best to see if you can get your controller up-to-date first. Let me know 😃

Yep, I had found the same thread as you and this morning implemented the tweaks to update to TLS 1.2. After restarting the controller, Homebridge is successfully talking with the APs again. Thanks!