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
