[LEDE-DEV] [PATCH netifd] Revert: set prefix indicator flag when IPv6 prefix lifetime, changes

Eric Luehrsen ericluehrsen at hotmail.com
Mon Apr 24 19:09:43 PDT 2017


Hi Hans

I guess I should have double checked FS#713. I thought it was set to 
notify, and just wasn't touched. Sorry about that.

wrt:
 > As explained in FS#713 reverting this patch will lead to complaints
 > from people homenet is broken
 > (https://github.com/openwrt/openwrt/issues/346[1]); a more
 > fundamental fix is required possible in procd to fix the issue.

Just a collection of thoughts: If HNET is "broken," then is HNET the 
daemon that needs a change not netifd? If a network parameter is a 
trivial change, then should a daemon use ubus/dbus/whatever to poll it 
on its own schedule? If a network parameter is critical to function like 
address (non-wildcard binding) or route, then isn't the network manager 
necessary to announce the surprise updates? If a package is "core," then 
shouldn't it be cared for more than something more external? Do we want 
dnsmasq to flush its cache frequently in the default LEDE distro, or do 
we want HNET to work (for how many users)? If procd isn't discerning 
about trigger types, then is netifd update premature? Should procd be 
fixed before netifd? As LEDE gets supplemented with more packages, we 
need delay-trigger control like LEDE, but frequent noise like this 
doesn't help?

I see a few issues with a balanced path to a solution.  So maybe a 
better plan could be revert this for _now_ and have a less troublesome 
change with procd and netifd updated coherently.

Thanks

Eric



More information about the Lede-dev mailing list