[OpenWrt-Devel] synchronous network reload/restart

[Bruno Randolf]

On 03/30/2015 11:26 AM, Zefir Kurtisi wrote:
> On 03/26/2015 06:54 PM, Jo-Philipp Wich wrote:
>> Hi.
>>
>>> Is there any way to synchronously (blocking) reload or restart the
>>> network configuration?
>>>
>>> "ubus call network reload" (or "restart") returns immediately, and the
>>> re-configuration happens asynchronously in the background. I'd like the
>>> command to block or otherwise wait until the reconfiguration is
>>> complete. Any way to achieve this?
>>
>> No.
>>
>> ~ Jow
> 
> Potential 'workarounds'
> 
> 1) if you need to wait for your AP
> use e.g. 'ubus -t 30 wait_for hostapd.wlan0'
> to wait for it up to 30 secs to show up
> 
> 2) to synchronize PROCD startup-scripts
> add a service_started() method in your scripts that does busy-polling for
> procd/netifd to bring up services. This blocks subsequent init-scripts from being
> executed before your current script is done.
> 
> 
> Some kind of dependency tracking within procd would help for sure (e.g. 'start
> this service only after services x+y are running'), but given how services are
> handled as independent instances now, this would add lots of complexity to modules
> that must not fail.

Thanks for these workarounds, they do not help me, but may be useful for
someone else in the future.

I am dealing with the problem of re-configuration of multiple dependent
virtual interfaces: an ad-hoc interface, a monitor interface, an AP and
a BATMAN-ADV bat0 interface all on one wireless device. Also I have a
service which depends on the monitor interface, and needs to be
restarted when that devices gets re-created.

So far got some results by making the necessary ubus calls equivalent of
"ubus call network reload" via the C interface, and waiting for the ubus
events also thru the C API, but sometimes it seems I get a "ifup" ({
"network.interface": {"action":"ifup","interface":"moni"} }) event
before the device is really available, because directly after that,
getting the MAC address by SIOCGIFHWADDR ioctl fails...

Any ideas?

bruno
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel