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

Frank Kardel kardel at ntp.org
Sun Sep 10 17:03:44 UTC 2006


xntp at skopos.be (Luc Pardon) writes:

> 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.
>
> Life was beautiful for more than a year until, last week, I suddenly started getting "Connection refused" messages in syslog.
>
>  > Sep  3 04:06:32 gida ntpd[4796]: recvfrom(193.190.230.65) fd=9: Connection refused
>  > Sep  3 04:06:32 gida ntpd[4796]: recvfrom(193.190.230.65) fd=9: 
> Connection refused
This error message from the kernel is a bit unusual, but you said it was running on Linux...

>
> 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
>
>    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.
>
The socket being bound does not allow you to call that a lie. The Disabled information just documents that pakets received on that
socket will be discarded.

>    The 'refused' messages come two at a time and in 64 second intervals.
>
So it seems to be related with some query activity.

>    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.
>
>    I tried removing the 'restrict' lines from ntp.conf but it doesn't make a difference.
restrict is not related to this behavior.

>
>    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.
>
>    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.
The socket seems to be ready for reading (select && SIGIO). when ntpd reads from it it gets the error message from the kernel. As I said getting that on a recvfrom is unusal
and delivered from the kernel - ntpd just documents that.

>
>    Needless to say, "tcpdump -i eth1 port ntp" (eth1 being fd 51) doesn't show activity that might be related to the refusals.
I suspect that icmp messages (probably port unreachable) being received. So try "tcpdump -i eth1 port ntp or icmp" and see whether
such icmp messages show up and who sends them.

>
>    One thing that I should add is that I can't ntpq locally on that machine. It  says "Name or service not known". From what I can see with strace it seems to be looking in /etc/services from something. But I wouldn't know what, "ntp" is definitely in there. In any case, this started happening one year ago so it should have nothing to do with the "refused" messages (but maybe with the ntp 4.1.x to 4.2.x transition). I can query the box remotely, from another Linux, without problems.
This looks like a local setup problem other system have following line in /etc/services:
ntp             123/udp                         # Network Time Protocol

Frank




More information about the questions mailing list