Looks good to me.

Could you please fix the following nits? Sorry for sending comments so many times separately.

Update patch:

In D21589#481177, @asomers wrote:

@hrs do you realize that the submitter is not a committer? Can you commit this change for him?

Your change looks to me trying to add IPv6 support by a copy-and-paste of the logic used in IPv4. I do not think it is a good idea in general or even for rwhod. At the time when rwhod utility was written there was an IPv4-specific API only, but nowadays we have a lot of address family independent APIs. For multicast membership management, an API defined in RFC 3678 is the standard way to support IPv4 and IPv6 in a AF-agnostic manner. Therefore, multicast support of rwhod needs a major rewrite by using this new API to support both IPv4 and non-IPv4 protocols at least. While we welcome converting an IPv4-only program to support IPv6 in an AF-independent API such as getaddrinfo(3), we do not want to add another IPv6-only code path to every single IPv4-only utility unless it is the only way to do so.

• We do not have MPLS as described in RFC 4023 or NVGRE in RFC 7637 as a kernel feature.
• RFC 8086 (GRE-in-UDP) is supported.
• I am not sure why WCCP I-Ds should be listed here. They use GRE but it is usually implemented by a userland daemon, not by kernel.

Looks good to me.

Update based on jilles's comments:

Updated to include bcr's suggestions and fix a missing length check.

In D21182#461094, @mp wrote:

Thanks! Useful and looks good to me.

In D19902#437962, @jilles wrote:

Perhaps it is cleaner to pass the int age to be searched for by reference. However, the asymmetry in the compare function is intentional as this allows finding an object with more data given the key, while having only one storage array.

As already pointed out on the mailing list, this example has a lot of problems which are not only style bugs. Ones I think as critical except for the style issues are the following:

• The function to compare two elements should accept the same type, not using an "age" field value by using a pointer type. It is a function to compare, not look up a matched element in the definition of bsearch(3). Passing a raw value as (void *) type is not impossible, but it is not suitable for a "textbook" example.
• Using assert() looks strange to me. Instead, this program should accept a value of "key" from the command line argument and show the results of bsearch(3) depending on the specified key, and this manual page should describe what results are expected.

Adding jumbo frame support looks good to me. However, is it better to support this in ether_ioctl() instead of a driver-specific ioctl handler? Check of (ifr->ifr_mtu > ETHERMTU) in ether_ioctl() can be changed to check if the interface has IFCAP_JUMBO_MTU or not.

Fixed in a different way in r334094.

In D19488#417207, @bz wrote:

In D19488#417164, @hrs wrote:

For (2), I think the old version unconditionally runs rtsol (w/o "d") when rtsold_enable="NO", and does not when rtsold_enable="YES" because rtsold (w/ "d") will be invoked later by rc.d/rtsold should handle it. In short, the condition which determines if rtsol is invoked or not depends only on "accept_rtadv" flag. Isn't it enough?

Hmm, are you sure? Looking at the logic I changed above we invoked rtsol only if rtsold was disabled and otherwise rtsold was started later and done it (so far we agree); I think that again meant that dhcp was run before the first RS/RA cycle happened hence me needing a way to trigger that early. Hence adding the extra interface flag. I think my description above was a cache miss and is wrong (I did this change months ago). I am almost tempted to remove the extra logic and run rtsol (no d) unconditionally if "accept_rtadv" and then start rtsold later or not depending on whether the user wants long-term stability and DNS options from RAs or not.
What do you think?

In D19487#417206, @bz wrote:

In D19487#417158, @hrs wrote:

Looks good to me. We might want to put an INFO log line when ND6_IFF_IPV6_ONLY flag is changed by receiving RA or link-down event so that the sysadmin can know what is going on.

Ifconfig will show the flag in the ndoptions line, in my case currently the manual one.

nd6 options=423<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,IPV6_ONLY_MANUAL>

Logging each time we receive an RA is not a good idea as the IPv4 exemption logic logging has shown me (need to fix that). Logging on every "state toggle" would be good, I agree. I'll prepare that.

One more comment: immediate change of the flag just after a link-down event may be problematic when the link is unstable. In such a situation, IPv4 packets can be allowed after a link-up and before another RA arrives even if the all of advertising routers keep sending ipv6only flag. We can assume that the interface should be configured to accept RA when the machine moves from a network to another, so sending a RS after a link-up then clearing ND6_IFF_IPV6_ONLY only when no RA arrives in a few seconds looks a more reasonable behavior. If at least one RA arrives after the RS, the normal handling of ipv6only flag works.

(1) looks good to me. For (2), I think the old version unconditionally runs rtsol (w/o "d") when rtsold_enable="NO", and does not when rtsold_enable="YES" because rtsold (w/ "d") will be invoked later by rc.d/rtsold should handle it. In short, the condition which determines if rtsol is invoked or not depends only on "accept_rtadv" flag. Isn't it enough?