Hostapd unknown configuration item 'radio_config_id' [SNAPSHOT r23375-cdfcac6e24]

Hi, wireless stopped working on my device after mentioned update to snapshot with:

daemon.err hostapd: Line 20: unknown configuration item 'radio_config_id'
daemon.err hostapd: 1 errors found in configuration file '/var/run/hostapd-phy0.conf'
daemon.err hostapd: Failed to set up interface with /var/run/hostapd-phy0.conf

in the logread output.

After some digging I found some inconsistency in generating (using and reading (with hostapd) of said configuration file.



contains row:

echo "radio_config_id=${radio_md5sum}" >> $hostapd_conf_file

but currently used (really don't know the reason) hostapd is not aware of such configuration item.

When is mentioned row commented out, thus config file does not contain 'radio_config_id', wireless starts working again.

As I already stated I'm not sure what could be the reason (I'm using wpad-mbedtls, stock is I think with basic version?, it should be the only difference), and I'm really not particularly experienced how exactly openwrt works in this area, but even just for the sake of saving someone else's time I wanted to share what I found.



I also had similar issues when attempting to install a new USB WiFi adaptor and using wpad.

What resolves the issue is removing or commenting out line 495 from:

       echo "radio_config_id=${radio_md5sum}" >> $hostapd_conf_file


#       echo "radio_config_id=${radio_md5sum}" >> $hostapd_conf_file

Thereafter performing a restart on wpad and following logread shows it starting up fine as expect:

/etc/init.d/wpad restart && logread -f

Yup, that's what I did too.

...but something is telling me there should be better solution. :smiley:

Thanks, that was helpful.

Thanks to @davidrapan and @aphorise, for getting us a workaround, but I think this is a serious problem. As much as I like my "logread", I don't think individual workarounds for every single user is the way to go here.

On a new install this happened to me, just after rooting. As a comparison, I updated all packages on an old one.

On an old install after updating all packages I had the same problem. I don't recall which one did it. It must have been one containing
Then, WIFI never came back up, error in logread:
unknown configuration item 'radio_config_id'

Yes, it's workaroundable, but can anybody tell me who to report it to? Probably no AX3600 specific issue.

Solution in this thread, but I assume the checksum isn't just there for funsies and does serve a purpose?

1 Like

Exactly, this one is really nasty, and as u said it's very likely it won't be an issue of just AX3600.

First thing what's comes to my mind (and also possibly the simplest solution) is why is hostapd so strict of what its conf file contains? Shouldn't that be more of an optional feature? Am I missing something?

Also I'm missing a :white_check_mark: Workaround button here :smiley: , cause I just can't even think of the word Solution in this context. :smiley:

1 Like

hostapd is a highly security sensitive service, it really shouldn't second-guess the config or ignore parts of it, just because (stripped variants of-) it can't understand it. The only sensible approach here is to throw an error and refuse to start up.

That may be inconvenient if you know better, but hostapd doesn't know if the option is important or not, unless it is taught about it.

I can see your point, the best would be not to generate conf file which is from the perspective of hostapd invalid. Cause obviously, one can never know for sure, how that could have happened and that it's not from some kind of a malicious intent.

But I really would like to know the purpose of 'radio_config_id', and why it's there. Is it (or was it in the past) part of some version of hostapd?


same issue here. Way to fixed is from file "/lib/netifd/wireless/" removing or commenting out line 495 from:

       echo "radio_config_id=${radio_md5sum}" >> $hostapd_conf_file


#       echo "radio_config_id=${radio_md5sum}" >> $hostapd_conf_file

I don't know why this is happening maybe @slh could confirm the purpose of 'radio_config_id', and why it's there. Is it (or was it in the past) part of some version of hostapd?


Unfortunately, the recently updated "hostapd-common" package didn't resolve this problem.

As @slh stated, hostapd is probably not where this should be addressed.

Instead I got a new error, but that is OT here, because it's a roaming issue.

After reverting the workaround, I had 2 errors, so the workaround didn't cause the second one.

I think this needs to be addressed in "/lib/netifd/wireless/"

I agree, my use of the term "solution" was frivolous in the context of this issue.


I had same issue with the radio_config_id today after updating some packages on my Netgear Wax206 running as an AP on OpenWrt 23.05.0-rc3 - r23389-5deed175a5 since start September

Only issue I have had some time now is the systemtime not being updated (set to ntp from openwrt) this prevents updating until set accordingly.

Issue with the wireless occurred after reboot...

But thanks to Your 'FIX', commenting out echo "radio_config_id=${radio_md5sum}" >> $hostapd_conf_file
in /lib/netifd/wireless/, I'm up running again


So, as expected, this is not an AX3600 exclusive issue.
At least one other user has had the same problem with Netgear Wax206.

This needs to be addressed at a more senior level, then.

I hope. Nevermind,

1 Like

Confirming this is still an issue as of a couple of hours ago when I tried updating with auc. I am running 23.05 rc-3

I posted the problematic packages in the rc-3 topic

Hopefully not to hard to fix. I will keep an eye out for new versions of the problematic packages and try again.

1 Like

Can confirm this affects Dynalink DL-WRX36 running 23.05.0-rc3. It did not affect it on the initial release, it only happened last night when I updated my software packages. Woke up to my phone gripping about no WIFI access to my thermostat, as I didn't realize wifi didn't come back up before I laid down..

Here is what I remember and can confirm from the update as well as my software list::
-wpad-basic-mbedtls, as it's updated to 2023-09-08-efccbfc6-3.
-netifd is updated to 2023-09-15-afcd3825-1

ubus , ubus, uci, ucode and ucode-mod packages all updated as well. Funny enough, they're all dated 2023-06-06-c7d84aae-1. Which includes ucode-mod-nl80211. Not sure if this is the culprit, or if netifd or wpad are the issues. Otherwise openssh-server and openssh-keygen were updated to 9.4p1-1, but I doubt they were the cause.
Regardless, after commenting out the line as mentioned, I'm up and running again. Hopefully I was able to provide somewhat useful information.
I'm now returning to bed. Good night!

Fri Sep 22 02:52:48 2023 daemon.notice hostapd: Configuration file: /var/run/hostapd-phy1.conf (phy phy1-ap0) --> new PHY
Fri Sep 22 02:52:48 2023 daemon.err hostapd: Line 50: unknown configuration item 'radio_config_id'
Fri Sep 22 02:52:48 2023 daemon.err hostapd: 1 errors found in configuration file '/var/run/hostapd-phy1.conf'
Fri Sep 22 02:52:48 2023 daemon.err hostapd: Failed to set up interface with /var/run/hostapd-phy1.conf
1 Like

same on linksys wrt 3200acm

radio_config_id is not used anymore since the conversion to ucode.

1 Like

those workaroud works for ap mode, how about sta mode ?

kern.err kernel: [ 7419.052701] ieee80211 phy0: rt2800_wait_bbp_rf_ready: Error - BBP/RF register access failed, aborting
daemon.err hostapd: rmdir[ctrl_interface=/var/run/hostapd]: Permission denied
daemon.notice netifd: Interface 'wwan' is disabled
daemon.notice netifd: Wireless device 'radio0' is now down
daemon.notice netifd: radio0 (8085): sh: out of range
daemon.notice netifd: radio0 (8085): ./ eval: line 871: wpa_supplicant_run: not found
daemon.notice netifd: Wireless device 'radio0' is now up
daemon.notice netifd: Interface 'wwan' is enabled

i will try to comment that 871 line

Thanks for this clarification. :+1:

As an attempt to wrap it up as sufficient solution:

The combination of info from @robimarko and thus commenting out (carefree) the line 495:

echo "radio_config_id=${radio_md5sum}" >> $hostapd_conf_file



Ofc as already stated instead of updating packages with opkg (especially the system ones, which is not recommended) flashing the router with new snapshot is always a better approach.