being rejected - comp.protocols.time.ntp

Hi group, My ntp clients keep being rejected, and I don't know how to debug it. I don't even know if it's the client that rejects the server or the server that rejects the client. ntpq shows this: # ntpq localhost ntpq> peers remote refid st t when poll reach delay offset jitter ============================================================================== gelbbaer.kn-bre .INIT. 16 - - 1024 0 0.000 0.000 0.000 svr02.teleport- .INIT. 16 - - 1024 0 0.000 0.000 0.000 coprophiliac.de .INIT. 16 - - 1024 0 0.000 0.000 0.000 formularfetisch .INIT. 16 - - 1024 0 0.000 0.000 0.000 ntpq> as ind assID status conf reach auth condition last_event cnt =========================================================== 1 61694 8000 yes yes none reject 2 61695 8000 yes yes none reject 3 61696 8000 yes yes none reject 4 61697 8000 yes yes none reject Now what does this mean? Why is my time not being synced? Where should I look for the problem? thanks in advance...

a@b.cd wrote: > > ind assID status conf reach auth condition last_event cnt > =========================================================== > 1 61694 8000 yes yes none reject > 2 61695 8000 yes yes none reject > 3 61696 8000 yes yes none reject > 4 61697 8000 yes yes none reject > > Now what does this mean? Why is my time not being synced? Where should I look for the problem? > Please do rv 61694, etc., but using the current assID values. You have some rather strange domain names as sources. Are these by any chance local machines running w32time. A common reason for rejecting w32time is that it is reporting very large root dispersions, because it hasn't been synchronised sufficiently recently to provide a time with acceptable error bounds.

>My ntp clients keep being rejected, and I don't know how to debug it. I don't even know if it's the >client that rejects the server or the server that rejects the client. ntpq shows this: Do you have any restrict statements in your config file? If so, comment them out and try again. Do you have any firewall rules that might block UDP traffic to port 123? -- These are my opinions, not necessarily my employer's. I hate spam.

David Woolley wrote: > a@b.cd wrote: > >> >> ind assID status conf reach auth condition last_event cnt >> =========================================================== >> 1 61694 8000 yes yes none reject >> 2 61695 8000 yes yes none reject >> 3 61696 8000 yes yes none reject >> 4 61697 8000 yes yes none reject >> >> Now what does this mean? Why is my time not being synced? Where should I >> look for the problem? >> > > Please do rv 61694, etc., but using the current assID values. ntpq> rv 61694 assID=61694 status=8000 unreach, conf, no events, srcadr=gelbbaer.kn-bremen.de, srcport=123, dstadr=0.0.0.0, dstport=0, leap=11, stratum=16, precision=-20, rootdelay=0.000, rootdispersion=0.000, refid=INIT, reach=000, unreach=38, hmode=3, pmode=0, hpoll=10, ppoll=10, flash=00 ok, keyid=0, ttl=0, offset=0.000, delay=0.000, dispersion=15937.500, jitter=0.000, reftime=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, org=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, rec=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, xmt=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, filtoffset= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, filtdisp= 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 ntpq> rv 61695 assID=61695 status=8000 unreach, conf, no events, srcadr=svr02.teleport-iabg.de, srcport=123, dstadr=0.0.0.0, dstport=0, leap=11, stratum=16, precision=-20, rootdelay=0.000, rootdispersion=0.000, refid=INIT, reach=000, unreach=38, hmode=3, pmode=0, hpoll=10, ppoll=10, flash=00 ok, keyid=0, ttl=0, offset=0.000, delay=0.000, dispersion=15937.500, jitter=0.000, reftime=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, org=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, rec=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, xmt=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, filtoffset= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, filtdisp= 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 ntpq> rv 61696 assID=61696 status=8000 unreach, conf, no events, srcadr=coprophiliac.de, srcport=123, dstadr=0.0.0.0, dstport=0, leap=11, stratum=16, precision=-20, rootdelay=0.000, rootdispersion=0.000, refid=INIT, reach=000, unreach=38, hmode=3, pmode=0, hpoll=10, ppoll=10, flash=00 ok, keyid=0, ttl=0, offset=0.000, delay=0.000, dispersion=15937.500, jitter=0.000, reftime=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, org=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, rec=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, xmt=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, filtoffset= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, filtdisp= 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 ntpq> rv 61697 assID=61697 status=8000 unreach, conf, no events, srcadr=formularfetischisten.de, srcport=123, dstadr=0.0.0.0, dstport=0, leap=11, stratum=16, precision=-20, rootdelay=0.000, rootdispersion=0.000, refid=INIT, reach=000, unreach=38, hmode=3, pmode=0, hpoll=10, ppoll=10, flash=00 ok, keyid=0, ttl=0, offset=0.000, delay=0.000, dispersion=15937.500, jitter=0.000, reftime=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, org=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, rec=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, xmt=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, filtoffset= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, filtdisp= 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 > You have some rather strange domain names as sources. Are these by any > chance local machines running w32time. A common reason for rejecting > w32time is that it is reporting very large root dispersions, because it > hasn't been synchronised sufficiently recently to provide a time with > acceptable error bounds. No, these hosts are actually redirects from [1234].gentoo.pool.ntp.org. All of them are reachable on port 123/UDP via nmap, so it's definitely not a connectivity issue. But thanks for the quick replies so far...

