NTP stuck on Waiting....

simsrw73 · Mon Dec 27, 2021 9:31 pm

I cannot get NTP client working. I had this setup on my hEX S before upgrading to the rb5009 and implementing a VLAN config. I've tried several time servers and I'm pretty sure I've set it up as I had it before and made a firewall rule to open that port. But my router hangs listening for the remote NTP server and all my client network devices hang listing for the NTP server on the router. I can use the IP/Cloud service to get the time on the router, but still the other MT network devices sit there stuck on "Waiting...." What am I getting wrong? Something on the Firewall? That's my biggest weakness currently. I'm pretty sure there's some redundancies and improvements that could be made to my config...

https://github.com/simsrw73/documents/t ... smart-home


# dec/27/2021 13:27:43 by RouterOS 7.1.1
# software id = SYTB-ZK4C
#
# model = RB5009UG+S+
# serial number = EC1A0FCC6B92

/system identity
set name=RT1-Office-NR2

/interface ethernet
set [ find default-name=ether7 ] name=ether7-Access

/interface bridge
add admin-mac=DC:2C:6E:47:0F:C0 auto-mac=no name=bridge protocol-mode=none \
    vlan-filtering=yes

/interface bridge port
add bridge=bridge frame-types=admit-only-vlan-tagged interface=ether2
add bridge=bridge frame-types=admit-only-vlan-tagged interface=ether3
add bridge=bridge frame-types=admit-only-vlan-tagged interface=ether4
add bridge=bridge frame-types=admit-only-vlan-tagged interface=ether5
add bridge=bridge frame-types=admit-only-vlan-tagged interface=ether6
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether8 pvid=99
add bridge=bridge frame-types=admit-only-vlan-tagged interface=sfp-sfpplus1

/interface bridge vlan
add bridge=bridge tagged=\
    bridge,ether2,ether3,ether4,ether5,ether6,sfp-sfpplus1 vlan-ids=99
add bridge=bridge tagged=\
    bridge,ether2,ether3,ether4,ether5,ether6,sfp-sfpplus1 vlan-ids=101
add bridge=bridge tagged=\
    bridge,ether2,ether3,ether4,ether5,ether6,sfp-sfpplus1 vlan-ids=107
add bridge=bridge tagged=\
    bridge,ether2,ether3,ether4,ether5,ether6,sfp-sfpplus1 vlan-ids=119

/interface vlan
add interface=bridge name=vlan-base vlan-id=99
add interface=bridge name=vlan-guest vlan-id=101
add interface=bridge name=vlan-iot vlan-id=107
add interface=bridge name=vlan-security vlan-id=119

/interface list
add name=WAN
add name=VLAN
add name=BASE

/interface list member
add interface=ether1 list=WAN
add interface=vlan-guest list=VLAN
add interface=vlan-iot list=VLAN
add interface=vlan-base list=BASE
add interface=vlan-base list=VLAN
add interface=ether7-Access list=BASE
add interface=vlan-security list=VLAN

/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik

/ip dns
set allow-remote-requests=yes servers=\
    1.1.1.3,1.0.0.3,2606:4700:4700::1113,2606:4700:4700::1003 use-doh-server=\
    https://family.cloudflare-dns.com/dns-query verify-doh-cert=yes

/ip dhcp-client
add interface=ether1 use-peer-dns=no use-peer-ntp=no

/ip address
add address=192.168.99.1/24 interface=vlan-base network=192.168.99.0
add address=192.168.101.1/24 interface=vlan-guest network=192.168.101.0
add address=192.168.107.1/24 interface=vlan-iot network=192.168.107.0
add address=192.168.9.11/24 interface=ether7-Access network=192.168.9.0
add address=192.168.119.1/24 interface=vlan-security network=192.168.119.0

/ip pool
add name=dhcp_pool-base ranges=192.168.99.20-192.168.99.254
add name=dhcp_pool-guest ranges=192.168.101.20-192.168.101.254
add name=dhcp_pool-iot ranges=192.168.107.20-192.168.107.254
add name=dhcp_pool-security ranges=192.168.119.20-192.168.119.254

/ip dhcp-server
add address-pool=dhcp_pool-base interface=vlan-base name=dhcp-base
add address-pool=dhcp_pool-guest interface=vlan-guest name=dhcp-guest
add address-pool=dhcp_pool-iot interface=vlan-iot name=dhcp-iot
add address-pool=dhcp_pool-security interface=vlan-security name=\
    dhcp-security

/ip dhcp-server network
add address=192.168.99.0/24 gateway=192.168.99.1
add address=192.168.101.0/24 gateway=192.168.101.1
add address=192.168.107.0/24 gateway=192.168.107.1
add address=192.168.119.0/24 gateway=192.168.119.1

/ip dhcp-server lease
add address=192.168.99.10 client-id=1:8:0:27:37:29:fa comment=\
    "Home Assistant (VM on DeskBox)" mac-address=08:00:27:37:29:FA server=\
    dhcp-base

/ip firewall address-list
add address=ec1a0fcc6b92.sn.mynetname.net list=WAN_IP

/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related" \
    connection-state=established,related
add action=accept chain=input comment="Allow VLAN" in-interface-list=VLAN
add action=accept chain=input comment="Allow VLAN_BASE" in-interface=\
    vlan-base log=yes
add action=accept chain=input comment="Allow LAN NTP queries-UDP" dst-port=\
    123 in-interface-list=VLAN log=yes log-prefix=NTP:: protocol=udp
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="Drop everything else"
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related" \
    connection-state=established,related
add action=drop chain=forward comment=\
    "Isolation for wifi guest. Only allow internet." in-interface=vlan-guest \
    log=yes out-interface-list=!WAN
add action=accept chain=forward comment="Allow VLAN access Internet" \
    connection-state=new in-interface-list=VLAN out-interface-list=WAN
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
add action=drop chain=forward comment="Drop everything else"

/ip firewall nat
add action=masquerade chain=srcnat comment="Hairpin NAT" dst-address=\
    192.168.99.0/24 src-address=192.168.99.0/24
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment="Port Fwd for Home Assistant" \
    dst-address-list=WAN_IP dst-port=8123 protocol=tcp to-addresses=\
    192.168.99.10

/ip neighbor discovery-settings
set discover-interface-list=BASE

/tool mac-server
set allowed-interface-list=BASE

