[EMAIL PROTECTED] (Luc Pardon) writes: > Frank Kardel wrote: >> [EMAIL PROTECTED] (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 > [email protected] > https://lists.ntp.isc.org/mailman/listinfo/questions Regards, Frank _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
