Mannaged to proc a crashloop in hostapd

Hi,
I was working on a shell script to use iwinfo scan output in order to my router change the current channel if it detects a better one (e. g. switching from channel 1 to 6 in 2.4GHz band).

I'm using my Yunlink XD4200 running OpenWRT 19.07 to test.
When I need to change the channel I call a wifi command, after setting a new channel with uci, on my bash script.
After a few successful changes, the wifi interface failed to initialize. I've check the logs to find a crash loop on the hostapd.

I've also managed to trigger the crash loop by calling wifi a few times in a row. I'm using wpad-full. After rebooting the AP the interfaces are up again. Is this intended behaviour?

I believe that the relevant log messages are
Mon Jan 27 13:53:49 2020 daemon.notice netifd: Network device 'wlan0' link is down Mon Jan 27 13:53:49 2020 daemon.info procd: Instance hostapd::hostapd-phy0 s in a crash loop 6 crashes, 15 seconds since last crash Mon Jan 27 13:53:49 2020 daemon.info procd: Instance hostapd::hostapd-phy1 s in a crash loop 6 crashes, 15 seconds since last crash Mon Jan 27 13:53:49 2020 daemon.notice netifd: radio0 (4920): Command failed: Not found Mon Jan 27 13:53:49 2020 daemon.notice netifd: radio1 (4921): Command failed: Not found Mon Jan 27 13:53:50 2020 daemon.notice netifd: radio0 (4957): command failed: Not supported (-122) Mon Jan 27 13:54:21 2020 daemon.notice netifd: radio1 (4960): Command failed: Request timed out Mon Jan 27 13:54:21 2020 daemon.notice netifd: radio1 (4960): Command failed: Not found Mon Jan 27 13:54:21 2020 daemon.notice netifd: radio1 (4960): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process path (/proc/exe) Mon Jan 27 13:54:21 2020 daemon.notice netifd: radio0 (4957): Command failed: Request timed out Mon Jan 27 13:54:21 2020 daemon.notice netifd: radio0 (4957): Command failed: Not found Mon Jan 27 13:54:21 2020 daemon.notice netifd: radio1 (4960): Command failed: Invalid argument Mon Jan 27 13:54:21 2020 daemon.notice netifd: radio0 (4957): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process path (/proc/exe) Mon Jan 27 13:54:21 2020 daemon.notice netifd: radio0 (4957): Command failed: Invalid argument Mon Jan 27 13:54:22 2020 user.notice root: ip link set dev wlan1 up Mon Jan 27 13:54:22 2020 kern.info kernel: [ 397.704150] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready Mon Jan 27 13:54:22 2020 user.notice root: ip link set dev wlan0 up Mon Jan 27 13:54:24 2020 kern.warn kernel: [ 399.969786] ath10k_pci 0000:00:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96 Mon Jan 27 13:54:24 2020 kern.warn kernel: [ 399.977638] ath10k_pci 0000:00:00.0: msdu-desc: 2500 skid: 32 Mon Jan 27 13:54:25 2020 kern.info kernel: [ 400.028859] ath10k_pci 0000:00:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186 msdu-desc: 2500 sw-crypt: 0 ct-sta: 0' Mon Jan 27 13:54:25 2020 kern.info kernel: [ 400.040194] ath10k_pci 0000:00:00.0: wmi print 'free: 117888 iram: 22628 sram: 26276' Mon Jan 27 13:54:25 2020 kern.warn kernel: [ 400.339071] ath10k_pci 0000:00:00.0: Firmware lacks feature flag indicating a retry limit of > 2 is OK, requested limit: 4 Mon Jan 27 13:54:25 2020 kern.info kernel: [ 400.350738] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready Mon Jan 27 13:54:25 2020 kern.info kernel: [ 400.358821] br-lan: port 2(wlan1) entered blocking state Mon Jan 27 13:54:25 2020 kern.info kernel: [ 400.364443] br-lan: port 2(wlan1) entered disabled state Mon Jan 27 13:54:25 2020 kern.info kernel: [ 400.370236] device wlan1 entered promiscuous mode Mon Jan 27 13:54:25 2020 kern.info kernel: [ 400.550237] br-lan: port 3(wlan0) entered blocking state Mon Jan 27 13:54:25 2020 kern.info kernel: [ 400.555787] br-lan: port 3(wlan0) entered disabled state Mon Jan 27 13:54:25 2020 kern.info kernel: [ 400.561650] device wlan0 entered promiscuous mode

Bump.
I think this issue will happen when using scripts such wifi-schedule or other dameons that could run wifi reconf or wifi.

I think hostapd is somewhat broken at the moment. I've noticed similar behavior here. Still happens on r12237-d2b8ccb1c0 (2020.02.16). This bug might be involved.

1 Like

Sorry for not replying earlier.
I did some testing with 19.07.2 (custom build) and it seems to be working as intended now.