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

[Luc Pardon]

 >>>     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).

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

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

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


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


    Luc Pardon