Am 08.04.2014 08:03, schrieb Steven Barth: > Hello Heiner, > > thanks, however overriding the kernel behavior is intentional as its handling > of e.g. routes is very limited. Also getting address from both the kernel and > through dhcpv6 to netifd to the kernel causes conflicts such as the ones you > noted. If you want to use Kernel RA-handling please disable the dhcpv6 > protocol handler on said interface. > > If you really want to do this I suppose I could live with a manual switch for > odhcp6c / the dhcpv6 handler to turn of RA-handling altogether. However the > results won't be very pretty. > > > Regards, > > Steven
Steven, appreciate your feedback. My use case: I want to use temporary addresses on an autoconfigured interface and need stateless dhcpv6 for getting name server information. As netifd can't deal with temporary addresses yet I have to let the kernel take care of it. And disabling dhcpv6 is also not an option as I need it for getting the nameserver information. I'm aware that kernel handling of routes is limited and that there is good reason to handle it via a userspace application. However I wonder whether userspace and kernel doing the same thing in parallel and potentially interfering with each other is the best solution. Shouldn't either kernel or userspace do it? If someone decides to let userspace (netifd) handle routes etc. then IMHO the consequence should be that he switches off RA handling in the kernel by sysctl.conf and the respective net.ipv6.conf settings. And that's something we can detect in odhcp6c and react accordingly. Also I wouldn't want to disable RA handling completely in odhcp6c. Even if the kernel takes care of addresses and routes he doesn't recognize (yet) DNS information in RAs as defined in RfC 5006/6106. There might be good reason to let kernel and userspace take care of different parts of the RA information. By the way, as I mentioned temporary addresses: The introduction of the IFA_F_MANAGETEMPADDR flag with kernel 3.13 made it easy for userspace applications to deal with temporary addresses. Adding it to system_addr in netifd should be a minimal extension. I could check and propose a patch .. Kind regards, Heiner _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
