http://bugzilla.suse.com/show_bug.cgi?id=975020 Bug ID: 975020 Summary: kernel does not send NEWLINK on changes caused by IPv6 RA Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: mkubecek@suse.com Reporter: mt@suse.com QA Contact: qa-bugs@suse.de CC: mt@suse.com, okir@suse.com, tiwai@suse.com, wicked-maintainers@suse.de Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #934067 +++ When RA arrives, the kernel is applying the RA flags (net/ipv6/ndisc.c): /* * Remember the managed/otherconf flags from most recently * received RA message (RFC 2462) -- yoshfuji */ in6_dev->if_flags = (in6_dev->if_flags & ~(IF_RA_MANAGED | IF_RA_OTHERCONF)) | (ra_msg->icmph.icmp6_addrconf_managed ? IF_RA_MANAGED : 0) | (ra_msg->icmph.icmp6_addrconf_other ? IF_RA_OTHERCONF : 0); .... but sends NEWLINK only when ra_msg->retrans_timer or ra_msg->reachable_time are set. Many routes send 0 here, what just means unspecified: https://tools.ietf.org/html/rfc4861#section-4.2 Reachable Time 32-bit unsigned integer. The time, in milliseconds, that a node assumes a neighbor is reachable after having received a reachability confirmation. Used by the Neighbor Unreachability Detection algorithm (see Section 7.3). A value of zero means unspecified (by this router). Retrans Timer 32-bit unsigned integer. The time, in milliseconds, between retransmitted Neighbor Solicitation messages. Used by address resolution and the Neighbor Unreachability Detection algorithm (see Sections 7.2 and 7.3). A value of zero means unspecified (by this router). https://tools.ietf.org/html/rfc4861#section-6.3.4 6.3.4. Processing Received Router Advertisements A Router Advertisement field (e.g., Cur Hop Limit, Reachable Time, and Retrans Timer) may contain a value denoting that it is unspecified. In such cases, the parameter should be ignored and the host should continue using whatever value it is already using. In particular, a host MUST NOT interpret the unspecified value as meaning change back to the default value that was in use before the first Router Advertisement was received. This rule prevents hosts from continually changing an internal variable when one router advertises a specific value, but other routers advertise the unspecified value. IMO there is no reason to send RTM_NEWLINK only, when these values are given and ignore other changes like the managed/other-config flags, which are applied, just the event aren't sent. Patches addressing this issue are accepted upstream: http://patchwork.ozlabs.org/patch/512486/ http://patchwork.ozlabs.org/patch/512646/ -- You are receiving this mail because: You are on the CC list for the bug.