On Wed, Nov 11, 2015 at 7:10 PM, Roy Marples <r...@marples.name> wrote: > On 11/11/2015 07:26, Ryota Ozaki wrote: >> 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... > > 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