0

I have connected a system with NTP client on a local network with windows system on which NTP server is running. The problem is client is not able to sync the time with server.

NTP version: 4.2.8p13 (on client)

NTP conf file (UPDATED):

driftfile /etc/ntp.drift
restrict -4 default
restrict -6 default
server -6 fddb::abe7:8164:14eb:2222 iburst

ntpq -npcrv result (UPDATED):

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 fddb::abe7:8164 .LOCL.           1 u    5   64    3    0.752  3925.18   1.286

associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
version="ntpd 4.2.8p13@1.3847-o Fri Mar 20 17:38:42 UTC 2020 (2)",
processor="armv7l", system="Linux/4.1.15", leap=11, stratum=16,
precision=-19, rootdelay=0.000, rootdisp=1.125, refid=INIT,
reftime=(no time),
clock=e22c442f.99e69f37  Mon, Mar 30 2020 15:40:55.601, peer=0, tc=3,
mintc=3, offset=0.000000, frequency=0.000, sys_jitter=0.000000,
clk_jitter=0.002, clk_wander=0.000

But when I update the time using ntpdate command, time gets synchronized. I have restarted the daemon many times but still the system is not syncing the time through ntpd.

Any help will be appreciated.

Thanks in Advance!

Anon
  • 25
  • 2
  • 7
  • Found one issue: kernel logs: "ntpd[1091]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized" Do any one have idea what is it;s solution? – Anon Mar 26 '20 at 11:45

1 Answers1

1

Your time is not syncing because your clock is too far out. Your offset is 2808682 milliseconds, which is over 46 minutes. Make sure your ntpd is being started with the -G flag. (Usually -g is the default.) Alternatively, set the time to within 1 second of the correct time before starting. Then restart ntpd - your time should correct itself within a few minutes.

You also have a duplicate server line in your configuration, which is not needed, but that shouldn't be stopping things from working.

You should also remove the restrict default line, which is much too permissive and allows remote systems to query your ntpd and opens it up to being used in reflective DDOS attacks. The preferred configuration nowadays is something more like this:

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Needed for adding pool entries
restrict source notrap nomodify noquery

The error about the clock being unsynchronized is a symptom of this problem, not the cause.

Paul Gear
  • 4,367
  • 19
  • 38
  • I've set the time within 1 min range and after waiting for hours it is not syncing up. Also when i execute the command ntptime it is giving return code 5. Is it affecting this mis-behaviorr in any way ? – Anon Mar 27 '20 at 05:15
  • actually I noticed today that offset is decreasing very slowly. I've already added "iburst" in the conf file but still the sync-up is very slow – Anon Mar 27 '20 at 07:32
  • Set the time, then gather the output of `ntpq -npcrv` and show your exact config file again - there might be something else you missed. – Paul Gear Mar 27 '20 at 11:26
  • I've updated the conf file and the ntpq results in the question itself – Anon Mar 30 '20 at 07:30
  • Your source server is synchronized to its local clock rather than a useful lower stratum source. It's likely that both it and your local clock are unstable and thus cannot usefully synchronize with each other. Get more time sources, and make sure that they have proper connections to reliable stratum 1 servers. – Paul Gear Mar 30 '20 at 10:41
  • Could it be that WIndows is not set up correctly? NTP uses UTC as time base, while windows traditionally used local time. The offset in the question is more than one hour! – U. Windl Feb 09 '22 at 08:50