wifi-detect.uc is writing a new board.json on every boot
R.
grip_twenty244 at simplelogin.com
Wed Sep 9 05:59:49 PDT 2026
> > This is happening on both of my Cudy WR3000 devices running 25.15.5.
> > Flash wearing could be a thing. Commenting out the following block stops the writes.
> >
> > if (!is_equal(prev_board_data, board_data)) {
> > let new_file = board_file + ".new";
> > unlink(new_file);
> > let f = open(new_file, "wx");
> > if (!f)
> > exit(1);
> > f.write(sprintf("%.J\n", board_data));
> > f.close();
> > rename(new_file, board_file);
> > }
> >
> > A quick look at the is_equal function showed no obvious issues. I'll set up a modified wifi-detect.uc to log the before and after contents at boot.
> > The issue was found with:
> > sleep 90 && touch -m /etc/timestamp && ubus -S call system reboot
> > find /overlay/upper -newer /etc/timestamp
> >
>
> Here is the result by replacing the above block with:
>
> if (!is_equal(prev_board_data, board_data)) {
> const prev_board_json = open("/tmp/board.json.prev", "w");
> const curr_board_json = open("/tmp/board.json.curr", "w");
>
> prev_board_json?.write(sprintf("%.J\n", prev_board_data));
> curr_board_json?.write(sprintf("%.J\n", board_data));
>
> prev_board_json?.close();
> curr_board_json?.close();
> }
>
> diff -u board.json.prev board.json.curr
> --- board.json.prev
> +++ board.json.curr
> @@ -27,60 +27,5 @@
> }
> },
> "wlan": {
> - "phy0": {
> - "path": "platform/soc/18000000.wifi",
> - "info": {
> - "antenna_rx": 3,
> - "antenna_tx": 3,
> - "bands": {
> - "2G": {
> - "ht": true,
> - "he": true,
> - "max_width": 40,
> - "modes": [
> - "NOHT",
> - "HT20",
> - "HE20",
> - "HT40",
> - "HE40"
> - ],
> - "default_channel": 1
> - }
> - },
> - "radios": [
> - ]
> - }
> - },
> - "phy1": {
> - "path": "platform/soc/18000000.wifi+1",
> - "info": {
> - "antenna_rx": 3,
> - "antenna_tx": 3,
> - "bands": {
> - "5G": {
> - "ht": true,
> - "vht": true,
> - "he": true,
> - "max_width": 160,
> - "modes": [
> - "NOHT",
> - "HT20",
> - "VHT20",
> - "HE20",
> - "HT40",
> - "VHT40",
> - "HE40",
> - "VHT80",
> - "HE80",
> - "VHT160",
> - "HE160"
> - ],
> - "default_channel": 36
> - }
> - },
> - "radios": [
> - ]
> - }
> - }
> }
> }
>
> As you can see, wifi-detect.uc, when first called after a boot, won't be able to detect wifi devices through NL80211_CMD_GET_WIPHY, resulting in not just one, but TWO writes per boot (one with no devices and another with the devices).
>
> Possible solution:
>
> if (!is_equal(prev_board_data, board_data) && length(board_data.wlan)) {
> }
>
> This needs to be addressed asap. I em pretty sure this isn't just happening on the Cudy WR3000. Flashes are getting wear for no good reason.
>
The chain that leads to the double write:
1) System boots
2) In /etc/init.d/boot, boot() is invoked, which in turn invokes /sbin/wifi config
3) /sbin/wifi config invokes wifi_config(), which in turn invokes /usr/share/hostap/wifi-detect.uc
4) In /usr/share/hostap/wifi-detect.uc, cleanup() removes all wlan keys starting with "phy", read from /etc/board.json
5) In /usr/share/hostap/wifi-detect.uc, wiphy_detect() calls nl.request(nl.const.NL80211_CMD_GET_WIPHY, ...) to repopulate the previously cleaned wlan object, but at this point, nothing is returned by this call
6) Since the previously written /etc/board.json contains phy devices within the wlan object but the newly generated wlan object is empty, /etc/board.json is written to flash with an empty wlan object (first write)
7) /etc/hotplug.d/ieee80211/10-wifi-detect is eventually triggered, which leads to it invoking /sbin/wifi config
8) Repeat from 3, but this time nl.request(nl.const.NL80211_CMD_GET_WIPHY, ...) returns the correct devices, leading to a new /etc/board.json write to flash with the proper phy devices (second write)
I am wasting my free time debugging this issue (and in writing these detailed emails) and not even a single contributor has bothered to acknowledge these emails for half a week. This is the responsibility of the person who refactored them into ucode to begin with.
Also, DO NOT redirect me to your Github repository. They are using AI slop to shadowban accounts, which then hides all of your issues for everyone: https://github.com/orgs/community/discussions/153161
I would rather keep my knowledge and fixes to myself rather than further waste my time with that PROPRIETARY platform.
More information about the openwrt-devel
mailing list