[radvd-devel-l] radvd on freetz (Fritzbox mod) - radvd[1865]: setsockopt(IPV6_RECVPKTINFO): Protocol not available

[Pekka Savola]

Hi,

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
     other applications.

  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.

     Wrt. radvd:

     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
     somewhere)

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 
well.)

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