NTP client bug

I found a bug in the NTP client implementation of RouterOS.

This is seen on a RB750g v3. 6.37.3
It has SNTP installed as default, but since I did not get it to work, and I also like to have an NTP server, I installed the NTP full package.

After installing NTP package I configured my NTP server with two (known working) NTP server IP.
17.253.52.125 and 185.41.243.30
But any thing I try I did only get this message:

status: started

Searching Google I did find several post that did have the same problem, with various solution, but nothing worked for me.
I did also try 10.10.10.5 (my Cisco switch), but not working.

So looking closer to this, I did see the following:

/system ntp client print
          enabled: yes
             mode: unicast
      primary-ntp: 17.253.52.125
    secondary-ntp: 185.41.243.30
  dynamic-servers: 1.2.3.1
           status: started

Where did the 1.2.3.1 came from?
It looks to came from my ISP!

So how to fix this?
IP DHCP Client and remove Use Peer NTP

Then viola status: synchronized

/system ntp client print
          enabled: yes
             mode: unicast
      primary-ntp: 17.253.52.125
    secondary-ntp: 185.41.243.30
  dynamic-servers:
           status: synchronized

So what is the bug?
I looks like if the NTP client get a not working server, it does not synchronize!!
Why should the dynamic-servers: 1.2.3.1 make all the NTP stop working?
One working should be enough??

Hi there,

Try the following which is what I use here:

/system ntp client
set enabled=yes primary-ntp=195.66.241.2 secondary-ntp=129.250.35.250

Replace the IP’s with whatever you want to use. These are ntp0.linx.net & 0.uk.pool.ntp.org which are the ones with the lowest latency for me.

/system ntp client print
             enabled: yes
         primary-ntp: 195.66.241.2
       secondary-ntp: 129.250.35.250
    server-dns-names: 
                mode: unicast
       poll-interval: 15m
       active-server: 195.66.241.2
    last-update-from: 195.66.241.2
  last-update-before: 18m7s990ms
     last-adjustment: 1ms683us

My ISP doesn’t send any NTP details down the link so I can’t confirm or deny on your “possible” bug, however setting them up manual like this should resolve your issue (assuming its not a bug).

HTH

Server you list does work fine.
Problem is that my ISP sends out a NTP server that does not work.
You can not get rid of the dynamic IP by setting manually NTP server. You need to remove “Use Peer NTP” from the DHCP client.

I can confirm that problem still exist in 6.38.1

This seems to be fixed in 6.38.3

If I now accept the wrong NTP IP from my provider, it tells me that its synchronized

/system ntp client print 
          enabled: yes
             mode: unicast
      primary-ntp: 17.253.52.125
    secondary-ntp: 185.41.243.30
  dynamic-servers: 1.2.3.1
           status: synchronized

I thought this was fixed, but in 6.39.2 I see this.

Enable use if NTP server (non working NTP ip) I get this:

/system ntp client print
          enabled: yes
             mode: unicast
      primary-ntp: 17.253.52.125
    secondary-ntp: 185.41.243.30
  dynamic-servers: 1.2.3.1
           status: started

If I disable the NTP that coming from my ISP:

/system ntp client print
          enabled: yes
             mode: unicast
      primary-ntp: 17.253.52.125
    secondary-ntp: 185.41.243.30
  dynamic-servers:
           status: synchronized

So NTP breaks when it get the non working NTP with IP 1.2.3.1

Hi.
Can you simulate the problem and the generate a supout.rif to send to MT’s support?
This is a better way to report the problem to them.

+1

I lost several hours by this bug (v6.42.7 on hAP ac).

My provider has wrong NTP address in their DHCP and even if I used correct addresses in NTP setting, Mikrotik is using only the wrong from DHCP.

Finally I found this post.

I can confirm that it is still a problem on latest version.

Without DHCP NTP

/system ntp client print
          enabled: yes
             mode: unicast
      primary-ntp: 17.253.52.125
    secondary-ntp: 185.41.243.30
  dynamic-servers:
           status: synchronized

Whith DHCP NTP

 /system ntp client print
          enabled: yes
             mode: unicast
      primary-ntp: 17.253.52.125
    secondary-ntp: 185.41.243.30
  dynamic-servers: 1.2.3.1
           status: started

It very simple to reproduce, so MT should be able to test this and find out what is wrong.

Still not fixed in 6.43.2


It just show started when I do get a non working DNS from DHCP

 /system ntp client print
          enabled: yes
             mode: unicast
      primary-ntp: 17.253.52.125
    secondary-ntp: 185.41.243.30
  dynamic-servers: 1.2.3.1
           status: started

Disable DNS NTP and all ok.

/system ntp client print
          enabled: yes
             mode: unicast
      primary-ntp: 17.253.52.125
    secondary-ntp: 185.41.243.30
  dynamic-servers:
           status: synchronized

I am just curious why you still try to use “Use Peer NTP” from your ISP while you know it is not working? :slight_smile:
And did you try to contact your ISP to fix his DHCP NTP address setup?

I do not try to use wrong IP, just to test to see if MT has fixed their bug.

I have a ticket on MT for some time on the NTP bug. Ticket#2018083022003469
They telling that they are working on it, but I do not see any progress.

Problem is that when I did set up NTP, I did just use the server that I did get from my ISP.
I did not work, (1.2.3.4), so I tried to add some static server that I do know that works.
But this did not work either, still not synced. So MT should fix this so other do not use time to try to solve it.
Yes I have sent email to my ISP, but have not got any response.

So there are three part with problems here.

  1. Clients that do not get working NTP since its wrong IP.
  2. ISP that uses the wrong IP.
  3. MT that stops syncing when a non working IP is listed.

Make sure udp port 123 is accepted for that ntp server on firewall

Port is correct.

There are just to wrong thing here.

  1. Mikrotik NTP stops working if it gest a non working NTP Ip. This MT can fix.
  2. My ISP sending a none working NTP IP. This my ISP should have fixed, but talking to them is like talk to a stone.

Thanks for this, I also have been racking my brain for a few days on this one.

Once the ISP NTP server was removed, timesync started working as it should have from day 1.

Saved my sanity finding this post!