Re: CVS commit: src/sys/netinet

[Roy Marples <roy%marples.name@localhost>]

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_*.

>>>> 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!

Roy