On Thu, Mar 9, 2017 at 10:20 PM, Matthias Schiffer
<mschiffer at universe-factory.net> wrote:
> On 03/09/2017 05:32 PM, Hans Dedecker wrote:
>> Trigger interface update event when IPv6 address lifetime changes by
setting
>> the address indicator flag to inform external subsystems about IPv6
address
>> lifetime change.
>>
>> Signed-off-by: Hans Dedecker <dedeckeh at gmail.com>
>
> AFAICT, this will cause a lot of ifupdate events in big IPv6 networks
(for
> example, some large mesh networks based on Gluon have more than 4000
client
> and 5-10 radvds, often causing more than one RA per second, each updating
> valid/preferred lifetimes). We *really* want to avoid causing lots of
> reloads for services that set triggers on interface updates; the majority
> of services is not interested in the lifetimes of addresses at all.
>
> Matthias
>
>
>> ---
>> interface-ip.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/interface-ip.c b/interface-ip.c
>> index ddca5d2..366f69a 100644
>> --- a/interface-ip.c
>> +++ b/interface-ip.c
>> @@ -563,8 +563,10 @@ interface_update_proto_addr(struct vlist_tree
*tree,
>> keep = false;
>>
>> if (a_old->valid_until != a_new->valid_until ||
>> - a_old->preferred_until !=
a_new->preferred_until)
>> + a_old->preferred_until !=
a_new->preferred_until) {
>> + iface->updated |= IUF_ADDRESS;
>> replace = true;
>> + }
>>
>> if ((a_new->flags & DEVADDR_FAMILY) == DEVADDR_INET4 &&
>> a_new->broadcast != a_old->broadcast)
It appears that the concerns with this commit have manifested as
undesirable side effects. For name servers, this flushes the cache. This
is would be a regression with perspective from other packages that use
the interface triggers only to start/reload. With my device and ISP,
this can happen as often as every 2 minutes. Please consider reverting
this commit or fix this new behavior to be a controllable feature. Maybe
enable/disable or limit to not more than every hour or other choice
time. FS#713. netifd/a03216660797173fbe67866f75564e3fec9c1e8d
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
