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

Luc Pardon xntp at skopos.be
Mon Sep 11 09:47:13 UTC 2006


Frank Kardel wrote:
> xntp at skopos.be (Luc Pardon) writes:
>>    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.

    Bang, spot on!

    The culprit is ntp1.belbone.be, sending icmp packets to my box for 
whatever reason.

    The interesting thing is, this server is not in my ntp.conf. It was 
in there - for a short time - a few days ago. But as best I can tell it 
was not in there when the "refused" messages started on Sept 2. His 
brother, ntp2.belbone.be, has been there all the time, but has a 
different IP.

    Of course this got me wondering if ntp1.belbone.be is the only 
culprit. You'll remember that, while I still had ntp 4.2.0 installed, 
the "connection refused" messages showed not 0.0.0.0 but several 
different IP's, including internal ones.

    As it turns out, 4.2.0 is plain wrong.

    I briefly reverted to ntp 4.2.0 and it seems to show a left-over IP 
from the previous packet exchange.

    For example, I see a normal udp/123 query/response to/from the ntp 
server at IP 195.13.1.153 (ntp2.belbone.be). Then, 24 seconds later, 
comes the next icmp packet from ntp1.belbone.be. It's IP is 195.13.23.5 
but the syslog entry has the ntp2.belbone.be IP:

> Sep 11 09:26:44 gida ntpd[30638]: recvfrom(195.13.1.153) fd=9: Connection refused
> Sep 11 09:26:44 gida ntpd[30638]: recvfrom(195.13.1.153) fd=9: Connection refused

   Same for other icmp's. If it comes right after an incoming time query 
from one of the internal clients, that client's internal IP is what 
shows up in syslog.

   So, this (reporting the wrong source) was a bug in 4.2.0 that is now 
more or less fixed in 4.2.3p39.

   I say more or less because I still think that ntpd should at least 
display the correct IP, i.e. 195.13.23.5 instead of 0.0.0.0. If I had 
seen all the "refused"s coming from a single IP I might have tcpdumped 
all the traffic to/from that IP and I might have seen the icmp's.

   In fact, I would expect this packet to be ignored, if only because of 
the "restrict default ignore", no?

    Finally, the message is logged twice. Once would have been enough to 
flood my logs <g>.


   Bottom line, my conclusions for now are:

   1) the problem seems external, probably something is broken at 
ntp1.belbone.be.

   2) improvement in ntpd's logging could have saved me many hours of 
debugging (conclusion, not criticism)

   3) to make this stop (i.e. keep the message out of my logs), I can 
only firewall him out (and contact the operator - if he's listening on 
tcp/25 <g> - but I'm not sure what to tell him).

   4) there is nothing I can do at this point to prevent this from 
happening in the future.

    Please correct me if I'm wrong.

    Any light that can be shedded on the 'why' of this would be welcome too.

    Thanks for all the help.

    Luc




More information about the questions mailing list