Hi,
On Fri, Feb 19, 2010 at 08:33:04PM +0100, Gert Doering wrote:
> > [uclibc without UCLIBC_HAS_IPV6]
>
> I have to investigate.
And so I did. The impact of UCLIBC_HAS_IPV6=0 is fairly low:
- getaddrinfo() will not resolve IPv6 addresses (but *will* be available)
- the external globals in6addr_any and in6addr_loopback will not
be compiled in (in6_addr.c).
** I expect this to cause linking problems for my code **
- inet_ntop6() and inet_pton6() will not be compiled-in - both are only
called indirectly, from inet_ntop() and inet_pton(), respectively, for
af AF_INET6. So trying to convert IPv6 addresses will fail at run-time.
[side note: that's actually the same code as in the FreeBSD libc,
and as such, fully threadsafe :-) )
- __opensock() refuses AF_INET6 sockets at run-time
- the resolv.c functions (gethostbyname2, gethostbyaddr, __dns_lookup,
__read_etc_hosts_r, gethostent, ...) will not resolve / handle IPv6
addresses
- the relevant *definitions* (struct in6_addr etc) are all there, all
the time, and not depending on UCLIBC_HAS_IPV6.
I don't have a system available for testing, but I would expect that
OpenVPN with my patches compiled/linked against an IPv4-only uClibc
would fail due to unavailability of "in6addr_any", which can be fairly
easily worked-around [reports welcome!].
The other stuff should not cause any adverse run-time effects - if IPv6
isn't compiled in the library, OpenVPN will just not accept
"--ifconfig-ipv6" and similar commands (because parsing the IPv6
addresses fails, and thus the addresses are refused as "invalid"), but
everything else will just work as-is.
As said: I would welcome contact to someone who is using uClibc+OpenVPN
and could help me test this and adapt the code if needed.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
