[ntp:questions] recvfrom( fd=51: Connection refused

Luc Pardon 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[8768]: ntpd 4.2.3p39 at 1.1395-o 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,
>> Enabled
>> Sep  8 11:24:54 gida ntpd[8769]: Listening on interface #2 eth0,
>> Enabled
>> Sep  8 11:24:54 gida ntpd[8769]: Listening on interface #3 eth1,
>> 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
>> ntpd       8769        root   50u  IPv4 92307975       UDP
>> ntpd       8769        root   51u  IPv4 92307977       UDP
> 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 mailing list