[FS#3319] erratic behaviour wireless network control on system with three wireless phy

[OpenWrt Bugs]

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#3319 - erratic behaviour wireless network control on system with three wireless phy
User who did this - william wortel (wwortel)

----------
The hostapd crash is also easily reproducible by just 'wifi down' or 'wifi up'. 
Initially thought that drv_mac80211_teardown() in /lib/netifd/wireless/mac80211.sh chose the wrong 'data' config.
But by json_dump at that place observed that this is only the case for one out of three physical wireless interfaces that get acted upon simultaniously. The other two get the data about phy served correctly.
The crash as such happens when drv_mac80211_setup() is called, either as setup or teardown action. But, again, only for one out of three wireless interfaces.
It occurs near the line 'local hostapd_pid=$(ubus call service list '{"name":"wpad"}' | jsonfilter -l 1 -e "@['wpad'].instances['hostapd'].pid")'
Even though the code before that line has been waiting for hostapd to be present for ubus (ubus wait_for hostapd), by the time communication occurs hostapd has already crashed and in the data 'running' is reported 'false'
But the code has no test for that and just reports the pid (empty) is not the correct one.
But, again, only for one out of three interfaces. After a hostapd crash it gets started again automatically unless the kernel has detected to many crashes of hostapd in a short time and then hostapd remains absent.
The missing interface is brought up later.
My preliminary conclusion is that the concurrency in time of three identical mac80211 commands to be executed, cause this instability. Apparently the ubus communication channel to hostapd does not properly interleave communications.

Another imperfection observed is that a command like 'wifi down wlan1' does not bring down just wlan1, when also wlan0 and wlan2 are present.
All three get brought down and then the two not given down are restarted afterwards. It is very inconvenient that manipulating one radio does not leave the others intact without interruption.
Earlier OpenWrt did not have this problem. 
----------

More information can be found at the following URL:
https://bugs.openwrt.org/index.php?do=details&task_id=3319#comment8770

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.