Unlike another poster, my upgrade from 22.03.5 UBI went mostly well in that the radios (including additional SSIDs on VLANs) came up okay. It is just that connected wireless devices won't show up in status nor will either of the radios do a wireless scan.
Any suggestions for what to look at?
(Edited to add that the STAs will show up using the iw command, just not on the GUI)
So I had firmware-selector build me a custom UBI image with some packages that I would have installed anyway and flashed that image. Now the 2.4GHz radio works perfectly including showing associated stations and doing a scan. The 5GHz radio, on the other hand, shows enabled on the Wireless page but isn't even broadcasting its SSID.
The relevant section from the output of hwinfo for radio1 is:
Assuming you already tried to fix the configuration issue: I would drop your configuration, do an OpenWrt factory reset and rebuild your configuration from scratch.
Either from Luci or command line:
This message is sent via OpenWrt 23.05-Snapshot on E8450-UBI, some weeks after RC2. It should not be a code issue but a configuration issue.
After re-creating the config from scratch, everything seems to be working except that the 5GHz radio still won't do a scan. Is it not supposed to? (I can connect to the configured SSID though)
That is how I use it on my travel router. Here I am merely trying to do a wireless survey.
Since my last post, I have discovered that scan works if no AP is configured on this radio but shows no SSIDs once an AP is configured. Scan works on the 2.4GHz radio even when APs are configured.
The root cause is probably be the same. This limitation seems to be specific for the MediaTek MT7915E, since I have another access point with MediaTek MT76x2e which works fine as expected:
the region (FCC vs ETSI vs MKK vs China, etc.) and its regulatory requirements
the tuned channel
scanning while being tuned to a non-DFS channel is easier, than while being tuned to a DFS channel (where the chip has to scan for radar events constantly, this makes leaving the channel intermittently for scanning harder (depending on the exact regional regulatory requirements impossible).
There simply is no generic answer to this question.
If it works for you, great.
If it doesn't, that may very well be o.k. (working as required). To tell if it could work, is very hard without a deep dive into the driver code and the (usually unobtainable) hardware specifications - and impossible without talking about where the user is located (due to the local regulatory requirements).
That is why quite a few high-end routers have a dedicated radio exclusively used to search for DFS events, constantly scanning the ether to have an alternative free channel (without an active radar signal) on retainer.
There are devices that have been designed with that in mind (e.g. wrt3200acm/ wrt32x[0]), but even the vendor never actually made use of that as such in their proprietary firmware (probably they didn't get it working sufficiently well, but they did add a third radio exclusively meant for this purpose, in an environment where fractions of a cent count). No device using OpenWrt can do that at this point, as the drivers/ firmware won't allow omitting the DFS scanning on the primary device anyways (so there wouldn't be much of a gain compared to just doing it once, on the main radio); locked down proprietary firmware that don't allow (easy-) tampering would have more freedoms in this regard.
Some enterprise APs (with their proprietary firmware) probably have this features, but I don't have a specimen at hand.
--
[0] the Xiaomi Mi AIoT Router AX3600 and -AX9000 also come with a similar third radio, albeit with a different purpose in mind (second 2.4 GHz network for Xiaomi's IoT ecosystem, the radio itself is 1x1 802.11ac dual-band though)