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