with more logging i got this: while trying to achieve 160Mhz
[Fri Mar 28 11:36:04 2025] br-lan: port 7(wlp7s0) entered disabled state
[Fri Mar 28 11:36:20 2025] wlp7s0: start-radar-detection, starting dfs-cac-timer-work.
[Fri Mar 28 11:36:52 2025] br-lan: port 7(wlp7s0) entered disabled state
[Fri Mar 28 11:37:54 2025] chandef-usable, ch-160 not supported, ext-nss-bw issue
[Fri Mar 28 11:37:54 2025] br-lan: port 7(wlp7s0) entered disabled state
Enabling ASPM on the PCIe bus can significantly improve Wi-Fi noise level on the BE14 with no immediate drawbacks. Is there a reason why it's not enabled by default in OpenWrt and can it be enabled during build time instead of a post-installation command/script?
To answer my own question, I opened the file target/linux/mediatek/filogic/config-6.6 in the OpenWrt build root and swapped these two parameters around. Now the kernel defaults to powersave as the ASPM governor.
CONFIG_PCIEASPM_PERFORMANCE=y
# CONFIG_PCIEASPM_POWERSAVE is not set
It might be too soon to do until more people confirm there's no drawbacks to this change. I, for one, have only tested it with the 2 and 5 GHz bands active. By the way, using "powersupersave" instead of "powersave" seems to negatively affect Wi-Fi throughput.
It depends on the Wi-Fi SoC how much power-saving affects performance. It should be a user-facing configuration option with a reasonable default (not superpowersave).
"powersave" works for me and gains about 5-6dbm on 2 different bpi-r4, been using it for a couple of weeks now without additional problems. Did not check the throughput.
I do have instability with multiple SSID per interface in last Friday's snapshot that I did not have a month ago, but I have those even without the "powersave", so they are unrelated.
Last month I also had weird problems on ssh where interactive ssh connections (to the router or other internal server) would hang, but ssh commands would have no problems. Only on wifi. Restarting the wireless interface a couple of times would solve the issue for a while.
Luckily that is gone now, that was maddening,
it still requires "powersave" for better noise margin (~5dbm)
restarting the 2.4g device can drop you out of the 6ghz and vice versa...
example of problems on multiple ssid:
my IoT network does does not work at boot (have to disable/enable) and when I enable it I start having all sort of issues with the other network, sometimes packet loss, other times no internet (but no packet loss), ssh connections on a local (wired) server hanging after login, can't connect via ssh to the router...
...anyone has any workaround for the multiple ssid? I kinda need the IoT network...
Has anyone looked into this issue when LuCi gets stuck on the reading lowest on the list of Wi-Fi noise values? Here CLI returns different values from iw phy0.0-ap0 survey dump, but it's all the same noise level in LuCi.
Survey data from phy0.0-ap0
frequency: 2412 MHz [in use]
noise: -82 dBm
Survey data from phy0.0-ap0
frequency: 5660 MHz [in use]
noise: -91 dBm
Survey data from phy0.0-ap0
frequency: 6215 MHz [in use]
noise: -80 dBm
Another long-standing LuCi issue is the inability to launch channel scans on the 5 and 6 GHz bands. The results come up empty. It scans just fine with iw phy0.1 scan, though.
As the result, iwinfo reports the same noise value for each radio. The higher channels are lower on the list, so that's what LuCi picks up from iwinfo.
iw survey dump returns the same channel list regardless of the virtual interface selected, too.
Is this how the MT7995AV + MT7976CN + MT7977IAN combo of chips found on the BE14 board supposed to work, or is it a software shortcoming that needs to be fixed?
Regardless, I think iwinfo needs a more robust parsing function (source) to be able to tell apart separate radios which belong to the same Phy. The BE14 might not be the only device that does this.
