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

Danny Mayer mayer at ntp.isc.org
Sun Sep 10 21:50:26 UTC 2006


Luc Pardon wrote:
> Well, I'm about to give up.
> 
> My logs are getting flooded with "Connection refused" messages and I
> can't find why, much less how to stop them.
> 
> This is a rather oldish RH Linux box with two network cards. One is
> connected to the bad world outside via an ADSL router, the other to the
> internal network (192.168.x.x). It gets its time from stratum 2 servers
> and provides time to the internal network.
> 
> I've been running ntp on that box since 2001. In June 2005, I upgraded
> to ntp 4.2.0.

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. You need to
upgrade to 4.2.3p? to fix this. The new code will rebind to the new
addresses dynamically. Don't try p42, apparently it's broken.

> 
> This is not the case now, ntpd can reach the outside servers and syncs
> and serves the internal network just fine. Also, 'ntpq -p' showed 'reach
> 377' for all servers, including 193.190.230.65. Besides, fd 9 is the
> socket on the ADSL-facing card (192.168.254.2), so packets to/from the
> internal 192.168.1.3 have no business going there.
> 

Right, and that's because your IP address changed.

> 
> After 8 hours or so, the critters went away. I hate problems going away
> just like that. Fortunately (not!), they came back two days later, on
> Sep  5 08:01:15. They left again at 10:58:19, only to reappear the next
> day at 08:01:17 and leave again at 11:44:13. Back again next day, Sep 7
> 00:01:18 and lasted until 09:23 when I stopped ntpd.
> 

How often does your ISP forceable change your DHCP-supplied IP address?
You can find out from the lease limit.

> This is because I checked the mailing list and decided to upgrade to
> 4.2.2p3. Almost as soon as I started the new version, the "connection
> refused" was back, but different now:
> 
>> Sep  7 09:24:25 gida ntpd[26405]: ntpd 4.2.2p3 at 1.1577-o Thu Sep  7
> 07:05:22 UTC
>> 2006 (1)
>> Sep  7 09:24:25 gida ntpd[26406]: precision = 1.000 usec
>> Sep  7 09:24:25 gida ntpd: ntpd startup succeeded
>> Sep  7 09:24:26 gida ntpd[26406]: Listening on interface wildcard,
> 0.0.0.0#123 Disabled
>> Sep  7 09:24:26 gida ntpd[26406]: Listening on interface lo,
> 127.0.0.1#123 Enabled
>> Sep  7 09:24:26 gida ntpd[26406]: Listening on interface eth0,
> 192.168.1.23#123
>> Enabled
>> Sep  7 09:24:26 gida ntpd[26406]: Listening on interface eth1,
> 192.168.254.2#123 Enabled
>> Sep  7 09:24:26 gida ntpd[26406]: kernel time sync status 0040
>> Sep  7 09:24:32 gida ntpd[26406]: frequency initialized 128.381 PPM
> from /etc/ntp/drift
>> Sep  7 09:24:32 gida ntpd[26406]: recvfrom(0.0.0.0) fd=51: Connection
> refused
>> Sep  7 09:24:32 gida ntpd[26406]: recvfrom(0.0.0.0) fd=51: Connection
> refused
>> Sep  7 09:25:34 gida ntpd[26406]: recvfrom(0.0.0.0) fd=51: Connection
> refused
>> Sep  7 09:25:34 gida ntpd[26406]: recvfrom(0.0.0.0) fd=51: Connection
> refused
>> Sep  7 09:26:38 gida ntpd[26406]: recvfrom(0.0.0.0) fd=51: Connection
> refused
>> Sep  7 09:26:38 gida ntpd[26406]: recvfrom(0.0.0.0) fd=51: Connection
> refused
>> Sep  7 09:27:42 gida ntpd[26406]: recvfrom(0.0.0.0) fd=51: Connection
> refused
>> Sep  7 09:27:42 gida ntpd[26406]: recvfrom(0.0.0.0) fd=51: Connection
> refused
>> Sep  7 09:27:50 gida ntpd[26406]: synchronized to 193.190.230.66,
> stratum 1
>> Sep  7 09:27:50 gida ntpd[26406]: kernel time sync enabled 0001
>> Sep  7 09:28:46 gida ntpd[26406]: recvfrom(0.0.0.0) fd=51: Connection
> refused
> 
>   Note that, at startup, it says "Listening on interface wildcard,
> 0.0.0.0#123 Disabled" but that seems a blatant lie since lsof shows that
> it does have a socket open there.
> 

Sorry about that. Disabled was a convenient term. What it really means
is that any packet arriving on the wildcard address will be just dropped
and there will never be a response.

>   The 'refused' messages come two at a time and in 64 second intervals.
> 
>   I tried adding a line 'manycastclient 224.1.1.1' to ntp.conf. The
> messages stopped and came back. So it doesn't make a difference.
> 

If there is a multicast server on the subnet and you have not set up
ntpd as a multicast client then you may see these messages on the
wildcard address. It is not clear to me whether or not multicast packets
should be delivered to the wildcard address if you have not set up ntpd
to receive multicast packets. That's really an IP multicast question,
but we have seen that behavior on a number of O/S's.

>   I tried removing the 'restrict' lines from ntp.conf but it doesn't
> make a difference.
> 

It has nothing to do with this.

>   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 noticed that 193.190.230.66 is a stratum 1 server and not a 2 like
> the others. Either I missed that when I added it to ntp.conf in May 2005
> or they changed from 2 to 1 since then. In any case I removed it but it
> doesn't make any difference.
> 
>   I tried the debug output but it doesn't tell me anything. All I can
> make of it is that there is only one 'refused' in the debug output and
> two in the syslog. Also, the 'refused' comes after several seconds of
> silence in the debug output. It doesn't tell me why it thinks it should
> call recvfrom.
> 

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.

>   Needless to say, "tcpdump -i eth1 port ntp" (eth1 being fd 51) doesn't
> show activity that might be related to the refusals.
> 
> #--------------------------
> $ tail -f /var/log/messages | grep ntp
> 
> 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,
> 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.

> Sep  8 11:24:54 gida ntpd[8769]: kernel time sync status 0040
> Sep  8 11:24:54 gida ntpd[8769]: frequency initialized 129.083 PPM from
> /etc/ntp/drift
> Sep  8 11:25:04 gida ntpd[8769]: recvfrom(0.0.0.0) fd=51: Connection
> refused
> Sep  8 11:25:04 gida ntpd[8769]: recvfrom(0.0.0.0) fd=51: Connection
> refused
> 

Looks like it didn't bind to the wildcard address, hence the error.

> 
> #--------------------------
> $ 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.

I need to check why it's not binding to the wildcard address. That's
required even though it's not used.

Danny



More information about the questions mailing list