On Wed, 23 Feb 2022 at 14:10, MJ Ray <mjr@phonecoop.coop> wrote:

...

It is configured to update every 600s [...]

How is it configured to do that?

This is part of my problem in that I'm not sure I know the answer. I mean the web interface of the unit says it is set to 600. If I look in /etc/config/ntpclient it's set to 600. But I don't know how that gets passed to ntpclient.

Are you sure ntpclient is still running and hasn't been killed off by process limits, oom-killer or something else?

There doesn't seem to be any process running called ntpclient but again I don't really know what to expect to see. I can't see anything in the busybox logs to indicate that the client is dying. I think the lack of any running ntpclient process is a clue though... -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0344 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER

On Wed, 2 Mar 2022 at 19:25, MJ Ray <mjr@phonecoop.coop> wrote:

Often things in /etc/config get looked up as defaults, or sometimes passed there by cron jobs or init.d scripts (or I suppose systemd units now).

At least on this box it's init.d. Looking at the changes in the test firmware they seem to relate to the network startup, in that /etc/hotplug.d/iface/20-ntpclient (present previously, which reloaded ntpclient on interface up) was supplemented with a similar /etc/hotplug.d/net/20-ntpclient (restarted, rather than reloaded, ntpclient). According to the file comments the latter "net" action fires on every network event so presumably that fires on getting a WAN ip via 3G in a way that the "iface-up" action didn't. It's interesting that the clock was previously correctly getting set once the connection came up (but not thereafter); I can only assume that had nothing to do with npclient and was maybe something the PPP session did directly based on a timestamp from the mobile network? -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0344 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER

On Wed, 23 Feb 2022 at 19:02, Adam Bower <adam@thebowery.co.uk> wrote:

What device is it and which version of openwrt? By default openwrt devices run ntpd to keep the clock synced, I've never had to change the default configuration as it all "just works".

It's a Teltonika router (they have a wide range of openwrt kit and their own LUCI-based GUI), bought from Solwise. When I posted here I was waiting on a response from Teltonika support via Solwise - there'd been a bit of to-and-fro and I was becoming convinced that the problem was me (ie something I didn't understand, eg that a default config would accept a drift greater than seemed reasonable to me and I just hadn't waited long enough for it to reach the threshold for correction). Then two things happened almost simultaneously. MJR's comment about checking ntpclient was running (there was no ntpclient process) and Teltonika sending me a new firmware version to try, which does now have an ntpclient process running and which does now maintain the clock to within around 200ms (I'm sure I can tweak that if I care, but I don't). I don't know *why* ntpclient wasn't running on the old firmware but from comments that came with the new firmware I think it might be about connection stability so a guess would be that it was failing to start properly if the network wasn't up quickly, and this is a 4G unit so that can take some time. But that's speculation. Anyhow, it looks like this is now working - thanks all for your input. -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0344 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER