NTP

[Geoff Shang]

Hi,

Thanks everyone for your responses.

On Fri, 2 May 2014, Shlomi Fish wrote:

> I've had a similar problem on my laptop and I solved it by running "ntpdate
> -u" (Where "-u" tells it to use the unprivileged port which is also used by
> the "-d" flag which worked) instead of a regular "ntpdate". I'm telling it
> to inform everybody.

This is what I've been doing, but it's not really a substitute for 
something that should be working, and was until 4 weeks ago.

On Thu, 1 May 2014, Tzafrir Cohen wrote:

> Have you tried il.pool.ntp.org ?

Yes.  There's only one server on it, which does appear to be working.

# ntpdate -q 0.il.pool.ntp.org
server 212.199.182.150, stratum 2, offset -1.246416, delay 0.03937
  4 May 12:55:52 ntpdate[12996]: step time server 212.199.182.150 offset -1.246416 sec

I'm surprised that ntp.iix.net.il isn't in the pool.

On Fri, 2 May 2014, Baruch Siach wrote:

> ntp.iix.net.il works for me from home (012), and work (BezeqBL).

good to know.  At least this tells me it's not an ISP-wide issue.

On Fri, 2 May 2014, Amos Shapira wrote:

> 1. If you are running ntp daemons on your linux machines then use ntpq to
> query what it thinks it synchs with and its synch status.

I've done this.

# ntpq -p
      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
  Israel-IX.iix.n 192.115.209.50   2 u 1415   64    0    0.000    0.000   0.000

Interestingly, an check earlier in the day suggests it did get through 
once.

# ntpq -p
      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
  Israel-IX.iix.n 192.115.209.50   2 u  188   64    4   14.213  -153.40   0.004

Here's what the iMac shows:

$ ntpq -p
      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
  time.euro.apple .XFAC.          16 u    -  68m    0    0.000    0.000   0.000

> 2. Use traceroute with UDP port 123 to see whether you manage to reach the
> server you pick.

Ah!  This is what I wanted.

The manpage for traceroute is a bit confusing to me, but I tried this 
command which I think should tell me what I want to know:

# traceroute -p 123 ntp.iix.net.il
traceroute to ntp.iix.net.il (192.114.62.250), 30 hops max, 60 byte 
packets
  1  router.home (192.168.2.1)  1.988 ms  1.690 ms  1.534 ms
  2  bzq-109-64-64-1.red.bezeqint.net (109.64.64.1)  14.809 ms  14.740 ms  14.603 ms
  3  bzq-179-14-70.static.bezeqint.net (212.179.14.70)  14.594 ms  14.488 ms  14.607 ms
  4  bzq-25-77-6.static.bezeqint.net (212.25.77.6)  18.304 ms  18.147 ms  17.891 ms
  5  bzq-219-189-102.cablep.bezeqint.net (62.219.189.102)  15.135 ms  15.056 ms  14.916 ms
  6  * * *
  7  * * *
  8  * * *

I tried from an external server that is able to sync and reached the 
requested host.  So this would indicate that Bezeqint is blocking it.

On Fri, 2 May 2014, E.S. Rosenberg wrote:

> I've never had trouble with NTP... my guess is your ISP is blocking or
> interfering, get a level 2 or better rep. they should be able to unblock it
> if you make enough noise...

I think you're right.  We're paying them enough for service.

Thanks,
Geoff.