/tool mac-server mac-winbox
set allowed-interface-list=BASE

/ip ssh
set strong-crypto=yes

/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set api disabled=yes
set api-ssl disabled=yes

/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6

/ipv6 firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" port=\
    33434-33534 protocol=udp
add action=accept chain=input comment=\
    "defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=\
    udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 \
    protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=input comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !*2000011
add action=accept chain=forward comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment=\
    "defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" \
    hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=\
    500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=forward comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !*2000011

/system clock
set time-zone-name=America/New_York

/ip cloud
set ddns-enabled=yes

/system ntp client
set enabled=yes

/system ntp client servers
add address=time-d-g.nist.gov
add address=time-c-g.nist.gov

/system ntp server
set broadcast=yes broadcast-addresses=192.168.99.255 enabled=yes

/system routerboard settings
set cpu-frequency=auto

/ip smb shares
add comment="default share" directory=/pub name=pub
add comment="default share" directory=/pub name=pub

/ip smb users
add name=guest
add name=guest

/system scheduler
add interval=25w5d name=schedule-UpdateCACerts on-event=\
    "/system/script/run script-UpdateCACerts" policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    start-date=dec/30/2021 start-time=02:30:00

/system script
add dont-require-permissions=no name=script-UpdateCACerts owner=Yosef policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source="{\
    \r\
    \n  :do {\r\
    \n      /tool fetch url=https://mkcert.org/generate/ check-certificate=yes\
    \_dst-path=cacert.pem;\r\
    \n      /certificate remove [ find where authority expired ];\r\
    \n      /certificate import file-name=cacert.pem passphrase=\"\";\r\
    \n      /file remove cacert.pem;\r\
    \n      :log info (\"Updated certificate trust store\");\r\
    \n  } on-error={\r\
    \n      :log error (\"Failed to update certificate trust store\");\r\
    \n  };\r\
    \n}"

smyers119 · Mon Dec 27, 2021 10:15 pm

I am not able to reproduce your problem. It should not be a firewall issue as you don't need to add any extra firewall rules. It would fall uinder estab/related traffic

[admin@router1] /system/ntp/client> print
         enabled: yes
            mode: unicast
         servers: time.nist.gov
      freq-drift: 0 PPM
          status: synchronized
   synced-server: time.nist.gov
  synced-stratum: 1
   system-offset: 0.096 ms

smyers119 · Mon Dec 27, 2021 10:16 pm

I am kind of disappointed I can't set it to pull multiple servers from the pool though

Mon Dec 27, 2021 10:25 pm

Far stretch but I ran into the same problem last weekend messing with my lab setup.

Are you sure dns is working ?
No dns. No resolve. No ntp.

simsrw73 · Mon Dec 27, 2021 10:39 pm

Far stretch but I ran into the same problem last weekend messing with my lab setup.

Are you sure dns is working ?
No dns. No resolve. No ntp.

/system/ntp/client/servers print detail
Flags: X - disabled; D - dynamic
0 address=0.north-america.pool.ntp.org resolved-address=159.203.82.102
min-poll=6 max-poll=10 iburst=yes auth-key=none
1 address=1.north-america.pool.ntp.org resolved-address=74.6.168.73
min-poll=6 max-poll=10 iburst=yes auth-key=none
2 address=2.north-america.pool.ntp.org resolved-address=159.203.158.197
min-poll=6 max-poll=10 iburst=yes auth-key=none
3 address=3.north-america.pool.ntp.org resolved-address=45.15.168.96
min-poll=6 max-poll=10 iburst=yes auth-key=none

