Danny Mayer wrote:
Well ADSL is the clue. Your DHCP-supplied IP address is being changed
and the ntp code is still trying to use the old address.
Oops. I should have said that this box is on a static IP. Sorry!
But see my previous message, it seems the problem source is external.
I then pulled 4.2.3p39 from dev and tried again. Same thing, the only
difference is that it doesn't mention the wildcard IF at startup.
This version should work for you. You should see all addresses at
startup including the wildcard ones.
I can confirm that 4.2.3p39 only lists the two nic's and localhost
at startup, not the wildcard. The excerpt from the log (that I've left
in, below) is all there is.
The kernel is rather oldish but OTOH ntp 4.2.2p3 does show all the
IF's (as did 4.2.0) so the problem should not be with the kernel version.
Sep 8 11:24:54 gida ntpd[8768]: ntpd [EMAIL PROTECTED] Fri Sep 8
08:57:05 UTC 2006 (3)
Sep 8 11:24:54 gida ntpd[8769]: precision = 1.000 usec
Sep 8 11:24:54 gida ntpd: ntpd startup succeeded
Sep 8 11:24:54 gida ntpd[8769]: Listening on interface #1 lo,
127.0.0.1#123 Enabled
Sep 8 11:24:54 gida ntpd[8769]: Listening on interface #2 eth0,
192.168.1.23#123 Enabled
Sep 8 11:24:54 gida ntpd[8769]: Listening on interface #3 eth1,
192.168.254.2#123 Enabled
The wildcard address is missing and that's wrong.
#--------------------------
$ lsof -i -n | grep ntp
ntpd 8769 root 48u IPv4 92307937 UDP *:ntp
ntpd 8769 root 49u IPv4 92307973 UDP 127.0.0.1:ntp
ntpd 8769 root 50u IPv4 92307975 UDP 192.168.1.23:ntp
ntpd 8769 root 51u IPv4 92307977 UDP 192.168.254.2:ntp
Again no wildcard address.
Isn't the first line (fd 48) the wildcard?
I need to check why it's not binding to the wildcard address. That's
required even though it's not used.
I've been browsing through some of the messages on the list and I
won't even try to understand that <g>.
But while on the topic of listening: my tcpdumping also revealed
some suspect traffic to udp/123, from Russian dial-up lines and the
like. I would feel more comfortable if I could make it listen only on
the internal interface.
You would not normally see a "connection refused" message in recvfrom()
though if your IP address has changed it is possible.The new code should
rebind the interfaces and be able to continue. If it doesn't then you
should send us the debug output in a bug report. To get everything in
one place try using the -l stdout as a command line argument and then
all messages will go to the terminal session.
I can see the rebinding going on in the debug output all right.
Given that the problem is not in there, I don't suppose you still need
the bug report?
Luc
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
