[ntp:questions] recvfrom(0.0.0.0) fd=51: Connection refused
xntp at skopos.be
Mon Sep 11 09:49:44 UTC 2006
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: ntpd 4.2.3p39 at 1.1395-o Fri Sep 8
>> 08:57:05 UTC 2006 (3)
>> Sep 8 11:24:54 gida ntpd: precision = 1.000 usec
>> Sep 8 11:24:54 gida ntpd: ntpd startup succeeded
>> Sep 8 11:24:54 gida ntpd: Listening on interface #1 lo,
>> 127.0.0.1#123 Enabled
>> Sep 8 11:24:54 gida ntpd: Listening on interface #2 eth0,
>> 192.168.1.23#123 Enabled
>> Sep 8 11:24:54 gida ntpd: 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?
More information about the questions