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

Frank Kardel kardel at ntp.org
Mon Sep 11 10:51:49 UTC 2006


xntp at skopos.be (Luc Pardon) writes:

> 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!
Glad to help !
>
>     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:
>
I cannot speculate what happens there, these pakets might even forged and sent
with the wrong source address. I have no Idea why.

>> 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.
Actually ntpd does not know where these paket come from - it just gets a read error from the kernel without
any address indication.
What ntpd lists as address is the local address to which the socket is bound where the read error occurred.

>    In fact, I would expect this packet to be ignored, if only because of the "restrict default ignore", no?
There is actually no paket - just a failed recvfrom(). So nothing to ignore.

>
>     Finally, the message is logged twice. Once would have been enough to flood my logs <g>.
As these read errors are logged with LOG_ERR could it be that your syslog configuration
is a bit strange in that the error level messages are logged into the same file which also
logs lower level messages. The message is only generated once in ntpd, but the above scenario
would duplicate messages above a certain level. Please check your syslog configuration.

>
>
>    Bottom line, my conclusions for now are:
>
>    1) the problem seems external, probably something is broken at ntp1.belbone.be.
Could be anything, misconfiguration there, forged source addresses (unlikely but possible).

>
>    2) improvement in ntpd's logging could have saved me many hours of debugging (conclusion, not criticism)
The daemon does not have a chance, no address data is given from the kernel to the daemon. I am not even sure
whether Linux should report those icmp pakets as read errors - ECONNREFUSED is not even an allowed errorcode
in NetBSD's recvfrom for comparison. This might be a confusion helped by implementation details of Linux (or the version you use).

>
>    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).
Block his icmp messages.
But I think notification would be a good thing. Maybe something bigger is wrong there.

>
>    4) there is nothing I can do at this point to prevent this from happening in the future.
block icmps dealing with ntp port. Try out other versions of Linux, *BSD and other Unix variants.

>
>     Please correct me if I'm wrong.
See above for my thoughts.

>
>     Any light that can be shedded on the 'why' of this would be welcome too.
>
No real idea, but This is the first time I see this reported. I am still not
sure whether Linux behaves correctly here - I would have to look into the
specs though.

>     Thanks for all the help.
>
>     Luc
>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions

Regards,
  Frank




More information about the questions mailing list