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

Frank Kardel kardel at ntp.org
Tue Sep 12 17:10:43 UTC 2006

xntp at skopos.be (Luc Pardon) writes:

>  >>>     Finally, the message is logged twice.
>  >> As these read errors are logged with LOG_ERR could it be that your syslog configuration
>  >> is a bit strange
>      Yoy must have been a diplomat in a previous life. Of course it was "a bit strange". Fixed now, thanks (again).
Almost true. I am a consultant - not an insultant (most of the time).

>  >>    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 see. A glance at the man pages seem to say the address ought to be filled in, but it's not clear if that's true also in case of error. In any case, I had a look at ntp_io.c and I don't see anything obvious where it would get lost.

The usual Unix rule of system call interfaces is that nothing is changed when an error occurs. In case of ECONNREFUSED the behaviour across all
platforms ntpd runs on is at best undefined (though some/all versions of Linux may fill it in). So we are a bit limited of what we can 
reliably dig out. NetBSD would not give such errors on recvfrom for example. Linux apparently does.

>  > 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.
>       FWIW, ECONNREFUSED is listed in man (2) recvfrom on one Linux system with a 2.4.20 kernel and on another one with a 2.6.17 kernel.
>      Also, I am absolutely sure that I got "connection refused" errors last year when my ISP had blocked port 123 in the ADSL router so my client couldn't reach the servers. I also saw them when some server was temporarily down. I'm less sure it was on recvfrom, but I think so.
I don't deny that. But is seems to be more and more an implementation detail for a specific platform.

>  >>    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.
>     Working on that. Meaning: contacted them, they're working and I'm watching (the logs). There was some progress yesterday, none today. There are no more icmp packets. Now it's just udp/123 replies to requests that I didn't send. But at least they don't appear in syslog.
You are not NATting anything ? A broken NAT config/device could give this too if other systems from your network do queries that get mapped
to your primary system - but that's just a guess. Just like forged send IP would be. Maybe you could double check at your outgoing link
(inner and outer interface) for correlations like that.

>  >>     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.
>     There is not much I can do to help at this point, I suppose?
>     The strange packets are no longer coming in and in any case, I don't have the resources right now to hook up a Linux box with a more recent kernel to see what would happen.
Well, at least things did a bit improve, didn't they :-) ?

>     Luc Pardon
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions


More information about the questions mailing list