Hi,
It seems netifd itself and batman-adv also has a similar problem. See
the lines below:
./batadv.sh: eval: line 1: can't create
/sys/class/net/mesh0/batman_adv/mesh_iface: nonexistent directory
Tue Mar 31 09:38:01 2015 daemon.notice netifd: radio0 (6033): ifconfig:
SIOCSIFHWADDR: Invalid argument
This only happens sometimes, not always... More log:
Tue Mar 31 09:38:00 2015 daemon.info confsync[5896]: Interface moni is up
Tue Mar 31 09:38:00 2015 daemon.notice netifd: Interface 'moni' is now up
Tue Mar 31 09:38:00 2015 daemon.notice netifd: mesh (5931): ./batadv.sh:
eval: line 1: can't create /sys/class/net/mesh0/batman_adv/mesh_iface:
nonexistent directory
Tue Mar 31 09:38:00 2015 daemon.notice netifd: Network device 'moni0'
link is down
Tue Mar 31 09:38:00 2015 daemon.notice netifd: Interface 'moni' has link
connectivity loss
Tue Mar 31 09:38:00 2015 daemon.notice netifd: Interface 'moni' is now down
Tue Mar 31 09:38:00 2015 daemon.err confsync[5896]: MAC addr ioctl failed
Tue Mar 31 09:38:00 2015 daemon.notice netifd: Interface 'moni' is disabled
Tue Mar 31 09:38:00 2015 daemon.notice netifd: Interface 'moni' is enabled
Tue Mar 31 09:38:00 2015 daemon.notice netifd: Interface 'moni' is disabled
Tue Mar 31 09:38:01 2015 daemon.notice netifd: Interface 'moni' is enabled
Tue Mar 31 09:38:01 2015 daemon.notice netifd: Network device 'moni0'
link is up
Tue Mar 31 09:38:01 2015 daemon.notice netifd: Interface 'moni' has link
connectivity
Tue Mar 31 09:38:01 2015 daemon.notice netifd: Interface 'moni' is
setting up now
Tue Mar 31 09:38:01 2015 daemon.notice netifd: Interface 'moni' is now up
Tue Mar 31 09:38:01 2015 daemon.notice netifd: radio0 (6033): ifconfig:
SIOCSIFHWADDR: Invalid argument
bruno
On 03/30/2015 11:56 PM, Bruno Randolf wrote:
> 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@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
