>>> 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
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
