On Fri, Nov 6, 2015 at 7:01 PM, Roy Marples <r...@marples.name> wrote: > On 06/11/2015 09:24, Ryota Ozaki wrote: >> On Fri, Nov 6, 2015 at 6:09 PM, Roy Marples <r...@marples.name> wrote: >>> On 06/11/2015 08:38, Ryota Ozaki wrote: >>>> Module Name: src >>>> Committed By: ozaki-r >>>> Date: Fri Nov 6 08:38:43 UTC 2015 >>>> >>>> Modified Files: >>>> src/sys/netinet: if_arp.c >>>> >>>> Log Message: >>>> Fix inappropriate rt_flags check >>>> >>>> It depended on either RTF_CLONED or RTF_CLONING must be set, however, >>>> the assumption didn't meet for userland problems that create a route >>>> via RTM_ADD. >>> >>> Userland can set RTF_CLONING on any route. >>> >>>> >>>> This fixes an issue that running rarpd causes the following kernel panic >>>> reported by nonaka@: >>>> panic: kernel diagnostic assertion "(la->la_flags & LLE_STATIC) == 0" >>>> failed: file "/usr/src/sys/netinet/if_arp.c", line 1339 >>> >>> While I agree that the panic should be fixed, should rarpd be fixed too >>> add the RTF_CLONING flag if indeed it is a subnet route on the attached >>> network or should userland never care about this flag and all added >>> routes should be considered as attached (keep in mind we want similar >>> semantics for IPv6 routes). >> >> I prefer the latter because allowing userland programs freely setting >> flags (and other parameters) easily breaks consistency in the kernel >> (IOW that makes keeping consistency hard). Do we need some policies on >> manipulating routes from userland? Let me know if there is already. > > I doubt we have any policy as such, but I would like all facets of a > route to be set from userland. During netbsd-6 development I recall > fixing the kernel so that userland could at least manipulate routes > including the automaticly added subnet route. > > 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/? > 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? Could you clarify what does dhcpcd actually require on routes (and routing flags)? > > 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? ozaki-r