It looks like the issue is triggered by the long execution time of
hostapd_config_add() executed via ubus. This function is called for both
interfaces (5G and 2.4G). The first call for 5G is finished within 1 second.
The second call for 2.4G is finished after ~100 seconds. The ubus call itself
does timed out.
Sat Jun 3 09:03:55 2023 daemon.notice hostapd: (../src/ap/ubus.c:730)
hostapd_config_add() buf='bss_config=phy1-ap0:/var/run/hostapd-phy1.conf'
Sat Jun 3 09:03:55 2023 daemon.notice hostapd: Configuration file:
/var/run/hostapd-phy1.conf (phy phy1-ap0) --> new PHY
Sat Jun 3 09:03:55 2023 daemon.notice hostapd: phy1-ap0: interface state
UNINITIALIZED->COUNTRY_UPDATE
Sat Jun 3 09:03:55 2023 daemon.notice hostapd: ACS: Automatic channel
selection started, this may take a bit
Sat Jun 3 09:03:55 2023 daemon.notice hostapd: phy1-ap0: interface state
COUNTRY_UPDATE->ACS
Sat Jun 3 09:03:55 2023 daemon.notice hostapd: phy1-ap0: ACS-STARTED
Sat Jun 3 09:03:55 2023 daemon.notice hostapd: (../src/ap/ubus.c:744)
hostapd_config_add() res=0
Sat Jun 3 09:03:58 2023 daemon.notice hostapd: (../src/ap/ubus.c:730)
hostapd_config_add() buf='bss_config=phy0-ap0:/var/run/hostapd-phy0.conf'
Sat Jun 3 09:03:58 2023 daemon.notice hostapd: Configuration file:
/var/run/hostapd-phy0.conf (phy phy0-ap0) --> new PHY
Sat Jun 3 09:03:58 2023 daemon.notice hostapd: phy0-ap0: interface state
UNINITIALIZED->COUNTRY_UPDATE
Sat Jun 3 09:03:58 2023 daemon.notice hostapd: Enabled CRL reload functionality
Sat Jun 3 09:04:28 2023 daemon.notice netifd: radio0 (2991): Command failed: ubus call hostapd config_add
{"iface":"phy0-ap0", "config":"/var/run/hostapd-phy0.conf"} (Request timed out)
Sat Jun 3 09:04:28 2023 daemon.notice netifd: radio0 (2991): Device setup
failed: HOSTAPD_START_FAILED ret=0 hostapd_res=''
Sat Jun 3 09:04:59 2023 daemon.notice hostapd: Enabled CRL reload functionality
Sat Jun 3 09:05:52 2023 daemon.notice hostapd: phy0-ap0: interface state
COUNTRY_UPDATE->ENABLED
Sat Jun 3 09:05:52 2023 daemon.notice hostapd: phy0-ap0: AP-ENABLED
Sat Jun 3 09:05:52 2023 daemon.notice hostapd: (../src/ap/ubus.c:744)
hostapd_config_add() res=0
To bypass the issue, I added a long timeout to the affected ubus call:
--- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
@@ -1251,7 +1251,7 @@ drv_mac80211_setup() {
if [ "$no_reload" != "0" ]; then
add_ap=1
ubus wait_for hostapd
- local hostapd_res="$(ubus call hostapd config_add "{\"iface\":\"$primary_ap\",
\"config\":\"${hostapd_conf_file}\"}")"
+ local hostapd_res="$(ubus -t 180 call hostapd config_add "{\"iface\":\"$primary_ap\",
\"config\":\"${hostapd_conf_file}\"}")"
ret="$?"
[ "$ret" != 0 -o -z "$hostapd_res" ] && {
wireless_setup_failed HOSTAPD_START_FAILED
Regards,
Hartmut
Am 27.05.2023 um 18:04 schrieb e9hack:
if I execute 'ubus call network.wireless status', I get the same result as
executing ' ubus call luci-rpc getWirelessDevices'. It looks like a netifd
timeout issue. I see the following at boot in the log file:
Fri May 26 13:40:58 2023 daemon.notice netifd: radio0 (2851): Command
failed: ubus call hostapd config_add {"iface":"phy0-ap0",
"config":"/var/run/hostapd-phy0.conf"} (Request timed out)
Fri May 26 13:40:58 2023 daemon.notice netifd: radio0 (2851): Device setup
failed: HOSTAPD_START_FAILED
Fri May 26 13:40:59 2023 daemon.notice netifd: Wireless device 'radio0' set
retry=0
Fri May 26 13:40:59 2023 daemon.crit netifd: Wireless device 'radio0' setup
failed, retry=0
Fri May 26 13:40:59 2023 daemon.notice netifd: Wireless device 'radio0' is
now down
Is there a possibility to specify a longer timeout?
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
