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 mac80211.sh) and reading (with hostapd) of said configuration 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.
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 /lib/netifd/wireless/mac80211.sh
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?
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 aWorkaroundbutton here, cause I just can't even think of the word Solution in this context.
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?
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?
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/mac80211.sh, I'm up running again
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
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): ./mac80211.sh: eval: line 871: wpa_supplicant_run: not found
daemon.notice netifd: Wireless device 'radio0' is now up
daemon.notice netifd: Interface 'wwan' is enabled
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.
Workaround button here 