[OpenWrt-Devel] [RFC] netifd: enable force_link by default for proto=static

Hans Dedecker dedeckeh at gmail.com
Fri Aug 1 10:28:18 EDT 2014


The application is retrieving all bridge ports belonging to a bridge
when it receives the interface ubus up event.
As all bridge ports are not yet configured by netifd when the ubus up
event is received in the application it retrieves only a partial
bridge port list.
Traces below show that the ifup ubus event for lan is launched before
bridge ports eth2 and eth3 are configured by netifd

Aug  1 14:15:17 OpenWrt daemon.notice netifd: Create new device
'br-lan' (Bridge)
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Initialize device 'br-lan'
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Create interface 'lan'
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Add user for device
'br-lan', refcount=1
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Add user for device
'br-lan', refcount=2
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Create simple device 'eth0'
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Initialize device 'eth0'
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Network device 'eth0' is
now present
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Add user for device
'eth0', refcount=1
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Bridge 'br-lan' is now present
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Interface 'lan', available=1
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Claim Bridge br-lan, new
active count: 1
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Claim Network device
eth0, new active count: 1
Aug  1 14:15:17 OpenWrt kern.info kernel: [10097.341000]
ADDRCONF(NETDEV_UP): eth0: link is not ready
Aug  1 14:15:17 OpenWrt kern.info kernel: [10097.350000] device eth0
entered promiscuous mode
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Interface 'lan' is enabled
Aug  1 14:15:17 OpenWrt kern.info kernel: [10097.370000]
ADDRCONF(NETDEV_UP): br-lan: link is not ready
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Create simple device 'eth1'
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Initialize device 'eth1'
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Network device 'eth1' is
now present
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Add user for device
'eth1', refcount=1
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Claim Network device
eth1, new active count: 1
Aug  1 14:15:17 OpenWrt kern.info kernel: [10097.382000]
ADDRCONF(NETDEV_UP): eth1: link is not ready
Aug  1 14:15:17 OpenWrt kern.info kernel: [10097.389000] device eth1
entered promiscuous mode

{ "network.interface": {"action":"ifup","interface":"lan"} }

Aug  1 14:15:17 OpenWrt daemon.notice netifd: Create simple device 'eth2'
Aug  1 14:15:17 OpenWrt daemon.notice netifd: Initialize device 'eth2'
[10098.273000] device wl0 entered promiscuous mode
[10098.287000] br-lan: port 5(wl0) entered forwarding state
[10098.292000] br-lan: port 5(wl0) entered forwarding state

Aug  1 14:15:18 OpenWrt daemon.notice netifd: Create simple device 'wl0'
Aug  1 14:15:18 OpenWrt daemon.notice netifd: Initialize device 'wl0'
Aug  1 14:15:18 OpenWrt daemon.notice netifd: Network device 'w
Aug  1 14:15:18 OpenWrt daemon.notice netifd: Network device 'wl0' link is up
Aug  1 14:15:18 OpenWrt daemon.notice netifd: Add user for device
'wl0', refcount=1
Aug  1 14:15:18 OpenWrt daemon.notice netifd: Claim Network device
wl0, new active count: 1
Aug  1 14:15:18 OpenWrt kern.info kernel: [10098.273000] device wl0
entered promiscuous mode
Aug  1 14:15:18 OpenWrt kern.info kernel: [10098.287000] br-lan: port
5(wl0) entered forwarding state
Aug  1 14:15:18 OpenWrt kern.info kernel: [10098.292000] br-lan: port
5(wl0) entered forwarding state
[10099.416000] br-lan: port 3(eth2) entered forwarding state
[10099.448000] br-lan: port 4(eth3) entered forwarding state

On Fri, Aug 1, 2014 at 3:56 PM, Felix Fietkau <nbd at openwrt.org> wrote:
> 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
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list