Wifi at the Luci web interface

[e9hack]

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?
>