On my other switches/aps (I've tried different modes with same result):
/system/ntp/client/ print
enabled: yes
mode: multicast
servers:
freq-drift: 0 PPM
status: waiting

EDIT: my DNS on all my network devices, other than the router, is set to the router's IP: 192.168.99.1. I do not know if that is correct, but that worked for upgrading routeros.

smyers119 · Mon Dec 27, 2021 11:02 pm

what does /system/ntp monitor-peers show?

simsrw73 · Mon Dec 27, 2021 11:11 pm

what does /system/ntp monitor-peers show?

On my router:

/system/ntp monitor-peers
type="multicast-server" address=224.0.1.1

type="ucast-client" address=74.6.168.73 refid="" stratum=16 hpoll=17
ppoll=0 root-delay=0 ms root-disp=0 ms offset=0 ms delay=0 ms
disp=15937.5 ms jitter=0 ms

type="ucast-client" address=159.203.158.197 refid="" stratum=16 hpoll=17
ppoll=0 root-delay=0 ms root-disp=0 ms offset=0 ms delay=0 ms
disp=15937.5 ms jitter=0 ms

type="ucast-client" address=159.203.82.102 refid="" stratum=16 hpoll=17
ppoll=0 root-delay=0 ms root-disp=0 ms offset=0 ms delay=0 ms
disp=15937.5 ms jitter=0 ms

type="ucast-client" address=45.15.168.96 refid="" stratum=16 hpoll=17
ppoll=0 root-delay=0 ms root-disp=0 ms offset=0 ms delay=0 ms
disp=15937.5 ms jitter=0 ms

On a switch

/system/ntp monitor-peers
type="ucast-client" address=192.168.99.1 refid="INIT" stratum=16 hpoll=3
ppoll=3 root-delay=0 ms root-disp=5547.47 ms offset=0 ms delay=0 ms
disp=15937.5 ms jitter=0.003 ms

anav · Mon Dec 27, 2021 11:12 pm

1. Is NTP enabled (lol)
2. Do the addresses you put in there resolve to IP addresses? They should if connectivity is made.
3. If not perhaps the clue is DNS issues.
4. Mode on ntp client is unicast
5 NTP SERVER is enabled and manycast selected.
6. Date is accurate on the router?

For me the biggest difference is what I see on my config output
/system ntp server
set enabled=yes'

Yours

/system ntp server
set broadcast=yes broadcast-addresses=192.168.99.255 enabled=yes

Try changing that to manycast only!

smyers119 · Mon Dec 27, 2021 11:14 pm

let me browse threw your firewall. stratum 16 means it's not synchronizing.

smyers119 · Mon Dec 27, 2021 11:19 pm

remove this rule:

add action=drop chain=input comment="Drop everything else"

anav · Mon Dec 27, 2021 11:20 pm

Why should he drop that rule?

He has all the rules prior to that allowing traffic from the LAN side.
He even doesnt need the specific NTP rules because above that rule he has the one that allows
all VLANs, FULL ACCESS to the router and all BASE......

simsrw73 · Mon Dec 27, 2021 11:33 pm

1. Is NTP enabled (lol)
2. Do the addresses you put in there resolve to IP addresses? They should if connectivity is made.
3. If not perhaps the clue is DNS issues.
4. Mode on ntp client is unicast
5 NTP SERVER is enabled and manycast selected.
6. Date is accurate on the router?

For me the biggest difference is what I see on my config output
/system ntp server
set enabled=yes'

Yours

/system ntp server
set broadcast=yes broadcast-addresses=192.168.99.255 enabled=yes

Try changing that to manycast only!

NTP is enabled. DNS doesn't seem to be an issue. Everything resolves. I went through several variations, trying different modes, but I believe I initially had it set to manycast and have changed it back now with no change. The time is correct on the router, but only because IP/Cloud is enabled and set to sync. None of my switches/AP's are remotely correct.

anav · Mon Dec 27, 2021 11:36 pm

On my IP cloud TIME is NOT I repeat NOT enabled.
Are all you switches and access points (assuming smart devices) get their IP from the management vlan or trusted vlan?

The mode for clients should be unicast and the server should be the gateway of the management vlan or trusted vlan.

smyers119 · Mon Dec 27, 2021 11:42 pm

The only other difference I see is that my estab/related rule also allows untracked, which is the default config. Try adding that to your estab/related rule.

simsrw73 · Mon Dec 27, 2021 11:47 pm

remove this rule:

add action=drop chain=input comment="Drop everything else"

Tried this, but no change.

The only other difference I see is that my estab/related rule also allows untracked, which is the default config. Try adding that to your estab/related rule.

Also, no change here.

smyers119 · Mon Dec 27, 2021 11:48 pm

Why should he drop that rule?

He has all the rules prior to that allowing traffic from the LAN side.
He even doesnt need the specific NTP rules because above that rule he has the one that allows
all VLANs, FULL ACCESS to the router and all BASE......

your trying to troubleshoot a symptom of the problem, Not the problem itself. You can't fix the local ntp server until you fix the communication with the remote ntp servers.

smyers119 · Mon Dec 27, 2021 11:52 pm

remove this rule:

add action=drop chain=input comment="Drop everything else"

Tried this, but no change.

The only other difference I see is that my estab/related rule also allows untracked, which is the default config. Try adding that to your estab/related rule.

Also, no change here.

I am not sure how to help you from here, in the linux world (iptables) I would add the TRACE action to the raw table to follow the path of the packet's. I don't think you can do that with mikrotik.

I am running 7.1.1 on a rb4011 and I am not able to reproduce your problem

simsrw73 · Mon Dec 27, 2021 11:55 pm

On my IP cloud TIME is NOT I repeat NOT enabled.
Are all you switches and access points (assuming smart devices) get their IP from the management vlan or trusted vlan?

The mode for clients should be unicast and the server should be the gateway of the management vlan or trusted vlan.

I've tried with IP/Cloud Time disabled & with IP/Cloud completely disabled. Also, DHCP client Peer NTP/DNS settings are disabled.

All client devices I'm referring to are MT switches/aps and have static IP/route on management vlan.

Clients are now set to unicast and the server to the router/gateway. Still no joy.

anav · Tue Dec 28, 2021 1:13 am

Hmm it would seem you have covered all the bases.........
Looking at my tplink switches, my HEx switch and capac they all work just fine with my settings.......

The capac and switch have a ip Route
dst-address=0.0.0.0/0 gateway=gatewayIP (of trusted vlan)

simsrw73 · Tue Dec 28, 2021 7:34 pm

smyers119 said:

I am not sure how to help you from here, in the linux world (iptables) I would add the TRACE action to the raw table to follow the path of the packet's. I don't think you can do that with mikrotik.

I am running 7.1.1 on a rb4011 and I am not able to reproduce your problem

anav said:

Hmm it would seem you have covered all the bases.........
Looking at my tplink switches, my HEx switch and capac they all work just fine with my settings.......

The capac and switch have a ip Route
dst-address=0.0.0.0/0 gateway=gatewayIP (of trusted vlan)

Thanks. I appreciate you all walking me through it. I will keep playing with it. Maybe dig out the old config on my hEX S, if I kept it backed up somewhere, and see if i was doing something different when I had it working there.

perekhoda · Fri Jan 07, 2022 3:28 pm

Hello. I have a same problem. The support answered me: Enable debug logging for troubleshooting and check your firwall configuration. For help please contact consultants
offcourse, there are not any usefull information
Did you check this problem? Trouble occured on the CRS326 with ROS7.1.1

bfogdb20825 · Mon Jan 10, 2022 11:06 pm

My rb5009 encountered the same problem as you.I believe this is a bug.
IP>router>Rules IP > have the same problem.
Their same performance is that the address in the app is invisible.

deltaplaned · Tue Jan 11, 2022 10:31 pm

I have many Mikrotik devices: RB3011UiAS, RB4011iGS+5HacQ2HnD, RB750UPr2, RB952Ui-5ac2nD, RB941-2nD, RBcAPGi-5acD2nD
All were upgraded to 7.1.1 Stable.
All devices synchronized successful, and only one RB750UPr2 has such error - status is waiting.
Probably this is a bug.

perekhoda · Thu Jan 13, 2022 5:38 am

Hello. I have a same problem. The support answered me: Enable debug logging for troubleshooting and check your firwall configuration. For help please contact consultants
offcourse, there are not any usefull information
Did you check this problem? Trouble occured on the CRS326 with ROS7.1.1

Ooops, there are some problem with our ntp (domain controller). It got bad time from bad ntp server. ISP bead guys. Now ntp status on CRS326 (ROS7.1.1) is synchronized

ysovanna · Sun Feb 13, 2022 1:21 pm

i have the exact same issue with ntp client stuck at 'waiting'.

RB4011, routerOS 7.1.1

kwagga · Tue Feb 22, 2022 10:32 am

RB2011, RouterOS 7.1.3 - Still not working.

screenshot.2022-02-22 (3).png

Any advice?

mfrommel · Tue Feb 22, 2022 5:23 pm

ROS 7.1.3, RB4011
I think, I can reproduce the issue. - EDIT: sorry not reproducible.
If I configure only one NTP server, than it shows "synchronized".

ntp-client.png

As soon as a second NTP server is added, then the status is "waiting".
You may need to disable/enable NTP client to make the configuration changes active.

ntp2.png

kwagga · Tue Feb 22, 2022 6:39 pm

ROS 7.1.3, RB4011
I think, I can reproduce the issue. - EDIT: sorry not reproducible.
If I configure only one NTP server, than it shows "synchronized".
ntp-client.png

As soon as a second NTP server is added, then the status is "waiting".
You may need to disable/enable NTP client to make the configuration changes active.

ntp2.png

Gosh I hoped this worked, but no... Still not working. Also tried backup (compact), reset, restore - still nothing... On a side note... Backup/Restore seemed buggy too...

kwagga · Wed Feb 23, 2022 8:10 pm

So upon further investigation, I grabbed another RB2011 - fully reset it, blank config ROS 7.1.1 - and only configured DHCP Client with NTP pointing to another RB2011 6.49 which is working and is an NTP server...

Look at the below.. It still shows waiting, but was able to get time... this is definitely a bug...

Screenshot 2022-02-23 200639.png

kwagga · Wed Feb 23, 2022 8:21 pm

Well lookey here!

I'm busy manually transferring all my ROS code from 6.49 to 7.11 because backup/restore breaks the router and routing rules... I was busy copying over the NTP section and moments later the NTP client came back as synchronised!

Screenshot 2022-02-23 201903.png

Wed Feb 23, 2022 11:17 pm

sometimes is not your fault

maybe your public ip adress is blacklisted by the ntp servers, who know for how much time, and who know for what reason

try manually a different server

seridohost · Tue Mar 01, 2022 1:36 pm

I have the same problem in RouterOS 7.1.3 versions.

[admin@RB760iGS] > system/ntp/client/print 
     enabled: yes
        mode: unicast
     servers: 200.189.40.8,200.160.0.8
  freq-drift: 0 PPM
      status: waiting
[admin@RB760iGS] >

sv000008 · Mon Mar 14, 2022 11:29 am

Same problem on 7.x. Revert to 6.49.4 or older and everything works fine.

dave3 · Mon Mar 14, 2022 4:54 pm

I know it's not a solution, but for what it's worth, I don't have NTP enabled and the system time still gets set correctly. Even in v6 it had another built-in means of setting the time apart from ntp.

It doesn't seem to maintain accuracy, though. My router (on 7.1.3) was up 11 days, and the time was 9 seconds off. So I enabled the ntp client in winbox, added 4 pool.ntp.org servers, clicked apply, and it synced within a few seconds.

Mon Mar 14, 2022 5:11 pm

DHCP server also provides time (if enabled) and in your DHCP client you can set to get time from DHCP server.
But not as accurate.

pe1chl · Mon Mar 14, 2022 5:14 pm

DHCP server also provides time (if enabled) and in your DHCP client you can set to get time from DHCP server.
But not as accurate.

I think you are confused here. DHCP can provide addresses of NTP servers, and the accuracy depends on the actual NTP servers returned.
It still requires functioning NTP service, which is sometimes blocked by ISP firewall settings.
"not so accurate time" can be provided by HTTP servers. And also by "IP cloud".

Mon Mar 14, 2022 5:23 pm

This setting ?

pe1chl · Mon Mar 14, 2022 5:36 pm

Yes that is what you can set in the client, and in the DHCP-server Networks tab you can specify what addresses it will return for this. You will then find these as "dynamic" NTP server.
It works.

Mon Mar 14, 2022 5:37 pm

Sweet, learned something new today.

achalela · Wed Mar 30, 2022 1:14 am

Hi,

I have a similar problem with RB2011 with routeros 7.1.5. NTP is always in waiting. I check different NTP servers and DNS is ok. I think my problem is because in WAN interface i dont have a public IP, my public IP is in a bridge like a loopback and i have a NAT rule with chain=src-nat and acction is src-nat to the public IP. The routerboard have internet because i can access it by public IP and i can upgrade. I create 2 firewall rules for NTP and only the output rule counters is increassing the input rule never increase. I activate the "log" in the output rule and i see that routerboard is ussing the private address in the WAN interface to reach the NTP server that are in internet, in the log i can see the NAT but i think there is a problem with the main interface that routerboard use to reach NTP servers.

Any comment? How can i fix it?

minfrin · Sun Apr 10, 2022 11:46 pm

Hi all,

Posting my experience as it may help someone.

Had same problem, NTP stuck in waiting. Eventually I discovered I could ping in one direction but not the other, odd.

Turned out two interfaces on different VLANs were enabled for OSPFv3, and there was an asymmetrical route. As soon as OSPF was limited to just one interface, and there was just one outgoing route to the rest of the network, NTP suddenly started working.

I see similar problems reported with SNMP, I suspect NTP cannot handle asymmetrical routing.

Regards,
Graham
--

anup · Fri May 20, 2022 10:58 pm

Definitely bug, here is debug data for time.cloudflare.com, I have tried multiple NTP servers (pool.ntp, google, windows and more)

 may/21 01:47:43 ntp,debug Start resolving name: time.cloudflare.com
 may/21 01:47:43 system,info ntp settings changed by anup
 may/21 01:47:43 ntp,debug Resolved address: time.cloudflare.com -> 162.159.200.1
 may/21 01:47:49 ntp,debug Unreachable and iburst enabled. Send burst
 may/21 01:47:49 ntp,debug tx dst-ip:162.159.200.1
 may/21 01:47:51 ntp,debug tx dst-ip:162.159.200.1
 may/21 01:47:53 ntp,debug tx dst-ip:162.159.200.1
 may/21 01:47:55 ntp,debug tx dst-ip:162.159.200.1
 may/21 01:47:57 ntp,debug tx dst-ip:162.159.200.1
 may/21 01:47:59 ntp,debug tx dst-ip:162.159.200.1
 may/21 01:48:01 ntp,debug tx dst-ip:162.159.200.1
 may/21 01:48:03 ntp,debug tx dst-ip:162.159.200.1
 may/21 01:48:05 ntp,debug tx dst-ip:162.159.200.1

pe1chl · Sat May 21, 2022 10:41 am

Definitely bug

What do you mean, "Definitely bug".
It can well be a config error on your side, or it can be that your ISP blocks NTP. Ask them.

kevinds · Mon May 23, 2022 8:55 pm

I had this a couple days ago with a restored CHR (re-installed CHR and then restored my backup).

What I did to fix it... Disabled the NTP client, then re-enabled it.. It synced in a second or two after that. I had a time server entered.

Does appear to be a bug..

vblack · Fri May 27, 2022 3:29 pm

RB1100AHx2 - same issue

anup · Wed Jun 01, 2022 11:12 pm

Definitely bug
What do you mean, "Definitely bug".
It can well be a config error on your side, or it can be that your ISP blocks NTP. Ask them.

I ask my ISP they didn't. I also tried 5+ ISPs at 3 different locations.

But it starts working again after a few days. I am confused now.

bcbigb · Tue Jun 07, 2022 8:01 am

I have some info that may help the devs or users:

I had this two weeks ago on an RB750Gr3 (HeX) that was configured as a normal router with the two main NIST stratum-1 servers and was upgraded from 6.48.6 LT with the NTP package to 7.2.3 ST. After I upgraded neither of them would sync, whether I disabled them, disabled all of NTP, rebooted, etc. Maybe some special combo of those would have worked, but I didn't have infinite time and couldn't take them down forever, plus obviously something was wrong.

However, when I tried adding a *new* server, in my case "time.windows.com", it synced right away, which gave me the idea that the original servers that went through the upgrade had some specific problem.

Next, I deleted all settings I could find under NTP and disabled the client to clear it out completely. Strangely, I was left with the two original/nonworking NIST servers (the IPs you see in the attached picture) stuck in the servers list, perhaps being kept there by some stuck process/thread or the like. I left everything deleted/off and, IIRC, I came back in maybe 2-4 hours and the "stuck" NTP servers were gone and I was able to re-add them and NTP has worked just fine ever since.

So my only guess is it's something related to either the upgrade or otherwise some unusual start condition for the NTP client/process or just the router generally. It seems that something is getting stuck, then either crashing/freezing/timing-out/looping and holding the time sync of the pre-existing servers open until everything is stopped for long enough that those processes stop/restart and the servers can be re-added fresh. Since RouterOS v6 instantly resolves all DNS-entered NTP servers I don't think it would be related to DNS, given everyone upgrading would implicitly have IPs in the NTP servers field.

pe1chl · Tue Jun 07, 2022 10:06 am

I can confirm that when you delete servers there sometimes are remaining entries, and when you e.g. re-add a server that has been previously deleted, you may even see duplicate entries.
However, I cannot confirm it getting in a state where it does not synchronize. That has not happened here.
At some point in time during v7 testing I exported the config, netinstalled the next version, reset its configuration to completely blank, and imported my config.
Maybe that solves some issues that result from upgrading from v6 to v7.

deltaplaned · Wed Aug 24, 2022 10:33 pm

upgraded to 7.4.1 for RB750UPr2
still not working NTP Client, in waiting status

pe1chl · Wed Aug 24, 2022 11:15 pm

It can be caused by the clock set to 1970 (a bug in the RouterOS v6-v7 migration program)
Try set the clock manually to about the correct time and see if it synchronizes.

jmay · Mon Sep 26, 2022 9:10 pm

Does V7 no longer support using an IP address as an NTP server? I'm experiencing the same issue as OP when I use my own internal server, but if I use something like time.windows.com it syncs just fine. This happened right after updating from 6.47.4 to 7.5. It's not my ISP, I'm the ISP lol. All the other routers that have not been updated are working fine using a single IP address.

pe1chl · Mon Sep 26, 2022 11:03 pm

"right after updating from 6.47.4 to 7.5" you will find that the router clock is not at some sensible value but at 1-1-1970 00:00.
That is what makes it difficult for NTP to rectify the situation. It considers all NTP servers as outliers.
I did not linger around to see if it would ever rectify itself, but just set the clock manually and NTP locked.
That is with literal IP addresses, which in itself isn't a problem.
Hopefully the 1-1-1970 bug is fixed sometime, it is just a bug in the upgrade procedure.

sszbv · Fri Nov 11, 2022 1:00 pm

This is very easy to recreate.
I have a ccr2004-16g-2s+, upgraded to 7.6, then reset config to make sure it is empty.
I enable cloud time sync to set the clock.
Then enable the ntp server with default settings (manycast, vrf=main, authkey=none).

On the network I hand out the IP of this router as the ntp server, via dhcp.

Now I take a CRS312-4C+8XG, upgrade to 7.6 and reset.
I enable ntp client with default settings (unicast vrf=main).
I enable the dhcp client, it sees the ntp server and puts it into the ntp server list.

The result, no time sync. Status is waiting forever.
I see the packets going between the client and server...
But the client just doesn't sync.

Moinitorpeers says:
type="ucast-client" address=10.1.26.1 refid="INIT" stratum=16 hpoll=6 ppoll=6 root-delay=0 ms root-disp=822.28 ms
offset=0 ms delay=0 ms disp=15937.5 ms jitter=0 ms

Same issue on cAP ac devices running 7.6

There are no firewall rules at all here!

My main vpn router is also running 7.6, 6.x devices can sync with it's NTP server. So I suspect it's a bug in the 7.6 client, because the server seems to work.

The log on client side says:

server not sync (kod). Ignoring.

But I'm pretty sure that it is synced. 6.x devices can sync with it.
Forget this part, at the moment the 6.x client also says 'server not synchronised'.
So it might have something to do with the server after all.
In the past, using cloud time sync, would give the server a synchronised status.
This seems to be not the case anymore.

Now it gets even more frustrating, I disabled cloud time sync on the router that is the ntp server. Then enabled the ntp client with nl.pool.ntp.org as the time server. Now the client syncs, status is synchronised.
I disable and enable the ntp server, just to make sure.
But the clients still don't sync!

Anyone found a solution?

pe1chl · Fri Nov 11, 2022 1:57 pm

For me it works OK. The only thing I noticed is that after a v6->v7 upgrade the router time is set to 1-1-1970 00:00 (BUG!) and then the NTP client does not synchronize because of too large time difference.
After setting it manually to nearly correct time, it syncs. But it seems you already covered that by using cloud sync (I always disable that).
Other than that, the NTP client and server in v7 work fine for me.

sszbv · Fri Nov 11, 2022 2:10 pm

For me it works OK. The only thing I noticed is that after a v6->v7 upgrade the router time is set to 1-1-1970 00:00 (BUG!) and then the NTP client does not synchronize because of too large time difference.
After setting it manually to nearly correct time, it syncs. But it seems you already covered that by using cloud sync (I always disable that).
Other than that, the NTP client and server in v7 work fine for me.

Many devices without clockchip boot up with 1-1-1970 00:00 as their time. That's why you need a time server in the first place.
I don't think that is a bug.

sszbv · Fri Nov 11, 2022 2:12 pm

In addition to my previous post, now that the ntp server has sync status, it took a while for the 6.x clients to sync to it.
The 7.6 clients however, still don't sync...
Log says: No survivors for clock sync
So at least it get's something back from the ntp server now.
Maybe it will take some time (lol) before this also starts syncing.

And yes, after a while it started syncing.

So, what did I learn?

1. use the ntp client to sync the time of the router that acts as ntp server, not cloud time sync
2. it takes a long time before the clients consider the ntp server as FIT (see logging of the ntp client to see the actual status)

pe1chl · Fri Nov 11, 2022 11:53 pm

Many devices without clockchip boot up with 1-1-1970 00:00 as their time. That's why you need a time server in the first place.
I don't think that is a bug.

The bug is that the router resets the time to 1-1-1970 when you upgrade from v6 to v7. I think that happens because it uses the last-modified-time of the config database as a starting point for the time. Normally when you powercycle the router it goes back in time only a couple of hours, maybe max a day, not to 1-1-1970.

Of course in general an NTP service has an option (usually enabled by default in e.g. a Linux distribution) to tell the service that it always has to believe the first few NTP replies, even when they indicate a large jump. This is especially to allow for a completely incorrect clock. Apparently RouterOS does not have that.

alexandrecorrea · Tue Nov 22, 2022 1:32 pm

Same problema here.

CRS226 with 7.6

drzub · Thu Dec 01, 2022 12:00 pm

Hi guys. Run into the same problem... No NTP sync from MT router and some machines behind this router (windows machines do not sync, while old iphone syncs OK). Don't know if this will help, but i noticed that successful NTP updates are NTPv3 coming from random port to 123, while unsuccessful - NTPv4 from port 123 to pot 123. If i try to run ntpd on a router that is between Internet and MT (Ubiquity), MT syncs with it NO PROB. My guess that this somehow might be related to NAT. Any ideas?

P.S. Forgot to mention: NTP servers never respond to those unsuccessful requests (at least tcpdump doesn't catch those replies).

pe1chl · Sun Dec 04, 2022 8:28 pm

This problem is caused by your ISP who blocks traffic with port 123 at your side. Ask them to stop doing that.

drzub · Mon Dec 05, 2022 9:38 am

This problem is caused by your ISP who blocks traffic with port 123 at your side. Ask them to stop doing that.

I'm almost sure this is not the case, because a pair of Ubiquiti Nanobeams (AC link between MT and Internet) is syncing time and receiving responses from NTP servers.

pe1chl · Mon Dec 05, 2022 12:22 pm

I am almost sure it IS the case. You pointed out the issue: the MikroTik sends the requests with a source port number 123, other devices use a random source
port number in the 32000+ range. As your ISP blocks traffic from internet to port 123 (after they had some lazy customer 5 years ago who did not secure his
NTP server properly), the reply is lost and the server never syncs.
Either you have to convince them that that firewall rule is no longer necessary (NTP software and configs have usually been fixed), or you need to setup a
specific NAT rule in your router that modifies the source port number of outgoing NTP traffic.

drzub · Wed Dec 07, 2022 11:30 pm

I am almost sure it IS the case.

I must admit, that You are right! So now I am stuck on how to do that. Any help/guidance would be much appreciated.

Update! Ended up routing all outgoing NTP from MT through wireguard interface. NTP client synced. But that's a workaround for those who have VPN. Is there a way to change NTP src port?

mkx · Thu Dec 08, 2022 9:01 am

You mean something like what was discussed in this topic?

drzub · Thu Dec 08, 2022 10:21 am

You mean something like what was discussed in this topic?

Exactly.

This eventually worked for me.

/ip firewall nat add action=src-nat chain=srcnat protocol=udp src-port=123 to-ports=12300

Probably I will add a script to randomize to-ports later.

Weirdest is that I've seen topic you mentioned before and tried that rule but with no success.
Anyway, NTP is syncing and I've learned something new. Thank You guys for helping me to deal with my problem.

mkx · Thu Dec 08, 2022 10:46 am

Probably I will add a script to randomize to-ports later.

If ISP doesn't start to play funny games with you, I think you should just leave it on same port. This way you're slightly more friendly to upstream NTP servers: many keep list of clients, identified by remote IP address and port number, for statistical purposes. Changing port number on your side makes NTP server believe it sees yet another client and allocates another slot in list of clients. Indeed the difference is every so slight, normal src nat for LAN hosts (which might reach out to internet for NTP servers) will most probably randomize src ports due to long time interval between subsequent NTP packet exchange (most of implementations use 1024 seconds after clock settles down which can be way longer than connection tracking UDP timeout).

pe1chl · Thu Dec 08, 2022 11:32 am

You mean something like what was discussed in this topic?
Exactly.

This eventually worked for me.
Code: Select all
/ip firewall nat add action=src-nat chain=srcnat protocol=udp src-port=123 to-ports=12300
Probably I will add a script to randomize to-ports later.

Weirdest is that I've seen topic you mentioned before and tried that rule but with no success.
Anyway, NTP is syncing and I've learned something new. Thank You guys for helping me to deal with my problem.

Maybe the reason it does not always work is that this rule is not correct. I know I posted it in that other topic, but when you look carefully I later corrected it.
Your rule must include some extra matching to make sure that it is only active on outgoing queries. Check what matcher you use in the general NAT rule for internet traffic (something with out-interface or out-interface-list) and add the same thing to your rule.

drzub · Thu Dec 08, 2022 12:19 pm

If ISP doesn't start to play funny games with you, I think you should just leave it on same port.

Sounds reasonable.

Check what matcher you use in the general NAT rule for internet traffic (something with out-interface or out-interface-list) and add the same thing to your rule.

Done that unintentionally. I guess that's the reason why the rule started working

Thu Dec 08, 2022 7:45 pm

Did you try /system/ntp/client/reset-freq-drift ?

smily03 · Mon Dec 26, 2022 3:26 am

For what it's worth, I'm seeing the same/similar things. All devices on my network point to my RB2011, which points to external NTP servers. All are running ROS 7.4.1.
The RB2011 is synchronized, but none of my other Mikrotik stuff (CRS305, CRS226, CAP) is able to sync with the router, all are in "waiting." My Debian boxes can sync with the 2011.

Amm0 · Mon Dec 26, 2022 7:21 pm

All are running ROS 7.4.1.

Maybe try stable? There were bugs I recall in NTP at some point in the V7 chain.

Hamsterman · Wed Mar 01, 2023 12:03 pm

Just found this post - and I got the same issue it seems. I am running OS 7.8 on a RB3011UiAS

krazyglue · Wed Mar 22, 2023 10:28 pm

I have the same issue with any routerOS that I try to sync with windows servers
the NTP debug return this error:

Checking peer (192.168.1.22). Peer is: NOT FIT, because rootDist(10.126187) > 1.000960

pe1chl · Thu Mar 23, 2023 10:09 am

I have the same issue with any routerOS that I try to sync with windows servers

Do not try to do that! Sync the RouterOS routers with internet sources, and sync the windows servers from the routers.

mkx · Thu Mar 23, 2023 11:44 am

Debug message is saying that Windows NTP server is not accurate enough to take it as time source. The most likely reason is that Windows machines traditionally keep time with low precision and are thus unfit for distribution of precise time (i.e. NTP). The less likely reason (in your case) is that NTP server you're trying to use has poor connectivity to stratum 1 servers - either the chosen upstream servers are low in NTP hierarchy (e.g. stratum 4 or lower) or the internet connection is poor (long latency, highly unsymmetrical latency or high latency jitter). If the reason is the later, then router will have hard time keeping precise time even if synchronized directly to internet servers. But, as I already wrote, Windows (as OS) does not keep time very precisely. It's good enough for its own use (e.g. for timestamping in log files), but not precise enough according to NTP protocol requirements.

pe1chl · Thu Mar 23, 2023 11:50 am

That is what I meant to say. Windows time service is getting better for the newest versions, but in general it is not as good as Linux and RouterOS.
So it is better not to use it as a time server for such systems.

krazyglue · Fri Mar 24, 2023 3:44 pm

as they are domain controller I thought it would be alright and they were with ROS 6 if I recall correctly.
anyway, thank you for the hint I will change my plan

kurio · Thu Apr 06, 2023 8:27 pm

On the newest hap ax2 the ntp client does NOT work (waiting).
At the same time hap ac2 is synchronized.
Both are on 7.8 firmware. DNS is resolving, i see only TX lines. I have added manual firewall rule to allow 123 source port to input. No luck.
For me this is a buggy NTP client.
-----update next day-----
After i have moved it to a different network location, it started synchronizing.
Other router which was moved to the LAN location stopped to be synchronized.... Very strange behavior.

eleven · Sun Oct 15, 2023 5:44 am

I am having this issue where my switches can't sync time with NTP Server running on MT router.

My setup last worked, when my router (RB4011) was running on v6.49.10 and all the switches were on 7.x (not exactly sure what version). I finally upgraded my router to 7.x and everything seemed to work, but I didn't check NTP.

I happened to check the log on hAP AC^3 (ROS 7.11.2) and noticed the timestamps were months behind. I checked my other MT switches and they were off as well:
CRS112-8P (ROS 7.11.2)
cAP AX (ROS 7.11.2)

I have several network cameras, windows computers that also get the time from router and they all have the correct time. I turned on ntp debugging and noticed following message on MT clients: "server not sync (kod). Ignoring." I verified that NTP server running on router shows as synced to pool.ntp.org

Another data point is that all 3 MT switches can sync to pool.ntp.org if I open up the firewall.

On server side ntp debug messages appear normal regardless if source is an MT switch or a windows PC.

ZiZiPL · Fri Nov 17, 2023 4:41 pm

Please check the NTP server settings tab and see if the "use local clock" option is selected. It helped me when I selected this option. /MT RB5009 UG+S+ ARM64 V7.12

piku · Thu Jan 18, 2024 5:23 am

I firmly believe that mikrotik has been having problems as an ntp server since 7.2rc. In the service project, I raised a work order more than once, but it seems that it has not been completely resolved so far.
According to my observation, if mikrotik cannot act as ntp client and get an upstream time correctly, it will not work as ntp server. Setting to use local time has no effect.

mkx · Thu Jan 18, 2024 9:32 am

... if mikrotik cannot act as ntp client and get an upstream time correctly, it will not work as ntp server. Setting to use local time has no effect.

This is correct behaviour and is the same in all NTP server implementations. The notable exception is possibility to use localclock as reference (in most Linux implementations) and it's up to NTP server admin to set stratum of localclock low (i.e. number high enough) so that it's only used by its clients if absolutely none of higher-precision references are available.

The behaviour you see is even more important since ROS devices don't have hardware clocks and are initialied to some (more or less poor) approximation to current time at boot time.

piku · Fri Jan 19, 2024 4:01 am

This is correct behaviour and is the same in all NTP server implementations. The notable exception is possibility to use localclock as reference (in most Linux implementations) and it's up to NTP server admin to set stratum of localclock low (i.e. number high enough) so that it's only used by its clients if absolutely none of higher-precision references are available.

The behaviour you see is even more important since ROS devices don't have hardware clocks and are initialied to some (more or less poor) approximation to current time at boot time.

negative. I use GPS as the clock source and configure stratum=1, but the issue still exists.

mkx · Fri Jan 19, 2024 9:19 am

negative. I use GPS as the clock source and configure stratum=1, but the issue still exists.

I'm not sure if ROS NTP client can actually work with GPS receiver as source of (highly) precise time data. NMEA telegrams provide low precision as they are transmitted within one second, the problem is also slow serial line rate which doesn't allow very precise delivery of time stamp. True GPS NTP boxes use NMEA telegrams to get time information and additionally PPS for precise time stamping (PPS is a special impulse, transmitted by GPS receiver, precisely on beginning of a second, every second; usually a special data port is there only for PPS). And even if ROS NTP client would be able to use GPS receiver as reference, until it's locked, NTP server can not provide time to its clients. Setting stratum doesn't help with this issue, stratum only makes your NTP server more or less attractive for clients to sync to it (versus other NTP servers they might be configured with).

You can decide not to believe (I have around 30 years of user experience with NTP protocol), but that's not going to change the way NTP is supposed to work.

pe1chl · Fri Jan 19, 2024 2:11 pm

I agree. Using NMEA to provide "GPS time" is usually much worse than using NTP over internet.
I do have an NTP appliance (LeoNTP) at home and my MikroTik routers perfectly obtain time from it (and work as a server once they are locked).
There is no "issue", it just works OK.

(there is a possible point for improvement: use random source port for server connections instead of 123, but that is related to ISP blocks as mentioned above)

piku · Sat Jan 20, 2024 3:17 am

I'm not sure if ROS NTP client can actually work with GPS receiver as source of (highly) precise time data. NMEA telegrams provide low precision as they are transmitted within one second, the problem is also slow serial line rate which doesn't allow very precise delivery of time stamp. True GPS NTP boxes use NMEA telegrams to get time information and additionally PPS for precise time stamping (PPS is a special impulse, transmitted by GPS receiver, precisely on beginning of a second, every second; usually a special data port is there only for PPS). And even if ROS NTP client would be able to use GPS receiver as reference, until it's locked, NTP server can not provide time to its clients. Setting stratum doesn't help with this issue, stratum only makes your NTP server more or less attractive for clients to sync to it (versus other NTP servers they might be configured with).

You can decide not to believe (I have around 30 years of user experience with NTP protocol), but that's not going to change the way NTP is supposed to work.

It's not about gps as ntp client (in fact it can't). We can adjust mikrotik's local clock according to GPS, regardless of time accuracy.
And use the local clock as the source of NTP server.
Unfortunately, the mikrotik ntp server which uses the local clock as the time source, will stop working after about 1 week except reboot system. here is the issue.

mkx · Sat Jan 20, 2024 11:13 am

As I wrote: NMEA telegrams from GPS receiver are not very precise (+- 0.5 seconds is pretty normal) but NTP is supposed to be precise. And using localclock on MT devices as any kind of reference clock for network is even worse idea.

You'll have to rethink your setup and come up with another solution. If you insist on using local source for time sync of your network, you can use a low-cost device (e.g. RPi) running "normal" linux with NTP server which allows to use local clock as reference clock. You can then try to discipline local clock using NMEA telegrams if you will. Just a word of caution: large jumps in reference time compared to NTP client's own idea of time makes it unhappy (and discard that time source as sync candidate). "Large" in this context means "tens of miliseconds per sync opportunity" (NTP client asks server for time every now and then, by default interval is between 64s and 1024s). And that's less than precission which can be derived from NMEA telegrams only.

Now, if the fact that ROS NTP server stops giving out time after a week is the only problem you see, then open trouble ticket with mikrotik support (support@mikrotik.com , https://mikrotik.com/support ) and also give them supout.rif, taken when NTP server malfunctions.

piku · Wed Jan 24, 2024 9:13 am

If you insist on using local source for time sync of your network, you can use a low-cost device (e.g. RPi) running "normal" linux with NTP server which allows to use local clock as reference clock. You can then try to discipline local clock using NMEA telegrams if you will.

I don't think this is any different from using mikrotik. Maybe linux can receive ppi from a serial port, but the "500ms" is enough for my needs.

Now, if the fact that ROS NTP server stops giving out time after a week is the only problem you see, then open trouble ticket with mikrotik support (support@mikrotik.com , https://mikrotik.com/support ) and also give them supout.rif, taken when NTP server malfunctions.

Yes, they started investigating this issue in May 2022, and there was progress but not much. This is why I came to forum.

pe1chl · Wed Jan 24, 2024 11:47 am

If you insist on using local source for time sync of your network, you can use a low-cost device (e.g. RPi) running "normal" linux with NTP server which allows to use local clock as reference clock. You can then try to discipline local clock using NMEA telegrams if you will.
I don't think this is any different from using mikrotik. Maybe linux can receive ppi from a serial port, but the "500ms" is enough for my needs.

Yes, but not for NTP's needs... so it may experience strange phenomena when you use that as a time source.
(it will not want to select this time source because there is so much jitter)

When you have internet, at least you should add a timeserver on internet to your configuration, and you will most likely find that it selects that as its time source instead of the GPS.

mkx · Wed Jan 24, 2024 3:11 pm

OK. So in /system/ntp/server you have "use-local-clock" set to "yes" and "local-clock-stratum" to some sane number (like 10). After a while, what does /system/ntp/monitor-peers say about "server" with address 127.127.1.0?

piku · Thu Jan 25, 2024 12:56 pm

When you have internet, at least you should add a timeserver on internet to your configuration

This is exactly the problem, I need to synchronize the clocks of various devices in a network environment without internet. 1 second error or jitter is not an issue.

OK. So in /system/ntp/server you have "use-local-clock" set to "yes" and "local-clock-stratum" to some sane number (like 10). After a while, what does /system/ntp/monitor-peers say about "server" with address 127.127.1.0?

I restarted the whole mikrotik 6 days ago and it works great now. I will answer this question within 1 to 3 days

piku · Wed Jan 31, 2024 8:34 am

OK. So in /system/ntp/server you have "use-local-clock" set to "yes" and "local-clock-stratum" to some sane number (like 10). After a while, what does /system/ntp/monitor-peers say about "server" with address 127.127.1.0?

After 12 days 8 hours and 50 minutes of startup, the ntp server failed.
at this time,

[admin@MikroTik] > /system/ntp/monitor-peers
 type="ucast-client" address=127.127.1.0 refid="" stratum=2 hpoll=3 ppoll=0 
   root-delay=0 ms root-disp=0 ms offset=0 ms delay=0 ms disp=0 ms jitter=0 ms

Nucleoprotein · Sun Apr 28, 2024 8:03 pm

Dunno why but this fixes NTP for me:

/ip firewall nat
add action=masquerade chain=srcnat comment="NTP fix" dst-port=123 out-interface-list=WAN protocol=udp to-ports=\
    12300-12390

pe1chl · Sun Apr 28, 2024 9:18 pm

It is because your ISP blocks the NTP port 123 for you. As explained above.

Who is online