Re: CVS commit: src/sys/netinet

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Wed, Nov 11, 2015 at 7:10 PM, Roy Marples <roy%marples.name@localhost> wrote:
> On 11/11/2015 07:26, Ryota Ozaki wrote:
>> On Tue, Nov 10, 2015 at 10:30 PM, Roy Marples <roy%marples.name@localhost> 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...
>
> Great!
> ARP and NDP use that to add know if they should create LLINFO entries.
>
>>>>> 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?
>
> No, OpenBSD has RTP_CONNECTED, a flag for route priority.
> We don't have route priorities, so it would need to be RTF_*.

Oh, I meant dhcpcd can now use RTF_CONNECTED that is recently
introduced in OpenBSD for the OpenBSD case in dhcpcd?
Using RTF_CONNECTED instead of RTP_CONNECTED looks straightforward
(if it's possible).

>
>>>>> 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.
>
> Nice.
>
>> 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?
>
> I've looked at the rarpd code and I don't think it needs changing
> because it relies on an existing subnet route marked RTF_CLONING to
> already exist, so each route it RTM_GETs will be marked RTF_CLONED and
> thus considered a neighbour. Also, we only care about it being a
> neighbour in the kernel when we want to create LLINFO entries from ARP
> or NDP messages (iirc), so the direct manipulation here bypassses that
> check.
>
> Adding / removing ARP entries via arp(8) would have the same effect.
>
> Saying that I've not actually run or tested rarpd, nor inspected the
> routing table modifications it makes when running. My analysis could be
> wrong!

Your explanation matches my understanding, so we should be correct :)

Anyway I keep in mind your concern. Thanks!

  ozaki-r