I think I've got to the bottom of the problem and found a solution. The dnsmasq code uses a similar approach to handling IPv4 / IPv6 wildcard addresses. In dnsmasq-2.49/src/config.h there's a specific block of code which sets the IPV6_V6ONLY macro for uClibc platforms because this is not set as standard by uClibc 0.9.28. In uClibc 0.9.29 a setting for IPV6_V6ONLY has been added to uClibc's libc/sysdeps/linux/common/bits/in.h file.
By adding a definition of the macro IPV6_V6ONLY to the ntpd source code (ntpd/ntp_io.c) I have created a version of ntpd that runs OK when IPv6 is enabled, plus it actually seems to work using IPv6 addresses as well as IPv4 addresses. I'll run it for a while myself to check that it is stable and doesn't have other problems and then upload it to CVS. NTP version 4.2.4p8 seems like the best option to go for since 4.2.6 gives a much larger executable for little obvious benefit. davidMbrooke On Fri, 2010-01-01 at 20:24 +0000, davidMbrooke wrote: > Hi, > > I recently enabled IPv6 support on my firewall (Bering-uClibc > 3.1.1-beta3) and mostly it's working fine. There is however a problem > with the ntp daemon from package ntpd.lrp (version 4.2.4p3 Rev 1). I > have been using "classic" ntpd in preference to openntpd because I have > had problems with openntpd crashing in the past and I like the better > status reporting that comes with ntpd. > > Without IPv6 (i.e. without kernel module ipv6.o loaded) ntpd works fine. > The output in /var/log/daemon.log looks like this: > > ntpd[866]: ntpd 4.2....@1.1502 Tue Jan 20 10:48:02 UTC 2009 (1) > ntpd[868]: signal_no_reset: signal 13 had flags 4000000 > ntpd[868]: precision = 2.000 usec > ntpd[868]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled > ntpd[868]: Listening on interface #1 lo, 127.0.0.1#123 Enabled > ntpd[868]: Listening on interface #2 eth0, 192.168.10.66#123 Enabled > ntpd[868]: kernel time sync status 0040 > > Simply by running "insmod ipv6" and then "svi ntp restart" it changes to > this: > > ntpd[888]: ntpd 4.2....@1.1502 Tue Jan 20 10:48:02 UTC 2009 (1) > ntpd[890]: signal_no_reset: signal 13 had flags 4000000 > ntpd[890]: precision = 2.000 usec > ntpd[890]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled > ntpd[890]: unable to bind to wildcard socket address :: - another > process may be running - EXIT > > There's a discussion of the problem on the ntp:questions mailing list: > http://149.20.54.235/pipermail/questions/2007-April/013832.html > In summary, on Linux, when a process opens port 123 on the IPv4 wildcard > address "0.0.0.0" this also opens the IPv6 wildcard address "::" so that > when ntpd later tries to specifically open the IPv6 address it fails. > > > There are some #ifdef entries in the ntp source code which look like > they should address this problem (in particular those checking for > IPV6_V6ONLY) but for some reason they're not working on Bering-uClibc. > > I'm running standard ntpd (4.2.4p8) on Fedora 12, with IPv4 and IPv6 > addresses, and that works great. I therefore tried building 4.2.4p8 and > also the latest stable version, 4.2.6, for Bering-uClibc but they all > fail in the same way as 4.2.4p3. > > I will keep investigating with the aim of getting both IPv4 and IPv6 to > work, but a drastic workaround is to completely disable IPv6 support in > ntpd at compile time. In file source/ntp/buildtool.mk we explicitly pass > "--enable-ipv6" to the "configure" script and changing this to > "--disable-ipv6" makes ntpd work (using only IPv4) even when IPv6 > addresses are present. I think that is a better option than having it > fail completely. > > > Has anybody solved a similar problem with other programs? Since > everything works on Fedora I think this must be due to an issue with 2.4 > kernels (as opposed to 2.6), with uClibc or with the Bering-uClibc build > environment. > > If nothing better turns up I plan to go ahead and change buildtool.mk to > remove IPv6 support from ntpd. > > > davidMbrooke > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > ------------------------------------------------------------------------ > leaf-user mailing list: leaf-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/leaf-user > Support Request -- http://leaf-project.org/ ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ------------------------------------------------------------------------ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
