-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Robert, Martin,
On 09/20/2013 08:13 PM, Robert Edmonds wrote: > martin f krafft wrote: >> Package: unbound Version: 1.4.20-1 Severity: normal Tags: >> upstream >> >> Arguably a problem with ifupdown (#705996), unbound fails to bind >> an IPv6 socket that is "tentative": >> >> [1377457127] unbound[2694:0] error: can't bind socket: Cannot >> assign requested address [1377457127] unbound[2694:0] debug: >> failed address 2001:a60:f0fb::1 port 53 [1377457127] >> unbound[2694:0] fatal error: could not open ports >> >> As a result, unbound fails to start. >> >> As long as there are other sockets (v4 or v6) to bind to, >> unbound should just start with those, and monitor the ones it >> failed to bind on startup, keep retrying until success. See ntpd >> for an example of a daemon that does this right. Instead of having statically entered IP addresses in unbound, you can set interface-automatic. This binds to the ::0 and 0.0.0.0 (everything), and responds to incoming traffic on all interfaces. It detects the interface a packet was received on and replies from that interface. This could maybe work with DAD (not sure what that does)? Robert, unbound is already an event-based design. Not sure how I would get events to retry bind() attempts. Or know which bind() attempts were 'optional'. Right now it treats ipv6 when 'implicitly there' (by defaults) as 'optional' in case ipv6 is not supported. Best regards, Wouter >> -- System Information: Debian Release: jessie/sid Architecture: >> amd64 (x86_64) Foreign Architectures: i386 >> >> Kernel: Linux 3.10-rc7-amd64 (SMP w/4 CPU cores) Locale: >> LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh >> linked to /bin/dash >> >> Versions of packages unbound depends on: ii adduser >> 3.113+nmu3 ii libc6 2.17-92 ii libevent-2.0-5 >> 2.0.21-stable-1 ii libgcc1 1:4.8.1-9 ii libldns1 >> 1.6.16-1 ii libpython2.7 2.7.5-7 ii libssl1.0.0 >> 1.0.1e-3 ii openssl 1.0.1e-3 ii unbound-anchor >> 1.4.20-1 >> >> unbound recommends no packages. >> >> unbound suggests no packages. >> >> -- Configuration Files: /etc/unbound/unbound.conf changed [not >> included] >> >> -- no debconf information >> >> >> -- .''`. martin f. krafft <madduck@d.o> Related projects: >> : :' : proud Debian developer >> http://debiansystem.info `. `'` >> http://people.debian.org/~madduck http://vcs-pkg.org `- >> Debian - when you have better things to do than fixing systems > > hi, madduck: > > i ran into this recently on my home network but i can't reproduce > it now, unfortunately. i've re-read the ifupdown bug report [0] > and the thread on tentative addresses on debian-devel [1] and i'm > not sure there is a whole lot unbound can do (but Cc'ing wouter, > just in case); "have upstream convert the app to an event-based > approach" is not that great of an answer, in general. (iirc, there > was some special requirement that resulted in ntpd behaving the way > it does -- something like the protocol requiring that packets be > sourced from port 123, not just destined to that port.) > > i would be worried that just retrying the bind() until success may > result in misconfiguration going unnoticed. can a daemon readily > distinguish between a bind() that fails due to the address being in > the tentative state vs. a plain typo? ideally typo'd addresses > ought to be found immediately at daemon startup rather than just > generating log output. > > i found anecdotal reports from ubuntu users that DAD might have > been generating false positives [2,3,4]. that seems plausible. i > wasn't able to track down why i was getting DADs in my home > network. > > as a workaround only, i guess it might be possible to disable DAD > entirely with the accept_dad and dad_transmits IPv6 sysctl > settings. that seems no worse than the situation with IPv4 on > debian, where duplicate addresses go undetected. (though i believe > other linux distros do an ARP-based check prior to adding an IPv4 > address to an interface.) > > there's also the optimistic_dad IPv6 sysctl which appears to > implement RFC 4429 [5], though it specifically warns, "Optimistic > DAD SHOULD NOT be used for manually entered addresses." i'm not > sure if this would help work around this issue at all, or if > addresses in the "optimistic" state behave any differently from > those in the "tentative" state as far as bind() is concerned. > > i'm inclined to call this a bug in ifupdown [0]. if you have a > statically configured IPv6 address in /etc/network/interfaces, > ifup should only return once the interface is fully up or failed to > come up. i guess we could add a note to > /usr/share/doc/unbound/NEWS.Debian warning about the issue, > though. > > [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705996 [1] > http://thread.gmane.org/gmane.linux.debian.devel.general/177841 [2] > http://timesinker.blogspot.com/2009/11/karmic-ipv6-global-address-problems.html > > [3] http://nonblocking-random.blogspot.com/2010/04/duplicate-ipv6-address-detection-in.html > [4] http://ubuntuforums.org/showthread.php?t=2113822 [5] > http://tools.ietf.org/html/rfc4429 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSP+baAAoJEJ9vHC1+BF+N2SUP/jfAXnfCvapOlBbptUM1Pfi2 hnjcPbIO1ZLlx4PphSJqxjNoCT9rEkxjTzCOpUDY1JoNFiiQrJ2LMMNzAGadPs24 WAc0lBOdqpOsccnPKD3bn0kri1C2lFgIMcxKER9ddGecSVNxU0FBzTaNS1/ov5A4 OPUgYrN21P+oFu4SV3Rudc231HGewaJNokUtyGHNd2CDuIlekONa5eUlVxinh3Vd 9P7V0Z0JextLcKLd5vArB2XDvrX+vbAXhTzMVJK0dlzNtwySGjbCfhPFc5Y4Wegi WAoWi0LqACVgiNGtH3l4WPGyIT+zNAZqin/nj4szBP/E7TjBVvRVlJU48d15p+Y2 5vHbhZr89xBEII8Fp0JykBsMshJOAvFls++eK4GIysMxKKnEk/mp4A42Q1Fin7t/ 9hTuH+hoNKuOHuglaLgL2rnoHUTnSjrTvvkHV7/Qkvmd9J/JB3rgI8fTFVDBLxWE zboOE9xTmKDoykkLn/Gg99nFxpx2p1zMOvvm7es6VZ0hZDG1VIqgLS1Ct7FairJH pzmOSIIMlUrsEJD7lG/AIGeLWdwCtRxavLOdLcNLsK1fh428C0/WrJgN8g/glCdo ZEYp2wgTJRr2OYFFMCd+7ZWtETrDedRJ6USxmmesoOIp+ezg9zI7mV1YFWyrXGi0 BESGyhmDrzZyBxpoFVse =beX/ -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
