[radvd-devel-l] radvd on freetz (Fritzbox mod) - radvd: setsockopt(IPV6_RECVPKTINFO): Protocol not available
pekkas at netcore.fi
Sat Jan 17 14:34:58 EST 2009
On Sat, 17 Jan 2009, Paul Oranje wrote:
> the patch fails:
> checking if IPV6_RECVPKTINFO is defined that it also works with kernel... configure: error: cannot run test
> program while cross compiling
> thanks a lot though, for now I shall not further seek help form this mailing list, bye
Hmm. It appears that in a cross-compiler environment this problem is
difficult to fix in the generic case.
1) this is a bug in uClibc because it does not properly document the
required kernel version to run it. Recent versions have copied
header files from later kernels, and newer versions of uClibc
do not work properly with older kernels.
A possible way to address this problem at its roots (uClibc) is to
patch out IPV6_RECV* #defines in
libc/sysdeps/linux/common/bits/in.h and change the value of
IPV6_PKTINFO. Essentially by double checking the numbers in
kernel's include/linux/in6.h. But there are likely also other
breakages in the kernel interface that will cause problems with
2) Alternative is to update the kernel to a sufficiently recent
version or patch backport relevant net/ipv6/ipv6_sockglue.c
changes from recent kernels.
3) This could be worked around in radvd and every other application
using features of the kernel interface that are broken.
a) I could consider adding patches of like provided by Freetz
project, but these are a bit problematic for two reasons: they
only work if the kernel versions being run closely matches the
kernel uclibc version was compiled, and this fix needs to be done
in every application. If the kernel is updated later on but radvd
is not, it also sticks to using the old interface. However, this
is not really a big problem as long as the kernel doesn't remove
the old 2292 setsockopt interface.
b) I tried to make a generic solution, but that fails with
cross-compiling, so "automatic" solution is not doable.
c) I could also consider adding a smaller subset patch that
would still require manual patching but at least that patch
would be simple (e.g. defining HAVE_BROKEN_IPV6_RECVPKTINFO
Given that the Freetz project appears to be a system integrator,
providing both the library and kernel for its users, either 1) or 2)
seems like a good choice from the architectural point of view. That
way other apps that may also use other broken features of the kernel
interface could also work without modifications (I'd suspect that some
other IPv6 apps are also broken, and some multicast apps could be as
But I could also consider a)-c) especially if this was only supposed
to address short-term issue, and there was already work going on to
develop a longer-term fix.
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
More information about the radvd-devel-l