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

    Hy!

    I am running libreelec on a raspi v3 with no RTC. I have set up the timezone in the regional settings, and libreelec DOES get the ("a") time via NTP quite obviously (else it would be totally off). Basically everything works fine - except the time it uses is always about 6 minutes into the future! I have no explanation for this (it cant be a wrong timezone, for example). Even more puzzling is, that i can set the correct time manually just fine, like

    LibreELEC (official): 11.0.6 (RPi2.arm) 
    LibreELEC:~ # date
    Mon Jul 22 00:27:26 CEST 2024 
    LibreELEC:~ # ntpd -p pool.ntp.org
    LibreELEC:~ # date
    Mon Jul 22 00:21:13 CEST 2024

    I have already googled a bit and tried a dozen things suggested here and elsewhere - but no change. This seems a very weird issue. Some hints as to how to try to fix this would be appreciated. Thanks in advance! (An acceptable workaround would be adding the ntpd call to a script that runs once after startup, i guess - but thats seems hacky)

    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).

    You are my hero!

    Now that you said it, i checked my routers web interface - and indeed the time is off by the same amount. Restarted the router - and all is fine. Unfortunately though, i cant set up anything there (neither use another NTP server, or even disable it, or make it poll the time in regular intervals... nada). That basically means to get reliable time, i must use something else than the router and ignore it.

    I already used explicit servers in the libreelec config - but that doesn't change anything. So is there another way to make it ignore DHCP? seems strange that it would use the DHCP provided server even when you provide one in the config.

    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.

    So the question is: IS there a way to make libreelec (or kodi?) execute a simple script (containing the ntpd command above) after boot? ie _after_ connman has done whatever it wants to do? :)

    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.

    Quote

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

    Thats what you'd think - but it apparently doesn't work like this. I filled in all 3 NTP servers with one of the ntp.org pool - it would still grab the (wrong) time from my router (via DHCP).

    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.

    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!

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

    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 :)

    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.

    Edited once, last by TomB19: Merged a post created by TomB19 into this post. (July 25, 2024 at 2:54 AM).

    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

    Code
    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.