FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
1,967 views 6 comments
by anonymous
I own both an RUT950 and an RUT240. I need both of these modems to have the correct local time, so I have tried to configure NTP. Both modems are configured to use a local NTP time server, and I can confirm that each modem is able to communicate with the server. For some reason though, the modems do not keep time very well. If I sync their times, after a short period their clocks will be out by several minutes, then later by several hours. I have even seen them be out by months within a short period of time.

For the configuration, I have checked the 'Enable NTP' option with an appropriate update interval. The selected timezone is correct, and I have checked the 'save time to flash' option. There is only the one time server configured (on a local IP).

I have either not configured NTP correctly on these devices, or there is something wrong with the firmware. Is anyone able to provide some assistance or have a similar experience?

1 Answer

+1 vote
by anonymous

Hello hayden_spence,

Could you clarify what you mean by local NTP server? Do you have some other device that acts like it in yours LAN? If so, does both clocks show same wrong time or is it different for each of them? And does your router time deviates by hours or even moths after short period, if you use default time servers like 0.[yours region].pool.ntp.org ?

Regards,
VidasKac.

Best answer
by anonymous
Thanks for responding to my question, VidasKac.

To clarify – I have configured on my local network a server which responds to NTP requests. There are many local devices which poll this server for the time, and all of these devices (except the modems) are correctly in sync with the server's time. The server gets its time from an Internet time provider. The server has the correct local time.

I have never noticed any clocks on my local network devices deviating from the server's time before.

As both of my modems are in bridge mode, the modems cannot directly connect to the Internet to poll a time server. Both modems are configured to point to the local time server, and my firewall facilitates the request (as with all other request to the time server). I can see that the traffic does indeed flow from the modems to the time server without any issues.

At the time of writing this, I have checked both modems and they both have slightly different times to each other (differing by about 55 seconds). The modem with the most correct time is about 50 seconds behind the time server's clock. So right now, they are reasonably close to the correct time, but it is not precise enough for me. And as mentioned, I have seen them out by a significant degree many times before.

The NTP update interval set on both modems is 43200 seconds (12 hours).

Does that give you some more insight into the issue? Please ask for more details if you need them.
by anonymous

Then could you check if your routers send query and receive response from from yours local NTP server? 

With static IP log in to CLI or SSH of your routers, query NTP server: ntpclient -c 1 -h <host IP>
It should print line like: 43852 34918.760   19480.0     89.2  133021.8    183.1         0

And in separate window launch TCP dump: tcpdump -n -i any port 123

You should see something like this:
Query: 07:42:02.208563 IP [router.ip].123 > [server.ip].123: NTPv3, Client, length 48
Reply: 07:42:02.302573 IP [server.ip].123 > [router.ip].123: NTPv3, Server, length 48

Then we should know if it is router clock/configuration problem or something else.

Regards,
VidasKac.

by anonymous

VidasKac —

I have gathered the information using the commands you have provided. Both modems show the same results (just with different IP addresses).

root@secondary:~# ntpclient -c 1 -h 172.16.1.5
43854 19972.455  rejected packet: abs(DISP)>65536

root@secondary:~# tcpdump -n -i any port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
15:32:52.453463 IP 172.16.1.6.39272 > 172.16.1.5.123: NTPv3, Client, length 48
15:32:52.453608 IP 172.16.1.6.39272 > 172.16.1.5.123: NTPv3, Client, length 48
15:32:52.454555 IP 172.16.1.5.123 > 172.16.1.6.39272: NTPv3, Server, length 48
15:32:52.454597 IP 172.16.1.5.123 > 172.16.1.6.39272: NTPv3, Server, length 48

Do the results give any insight into the problem? I'm not familiar with 'ntpclient' and couldn't find much information on what 'rejected packet' actually means.

by anonymous

Hello hayden,

From the part of response rejected packet: abs(DISP)>65536 it is possible that NTP client on routers look at yours local NTP server as "unreliable" because it has too big dispersion (which is an estimate of the total amount of error/variance between that server and the correct time.) 

For this go to WebUI, Services > NTP  and in General settings tab mark Force servers (Force unreliable NTP servers) 

If that won't work and this error wont go away use same ntp client line but with extra oprion [-s]: ntpclient -s -c 1 -h 172.16.1.5 and post what you get.

by anonymous
That's interesting. Thank you for your explanation and recommendation.

It appears that after enabling 'force servers' option, both clocks are in perfect sync with the NTP server.

I'm going to mark this question as resolved, but will do my own investigation to understand what is causing the high dispersion.
by anonymous
Hello hayden,

Glad it helped.

As for high dispersion, since it is counted in milliseconds it is enough that yours NTP server time to "real time" has error margin of 1+ seconds, for some NTP clients to regard it as unreliable. Because for systems that operate industrial machinery or other precise devices one second mismatch can bring real harm. If yours goal is not for them to be in perfect sync, but to have same time with couple of seconds margin of error this is not a big problem. But if you want to avoid situations like this in future, read up on NTP server performance, since this one is server side problem. Good luck.

Best regards,
VidasKac.