On 10/11/2015 09:56, Ryota Ozaki wrote:
>> Certainly in our arp and ndp code the assumption is made that if a
>> matching route is not marked RTF_CLONING then it is not a neighbour.
>
> Just confirmation, do you mean s/not a neighbour/a neighbour/?
I believe it's like so:
rt = find_route_for_address();
if (rt->rt_flags & (RTF_CLONING | RTF_CLONED)) {
/* We're a neighbour */
}
>
>> When FreeBSD dropped RTF_CLONING they added the assertation that
>> advertised routes from rtadvd(8) are neighbours also, but this is
>> currently not possible to state from userland.
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194485
>
> Hmm, I don't notice this case. Does it indicate that it is possible
> that a route has both RTF_LLINFO and RTF_CLONING? Or just we can
> think a route with RTF_CLONING as a neighbor?
The latter. A subnet route would not have RTF_LLINFO.
> Could you clarify what does dhcpcd actually require on routes (and
> routing flags)?
if (is_a_subnet_route) {
#ifdef RTF_CLONING
rtm.hdr.rtm_flags |= RTF_CLONING;
#endif
#ifdef RTP_CONNECTED
/* OpenBSD */
rtm.hdr.rtm_priority = RTP_CONNECTED;
#endif
}
>> This leads me back to my question - should all added network routes,
>> regardless of source match neighbour tests or do they need to be
>> explicitly marked as such? This has nothing todo with cloning, which is
>> the real purpose of the flag.
>
> Well, I don't have an answer yet. I think I don't know enough
> about userland requirements. How do you think of that?
So the current situation is OpenBSD have RTP_CONNECTED, FreeBSD have
nothing but seems to be implied within the kernel (certainly for IPv6,
not checked IPv4) and we are abusing RTF_CLONING.
I know that your long term goal is to drop RTF_CLONING like FreeBSD,
hence asking about this. I suppose the easy approach would be to rename
RTF_CLONING to RTF_CONNECTED.
Roy
