[rbldnsd] Disabling ipv6-specific tests

[Jeff Dairiki]

On Mon, Jul 29, 2013 at 08:52:29PM -0400, Michael Orlitzky wrote:
> On 07/29/2013 08:19 PM, Jeff Dairiki wrote:
> >>
> >>   ERROR: test_exclusion (test_ip6trie.TestIp6TrieDataset)
> >>   ----------------------------------------------------------------------
> >>   Traceback (most recent call last):
> >>     File "/home/mjo/src/rbldnsd/test_ip6trie.py", line 31, in
> >>     test_exclusion
> >>       self.assertEqual(dnsd.query(rfc3152("dead::beef")), None)
> >>     File "/home/mjo/src/rbldnsd/test_ip6trie.py", line 22, in rfc3152
> >>       bytes = unpack("16B", inet_pton(AF_INET6, ip6addr))
> >>   error: can't use AF_INET6, IPv6 is disabled
> > 
> > Urgh.  I guess the choices are:
> > 
> >  - Re-implement enough of inet_pton() to get by.  Let me sleep on it
> >    to see if I can come up with a clean/simple way to do that.
> > 
> >  - Replace the calls to rfc3152() by hand-coded constants.  (Ugly and hard
> >    to read, but there are only two calls to rfc3152.)
> 
> We could just comment it as such and say it requires ipv6 for now.
> 
> A relatively small subset of people are going to run into these problems
> -- most people enable or disable ipv6 globally. For the corner-cases, we
> just don't want the tests to /fail/ (it looks bad, triggers bug reports,
> and makes people stop running the tests). If they skip a test it's not
> the end of the world. Everyone else with ipv6 enabled globally will be
> running it.

The test is testing something that should work.  It's the
implementation of the test that is causing the trouble.  I don't want
to skip it just because the test itself is broken on a particular
architecture.  (That mostly negates the point of the test.)

I'll work on finding a not-too-ugly alternative to inet_pton.

> > What does 'host localhost' produce on this system?
> 
>  $ host localhost
>  localhost has address 127.0.0.1
>  localhost has IPv6 address ::1
> 
> 
> > How about (quick-and-dirty way to see what the gethostbyname() libc
> > function returns):
> > 
> >   python -c "import socket; print socket.gethostbyname_ex('localhost')"
> 
>  $ python -c "import socket; print socket.gethostbyname_ex('localhost')"
>  ('localhost', [], ['127.0.0.1', '127.0.0.1'])

Wierd, but there's the problem.

Gethostbyname() returns 127.0.0.1 twice.  This causes initsockets() to
attempt to open two listening sockets on 127.0.0.1.  The second call
to newsocket() fails with "address in use", because the address is
indeed in use by the socket opened by the first call to newsocket().

I guess this problem only crops up on systems where the kernel/libc
support ipv6, but ipv6 is explicitly disabled during the compilation of
rbldnsd.

Two possible fixes:

Quick-and-dirty:

  Kluge initsockets() to check for and ignore duplicate IPs returned
  by gethostbyname().

Probably the "correct" fix:

  Use getaddrinfo() (when available) instead of (the deprecated)
  gethostbyname(), even when -DNO_IPv6 is set.

  This would require, I think, splitting the functionality of
  NO_IPv6 into two C defs.  Currently the default state for NO_IPv6
  is determined by a configure test for getnameinfo/getaddrinfo, but
  it can be overridden by --enable-ipv6 or --disable-ipv6.  We would
  need a new macro, say NO_GETADDRINFO which would be set depending
  solely on the result of the configure test for
  getnameinfo/getaddrinfo.

(A third fix would be to just get rid of the the --{enable,disable}-ipv6
overrides to the configure script, so that the state of NO_IPv6 truly
indicates whether getaddrinfo() is supported.)


I like the second option better, but, before comitting to that, it's
worth checking that it would work.

Please check the output of:

   python -c "from socket import *; print getaddrinfo('localhost', 5300, 0, AF_INET)"

It should produce something like (with just a single entry for '127.0.0.1'):

   [(2, 2, 17, '', ('127.0.0.1', 5300))]



Oop.  Just found this glibc bug report:
  http://sourceware.org/bugzilla/show_bug.cgi?id=4980

Apparently this is/was a known bug/not-a-bug in glibc at some
point. (I can't quite tell if this was eventually "fixed" or not.)  The
ticket makes for entertaining reading, in any case.

Jeff