Strange problem with ntp time - it is 6 minutes off!

Random guess: Is your router acting as an NTP source (some do) and is its clock correct?

The LE settings add-on will allow you to configure NTP servers, so perhaps force {0,1,2}.pool.ntp.org and see what happens. They are the default ones we use anyway, unless something like DHCP configures an alternate (like when the router sets itself as one).

Nice. I had a hunch it was that (not the first time I've seen the issue). I'm not sure why the override isn't working, other than I'm probably imagining it worked that way and in reality it doesn't, or that ConnMan used to but changed behaviour, which has happend a few times in a few areas, over time.

IIRR the NTP servers in the Network tab are only used as fallback servers. But any network connection can be configured individually and the NTP setting will override the DHCP.

Quote from mglae

But any network connection can be configured individually and the NTP setting will override the DHCP.

Maybe it worked this way in the past but few months back it didn't.

my analysis: https://gist.github.com/vpeter4/f746c7…b29601ec9c23a5f

Last time I checked this issue when using DHCP and there is NTP server in the DHCP answer this NTP server is used as primary regardless what settings are in LE.

To overcome this issue I disabled NTP queries (or answers) using iptables. Then connman switches to using custom NTP servers from LE settings. Or use static IP.

I disabled the DHCP server in my router for this, and a few other reasons.

My DHCP servers are configured with: "option ntp-servers pool.ntp.org;"

The ISC DHCP server implemented a really neat active/standby feature for high availability, some years ago. It's simple to configure and works great. No need to split address space, like we used to have to do.

Having said that, it sounds like your Internet gateway does a well acceptable job most of the time. Maybe there is no need for you to change anything, now that you have it sorted. I have an audio timer in my home theater stack that is literally flashing "12:00" right now, as I haven't bothered to set the time since the last power outage. You're doing OK. lol!

Quote from Grmpf

Disabling DHCP alltogether is not an option here, i want it to work for guests.

That's where the server comes in. You may notice I did not describe reverting to manual IP configurations. lol!

Sometimes ISP gateways are not very configurable. Others are quite configurable. If you can change the "ntp-servers" option, your DHCP clients will sync to whatever you specify.

It sounds like you're in good shape. Best wishes to you.

Quote from Grmpf

And sure, it "kindof" works now - however, since apparently the router only syncs when it boots, the time *will* drift again in the future, and having to remember to reboot the router when that happens is annoying - i'd prefer some script to issue that ntpd command. Or ideally, libreelec could be fixed to work as expected

I was going to leave this alone in the interest of courtesy but I highly doubt it works as you describe. NTP is a time calibration protocol, not a time sync protocol.

It will figure out the time clock error and periodically add or subtract corrective ticks, as it believes are required. This calibration is stored in a drift file that will survive a reboot. A system that has previously calibrated itself with NTP will have a more accurate clock than a system that has never synced, as long as the NTP daemon is running.

In fact, NTP systems check their clocks against a remote reference less and less frequently over time, as they become increasingly well calibrated.

The factor that will cause the drift calibration to be inaccurate is temperature changes. If the device is in a temperature stable environment, the clock should keep excellent time even if completely disconnected from the Internet.

You probably have a case of your NTP server crashing or stopping, for some reason. I suspect it will be very good until it crashes again.

Quote from Grmpf

My guess would be that those aren't actually "override", but they are always "fallback", and DHCP happens no matter what. That would totally explain what is happening at least.

That would make sense to me, and does indeed explain the current behaviour.

Quote from Grmpf

i'd prefer some script to issue that ntpd command

The problem with that is you cannot disable ConnMan NTP checking so regardless of what date/time you set via a boot script (or cron task) there will be times when ConnMan runs an NTP check against the router and reverts the device to router time, until the next scheduled script NTP check that will correct it again.

The better solution is to use a router that keeps time. The best solution is to author code that modifies ConnMan to optionally ignore NTP responses from routers (there are overrides for some other things, but not NTP). You can always submit the problem to the ConnMan mailing list and hope someone helps with that, but "You can have it fast or cheap, pick one" applies and $free requires someone on the list to feel kind or inspired enough to code something. Usually $free has a long waiting period.

It is more complex than expected.

In __connman_timeserver_get_all() connman is creating the NTP server (NTPS) list from

1. explicit configured service NTPS (configured via "Edit" of the connection/service but not for DHCP)
2. DHCP NTPS
3. Gateway (if enabled, in LE not)
4. Global NTPS (configured in LE Network tab)
5. Fallback NTPS (of main.conf)

The first accessible NTPS is used.

After the fix mentioned in vpeter's gist this seem to be working as designed.

To configure your desired NTPS of 1. use

connmanctl config <service> --timeservers [NTPS1 [NPS2 ...]]

The service name list can be obtained by connmanctl services, the current service configuration is listed with connmanctl services <service>.

The UI of LE-Settings addon does not represent this behavior. The "Edit" option is listing the beginning of the complete NTPS list but store the values to connman's Timeservers.Configuration.

Consequently the save option is forbidden for a DHCP connection.