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!
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:
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.
In fact, I would expect this packet to be ignored, if only because of
the "restrict default ignore", no?
Finally, the message is logged twice. Once would have been enough to
flood my logs <g>.
Bottom line, my conclusions for now are:
1) the problem seems external, probably something is broken at
ntp1.belbone.be.
2) improvement in ntpd's logging could have saved me many hours of
debugging (conclusion, not criticism)
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).
4) there is nothing I can do at this point to prevent this from
happening in the future.
Please correct me if I'm wrong.
Any light that can be shedded on the 'why' of this would be welcome too.
Thanks for all the help.
Luc
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
