<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 1, 2015 at 2:49 PM, Felix Fietkau <span dir="ltr"><<a href="mailto:nbd@openwrt.org" target="_blank">nbd@openwrt.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015-09-01 14:43, Hans Dedecker wrote:<br>
> The function set_state disable is not called for external devices in device_release<br>
> which means for external vlan/macvlan devices they won't be deleted.<br>
> As a result of this the set_state enable call for external devices by device_claim fails<br>
> as vlan/macvlan devices cannot be created since the device already exists in the kernel.<br>
> Therefore move the external device check from device_set_state to device_claim so<br>
> external vlan/macvlan devices are not created again and can also be external.<br>
Why/how do vlan/macvlan devices become external?<br></blockquote><div>This use case is driven by an external application which is adding a vlan device to the bridge.</div><div>Initially the vlan device is created as an internal device but not added to the bridge; later added by an external application via ubus to the bridge. In this scenario we hit the issue when doing network reload the vlan device is not anymore an active member of the bridge as vlan set_state enable was called which failed.</div><div>This is a bit similar to a wireless device which has uci device config; initially it's considered as an internal device by netifd when loading the config but becomes an external device when the wireless logic adds it to the bridge.</div><div><br></div><div>Hans</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
- Felix<br>
</font></span></blockquote></div><br></div></div>