I have noted an interesting issue in the LuCI Status/Real Time Graphs in that it displays “Radio 0” Data when “Radio 0” is disabled and/or not in use.
Scenario: A Google WiFi loaded with OpenWRT 24.10.4 (with latest LuCI updates applied) set up as a WiFi bridge using its 802.11ac interface only.
There appears to be no native facility to display data emanating from “Radio 1”.
Before posting I have tested this using a virtualised image into USB hardware; The same issue was observed there (and all latest LuCI updates were applied before attaching the USB hardware).
See attached images (with identifying data such as SSID’s and MAC addresses redacted/blanked out):
So is it hardware or luci? Then it would be in your face without drivers....
I would suspect that issues could be resolved with some tweaking of LuCI script - based on the fact that all main functions work as intended.
As for old lingering issues, I am not in a position to comment on that as I do not live inside this interface.
[ It possibly is based on both of our understandings of the product. I am just reporting the issue; there may be other background that quite an exhaustive search of the wiki’s has not thrown up. ]
It is an issue that needs greater attention; accurate presentation of the data (in some instances) would be highly useful.
Any “known anomaly” that lingers for some time presents reputation issues. As we all know, this product is the best that there is.
I have tried here to issue a report of a genuine issue - for which I have provided evidence - and now I am getting vile and attack-at-reputation thrown back.
I am an Academic. This has come from MY STUDENTS (as has a past post). I have verified issues.
Take the report for what it is - a genuine attempt to report an issue and nothing more than that.
Answers like this last one set a poor example to those out there in the community that are GENUINELY keen on seeing product improvement.
The question is whether ip link shows client device once used for wifi scan after scan is done - ie same software issue disabling secondary AP-s on the broadcom platform. Not how to hide problem from UI.
Yes — data is displayed, as you correctly note. However, to spell it out as plainly as possible: Radio 0 is not connected, implemented, or utilised — Radio 1 is. Despite this, there is no option or capability within the interface to display data from Radio 1.
I’ve already described the environment and provided screenshots showing the absence of data. When examined objectively, it’s evident that the system is attempting to read data from the wrong radio.
The physical hardware is a Google WiFi (Gale) device, deployed strictly according to the instructions at: https://openwrt.org/toh/google/wifi
As for the issue and reproducing the issue, “Trainees” observed that the graphs discussed in this thread were not functioning.
LuCI and attended-upgrade packages were updated, and the system was upgraded to OpenWRT 24.10.4 — issue persisted.
LuCI 24.10.4 upgrade scripts were also deployed in full — issue still remained.
Then OS was deployed and environments replicated inside a VMware Virtiualised environment using x86_64 images with “Similar” USB-connected hardware that is known to work with OpenWRT providing internet connectivity. Same Result.
At this point, under all reasonable and ethical reporting standards, this warrants discussion before reporting as a bug. Be informed before reporting.
While I’m not an OpenWRT internals expert, those here clearly are. While I am not over every post - others are.
From my overview understanding, this appears to be an issue that could be addressed within LuCI. A conceptual fix, without respect to OpenWRT internals, could possible involve:
Rename the current “Radio” tab (e.g., to “Wireless Interface”).
Add a combo box populated with available Radio Numbers and Network Names so that users can select the correct radio source for data display.
Implementing such a fix could have wider implications across related devices and configurations, so it should be referred to contributors with deeper LuCI and OpenWRT architectural knowledge for better solutions.
As for whether this has been reported elsewhere — I’ve found no clear evidence. Exhaustive searches (including via commercial AI tools) did not reveal any identical cases. It’s possible related posts exist, but they appear to describe different contexts or implementations.
I see you are passionate about clippy & friends.
Can you provide confirmation it is at least similar to script issue reported this summer but neglected since? Which means it is same on other platforms, though less visible than on brcm platforms.
It is not that luci starts reporting statistics from thin air at random.
People ask here FIRST in recognition of best practise for reporting issues. There has been lots of edits and “system rejections”. We are here and ask in these places to make things better; tight systems are also here to do the same.
Thanks for those that were positive with informed assistance