a@b.cd wrote: >>> 1 61694 8000 yes yes none reject > assID=61694 status=8000 unreach, conf, no events, I don't know why it is saying reach on the assoc, but the rv is certainly saying that nothing is coming back, which normally does mean a firewall problem. Often port 123 is firewalled off even though the port used for connectivity tests is not.

David Woolley wrote: > a@b.cd wrote: > >>>> 1 61694 8000 yes yes none reject > >> assID=61694 status=8000 unreach, conf, no events, > > > I don't know why it is saying reach on the assoc, but the rv is > certainly saying that nothing is coming back, which normally does mean a > firewall problem. Often port 123 is firewalled off even though the port > used for connectivity tests is not. But the reply packets are comin' thru no problem. I can see them with tcpdump: # tcpdump -ieth0 -s0 -vvv port ntp tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 16:51:13.668692 IP (tos 0xc0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 76) 192.168.10.235.ntp > 85.31.187.67.ntp: [bad udp cksum a719!] NTPv4, length 48 Client, Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 6s, precision -20 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3495624673.668643295 (2010/10/09 14:51:13) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3495624673.668643295 (2010/10/09 14:51:13) 16:51:13.725737 IP (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto UDP (17), length 76) 85.31.187.67.ntp > 192.168.10.235.ntp: [udp sum ok] NTPv4, length 48 Server, Leap indicator: (0), Stratum 2 (secondary reference), poll 6s, precision -8 Root Delay: 0.012069, Root dispersion: 0.032516, Reference-ID: 129.69.1.153 Reference Timestamp: 3495624222.340305030 (2010/10/09 14:43:42) Originator Timestamp: 3495624673.668643295 (2010/10/09 14:51:13) Receive Timestamp: 3495624673.882986783 (2010/10/09 14:51:13) Transmit Timestamp: 3495624673.883182883 (2010/10/09 14:51:13) Originator - Receive Timestamp: +0.214343518 Originator - Transmit Timestamp: +0.214539602 16:51:14.668741 IP (tos 0xc0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 76) 192.168.10.235.ntp > 141.40.103.101.ntp: [bad udp cksum fa90!] NTPv4, length 48 Client, Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 6s, precision -20 Root Delay: 0.000000, Root dispersion: 0.000015, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3495624674.668700516 (2010/10/09 14:51:14) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3495624674.668700516 (2010/10/09 14:51:14) 16:51:14.716766 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], proto UDP (17), length 76) 141.40.103.101.ntp > 192.168.10.235.ntp: [udp sum ok] NTPv4, length 48 Server, Leap indicator: (0), Stratum 2 (secondary reference), poll 6s, precision -20 Root Delay: 0.006301, Root dispersion: 0.042770, Reference-ID: 134.34.3.18 Reference Timestamp: 3495622992.015513980 (2010/10/09 14:23:12) Originator Timestamp: 3495624674.668700516 (2010/10/09 14:51:14) Receive Timestamp: 3495624674.866683959 (2010/10/09 14:51:14) Transmit Timestamp: 3495624674.866705596 (2010/10/09 14:51:14) Originator - Receive Timestamp: +0.197983473 Originator - Transmit Timestamp: +0.198005080 ..... So it really can't be a connectivity issue, can it?

Hal Murray wrote: > Do you have any restrict statements in your config file? If so, > comment them out and try again. Tried that, but doesn't change anything. Do they even affect client operations? I thought they were about server functionality.

a@b.cd wrote: > David Woolley wrote: > >> a@b.cd wrote: >> >>>>> 1 61694 8000 yes yes none reject >> >>> assID=61694 status=8000 unreach, conf, no events, >> >> >> I don't know why it is saying reach on the assoc, but the rv is >> certainly saying that nothing is coming back, which normally does mean a >> firewall problem. Often port 123 is firewalled off even though the port >> used for connectivity tests is not. > > But the reply packets are comin' thru no problem. I can see them with > tcpdump: > > # tcpdump -ieth0 -s0 -vvv port ntp > tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size > .... > > So it really can't be a connectivity issue, can it? Wait, now that I *can* see the packets, the associations actually look like this: ntpq> as ind assid status conf reach auth condition last_event cnt =========================================================== 1 13136 9344 yes yes none outlyer reachable 4 2 13137 942a yes yes none candidate sys_peer 2 3 13138 962a yes yes none sys.peer sys_peer 2 4 13139 9414 yes yes none candidate reachable 1 Which looks fine to me. It seems it was the -I lo option I was passing to ntpd. But why that would prevent it from *sending* out ANY traffic is beyond me. This client/server-in-one-app-thing is really confusing, especially if the docs don't make it clear what part of the operation particular options refer to.

