[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