On Tue, Nov 10, 2015 at 10:30 PM, Roy Marples <r...@marples.name> wrote:
> 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 */
> }
Now I got it. I misused "neighbor". I thought it matches RTF_LLINFO
routes...
>
>>
>>> 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
> }
Thanks. I can find it in dhcpcd.
BTW RTF_CONNECTED can be used in OpenBSD case now?
>
>>> 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.
And handle RTF_CONNECTED in the kernel like you try to do in FreeBSD
after we drop RTF_CLONING. Sound reasonable to me.
Let's back to talking about rarpd case. In general, we have to treat
adding a route with RTF_CLONING from userland. OTOH rarpd adds only
ARP entries (nexthop routes). So we don't need to change rarpd to
handle RTF_CLONING?
ozaki-r
