On 2014-08-01 15:37, Hans Dedecker wrote: > Since netifd commit 75e73ab force_link is enabled by default for > proto static in the netifd code. > This causes the netifd ubus interface up event to be send based only > on the interface enabled state (and thus faster) while if linksensing is > enabled the interface ubus event up is send when the interface is both > enabled and the link has been sense d. > This timing change has some impact; eg in an application I'm > fetching the bridge port info based on the interface ubus up event. > After the force_link change for proto static all bridge port info is > not yet available as netifd is still setting up the bridge while the > ubus interface up event is already raised. > Before this was not the case as the ubus interface up event was > raised when the bridge was enabled (all bridge ports configured) and link has > been sensed. > I was wondering why the behavior was hardcoded changed in netifd for > proto static although the same behavior could be achieved by setting the > uci parameter force_link to 1. Not having a static IP address added automatically when an interface is available was causing regular user confusion and bogus bug reports. I assumed that unlike dhcp, the static proto didn't really need dynamic enabling/disabling based on the link status. What bridge port info is your application fetching, and why is it not available yet when the event is sent?
- Felix _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