On 10/8/2010 5:17 PM, a@b.cd wrote: > Hi group, > > My ntp clients keep being rejected, and I don't know how to debug it. I don't even know if it's the > client that rejects the server or the server that rejects the client. ntpq shows this: > > # ntpq localhost > ntpq> peers > remote refid st t when poll reach delay offset jitter > ============================================================================== > gelbbaer.kn-bre .INIT. 16 - - 1024 0 0.000 0.000 0.000 > svr02.teleport- .INIT. 16 - - 1024 0 0.000 0.000 0.000 > coprophiliac.de .INIT. 16 - - 1024 0 0.000 0.000 0.000 > formularfetisch .INIT. 16 - - 1024 0 0.000 0.000 0.000 > ntpq> as > > ind assID status conf reach auth condition last_event cnt > =========================================================== > 1 61694 8000 yes yes none reject > 2 61695 8000 yes yes none reject > 3 61696 8000 yes yes none reject > 4 61697 8000 yes yes none reject > > Now what does this mean? Why is my time not being synced? Where should I look for the problem? > > thanks in advance... It's telling you that NONE of the four servers you have configured has responded to a NTP query. Time is not being synched because there is nothing to sync to!

Richard B. Gilbert wrote: >> ind assID status conf reach auth condition last_event cnt >> =========================================================== >> 1 61694 8000 yes yes none reject >> 2 61695 8000 yes yes none reject >> 3 61696 8000 yes yes none reject >> 4 61697 8000 yes yes none reject >> >> Now what does this mean? Why is my time not being synced? Where should >> I look for the problem? >> >> thanks in advance... > > It's telling you that NONE of the four servers you have configured has > responded to a NTP query. Time is not being synched because there is > nothing to sync to! > Again you weren't paying attention, as he has solved the problem. However the problem is that doesn't appear to saying what you claim it is saying. What it seems to be saying is that it is receiving responses (reach = yes), but they are unacceptable. This may be a misfeature in the way that a total lack of response is reported.

Similiar Articles:

iTonesPASS, Download Tones For iPhone - comp.sys.mac.hardware.misc ...
TecheSpot: iTonesPASS, Download Tones For iPhone iTonesPass, after being rejected as the AppStore application by Apple. Developers created another way so that users ...

clock not synching with low stratum time server - comp.protocols ...
It's almost certainly being rejected as a falseticker before its stratum can be considered. One of the problems with local clocks is that they give a falsely narrow ...

Internal hosts being blocked by spamhaus.org - comp.mail.sendmail ...
... Your mail server (myserver.dahl-stamnes.net) belongs to a known spammer - rejected! ... That's why people are unhappy about ntpdate being ... ntpd > 4) periodicaly check ...

OS X won't accept my username/password - comp.sys.mac.system ...
I entered my credentials and the OS rejected them. This behavior is new to me because ... Some applications have permissions set weridly that prevent them from being ...

NTP Stratum 16? - comp.protocols.time.ntp
In all cases ntpdc shows packets being sent and received, but ntpd does not ... My guess is that it's not your daemon getting > rejected by the server, but your ...

scripting a telnet session to VMS - comp.os.vms
If this connection is being made over the internet, I would suggest you use a ... You "receive a message that says the VMS host has rejected my request". VMS doesn't ...

RedBack HP-UX 11 - comp.sys.hp.hpux
... the redback bits, you could consider running tcpdump on the interface(s) being used ... ECONNREFUSED typically implies > a connection attempt was made and actively rejected ...

handling special characters in sqlldr - comp.databases.oracle ...
Error with loading .dat file - comp.soft-sys.matlab handling special characters in sqlldr - comp.databases.oracle ..... with the following messege: Record 1: Rejected ...

edit box population in a dialog box (win32) - comp.lang.asm.x86 ...
... invalid data, it > shows up on screen for a fraction of a second before it's rejected. ... this approach: * wait for WM_COMMAND * check for EN_CHANGE * verify the box being ...

Are newbie questions OK in here? - comp.lang.asm.x86
Yes and no: I distinctly remember being positively surprised maybe 10 years ago ... Otherwise, a compiler that rejected this program would not be compliant: int main ...

Being Rejected And Low Self Esteem - Squidoo : Welcome to Squidoo
Being rejected by others can affect our self image and cause low self esteem. Being rejected is always hurtful, no matter what the circumstances. It can cause ...

Dealing with rejection | 2KnowMySelf
Have you ever been rejected? Check out the ultimate guide to dealing with rejection

7/25/2012 4:17:53 AM