Time Server Issue in China about dietpi

[MichaIng]

The Great Firewall looks so arbitrary, contradicting and often nonsensical to me 😄. As the China NTP pool obviously is blocked as well, for whatever reason, you (your customer) need to find and use an NTP server which does work. This can be also the LAN router (or the ISP NTP server directly), which often uses the ISP NTP server, which is then probably the only non-blocked NTP server.

EDIT: It might be also just overloaded: https://community.ntppool.org/t/cn-pool-collapse-a-few-hours-every-day/3225

[DrCWO]

Ever tested with Alibaba Cloud NTP server?

[MichaIng]

Sounds like something which should work, but I have no experience with NTP servers in China. When I was there, I just kept using what the OS offered.

[DrCWO]

Did not work :-(

I wonder if the Router offers a NTP server and how this can be used by timesyncd as default if available?

[Joulinar]

Of course you can set the router/gateway as NTP server within DietPi. We offer this option already. At least as long as the router supports NTP server function.

[DrCWO]

Cool 👍
Can you tell me how to do that via the command line please.

[DrCWO]

My goal is to ask the router first and if this did not work ask the debian NTP servers. Hope this will work in Mainland China too as the debian NTP servers and also the Pool only delibver timeout.

[MichaIng]

The first one in dietpi-config > Network Options: Misc > NTP Mirror:

┌──────────────────────────────────────────────────┤ DietPi-Config ├───────────────────────────────────────────────────┐
│ Please select an NTP mirror:                                                                                         │
│                                                                                                                      │
│ "Gateway": Try to detect and use local router for time sync. Recommended, allows fastest sync and reduces load to    │
│ the *.pool.ntp.org servers.                                                                                          │
│                                                                                                                      │
│ "Custom": Manually enter local or external NTP server address(es).                                                   │
│                                                                                                                      │
│ "Default": Leave mirror choice to system. Usually falls back to local gateway (Stretch+ only) or                     │
│ "debian.pool.ntp.org".                                                                                               │
│                                                                                                                      │
│ Use "*.pool.ntp.org" mirrors, if your device is mobile or should act as local NTP server. Further information:       │
│ "http://www.pool.ntp.org/zone/@"                                                                                     │
│                                                                                                                      │
│                      Gateway                    : Use local router as NTP server (Recommended)                       │
│                      Custom                     : Manually enter NTP mirror                                          │
│                      Default                    : Fallback to system defaults                                        │
│                                                 ●─ Continental NTP pools ────────────────────●                       │

or

G_CONFIG_INJECT 'CONFIG_NTP_MIRROR=' 'CONFIG_NTP_MIRROR=gateway' /boot/dietpi.txt
/boot/dietpi/func/dietpi-set_software ntpd-mode

But not every router supports this.

The Debian NTP pool servers are used by default as fallback, but the fallback is only effective when other NTP servers are applied per-interface via systemd-networkd only, not when defining any NTP server via NTP= setting. There is sadly no way I am aware of to have a fallback like "try this first, and if it fails try the other".

[DrCWO]

I replaced the line in the dietpi.txt. Please take a look at my protocols.
Do I interpret it correctly that this means he tries getting it from my Router (Apr 09 16:13:19) got a timeout and next tried to get it from debian (Apr 09 16:14:13)? If yes this might be a solution 👍

root@rooExtend:/home/pi# timedatectl timesync-status
       Server: n/a (0.debian.pool.ntp.org)
Poll interval: 0 (min: 32s; max 34min 8s)
 Packet count: 0
root@rooExtend:/home/pi# timedatectl status
               Local time: Tue 2024-04-09 16:15:05 CEST
           Universal time: Tue 2024-04-09 14:15:05 UTC
                 RTC time: n/a
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
root@rooExtend:/home/pi# timedatectl show-timesync --all
LinkNTPServers=
SystemNTPServers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
FallbackNTPServers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
ServerName=0.debian.pool.ntp.org
ServerAddress=213.209.109.45
RootDistanceMaxUSec=5s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=34min 8s
PollIntervalUSec=1min 4s
NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=2, Precision=-24, RootDelay=335us, RootDispersion=9.124ms, Reference=A810960, OriginateTimestamp=Tue 2024-04-09 16:14:49 CEST, ReceiveTimestamp=Tue 2024-04-09 16:14:49 CEST, TransmitTimestamp=Tue 2024-04-09 16:14:49 CEST, DestinationTimestamp=Tue 2024-04-09 16:14:49 CEST, Ignored=no PacketCount=1, Jitter=0 }
Frequency=0
root@rooExtend:/home/pi# journalctl -eu systemd-timesyncd
-- Journal begins at Tue 2024-04-09 16:13:18 CEST, ends at Tue 2024-04-09 16:15:35 CEST. --
Apr 09 16:13:19 rooExtend systemd[1]: Starting Network Time Synchronization...
Apr 09 16:13:19 rooExtend systemd[1]: Started Network Time Synchronization.
Apr 09 16:14:13 rooExtend systemd-timesyncd[286]: Initial synchronization to time server 80.60.67.39:123 (2.debian.pool.ntp.org).
Apr 09 16:14:13 rooExtend systemd[1]: Stopping Network Time Synchronization...
Apr 09 16:14:13 rooExtend systemd[1]: systemd-timesyncd.service: Succeeded.
Apr 09 16:14:13 rooExtend systemd[1]: Stopped Network Time Synchronization.
Apr 09 16:14:49 rooExtend systemd[1]: Starting Network Time Synchronization...
Apr 09 16:14:49 rooExtend systemd[1]: Started Network Time Synchronization.
Apr 09 16:14:49 rooExtend systemd-timesyncd[1840]: Initial synchronization to time server 213.209.109.45:123 (0.debian.pool.ntp.org).
root@rooExtend:/home/pi# cat /boot/dietpi.txt | grep CONFIG_NTP_MIRROR
#CONFIG_NTP_MIRROR=debian.pool.ntp.org
CONFIG_NTP_MIRROR=gateway

[DrCWO]

I wonder that I can't see any attempt getting the time from the router...

[MichaIng]

Note that editing dietpi.txt only has no effect. You need to run the 2nd command from my post above which applies the actual current gateway/default route as NTP server to /etc/systemd/timesyncd.conf. The dietpi.txt setting in this case acts for like a flag, or a choice for the backend script to use.

Actually, choosing "Default", respectively leaving the NTP settings completely untouched (removing the /etc/systemd/timesyncd.conf file) should be closest to what you want, if DHCP is used:

• systemd-timesyncd applies NTP servers provided via DHCP automatically via /etc/dhcp/dhclient-exit-hooks.d/timesyncd. If the router provides NTP functionality, I would expect it to promote this via DHCP as well.
• If no NTP server is provided via DHCP, systemd-timesyncd uses the Debian NTP pool as fallback by default. With FallbackNTPServers= this can be changed, but we currently have no dietpi-config way to set this, hence this would require a custom /etc/systemd/timesyncd.conf.

If no DHCP is used, I see no way to have a fallback functionality, but it must be tested manually.

[DrCWO]

Great, thank you 👍
OK, set it to "Default" now and see this:
The config file had disappeared but still no hint that it tried to get data from the Router first.
Sure, my Router delivers nothing so I would expect to see a timeout somewhere...

root@rooExtend:/home/pi# journalctl -eu systemd-timesyncd
-- Journal begins at Tue 2024-04-09 16:35:51 CEST, ends at Tue 2024-04-09 16:36:55 CEST. --
Apr 09 16:35:52 rooExtend systemd[1]: Starting Network Time Synchronization...
Apr 09 16:35:52 rooExtend systemd[1]: Started Network Time Synchronization.
Apr 09 16:36:48 rooExtend systemd-timesyncd[272]: Initial synchronization to time server 5.39.184.5:123 (2.debian.pool.ntp.org).
Apr 09 16:36:48 rooExtend systemd[1]: Stopping Network Time Synchronization...
Apr 09 16:36:48 rooExtend systemd[1]: systemd-timesyncd.service: Succeeded.
Apr 09 16:36:48 rooExtend systemd[1]: Stopped Network Time Synchronization.
root@rooExtend:/home/pi# cat /etc/systemd/timesyncd.conf
cat: /etc/systemd/timesyncd.conf: No such file or directory
root@rooExtend:/home/pi# timedatectl show-timesync --all
LinkNTPServers=
SystemNTPServers=
FallbackNTPServers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
ServerName=0.debian.pool.ntp.org
ServerAddress=(null)
RootDistanceMaxUSec=5s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=34min 8s
PollIntervalUSec=0
Frequency=0
root@rooExtend:/home/pi#

[MichaIng]

Then the router does not provide any NTP server via DHCP. It would be listed in:

cat /var/lib/dhcp/dhclient.*.leases

[DrCWO]

/var/lib/dhcp/dhclient.*.leases does not exist on my system.

But I use DHCP to get the IP for my Raspberry...

[MichaIng]

The * is a wildcard for the network interface. So it would be e.g. /var/lib/dhcp/dhclient.eth0.leases. If no such exists, your system does at least not use isc-dhcp-client/dhclient started from ifupdown as DHCP client, or it failed to receive any DHCP lease (which would usually mean no network).

[Joulinar]

You could explicitly set router IP as NTP target. This would work around any DHCP features

[MichaIng]

Indeed, but then the fallback feature does not work anymore, i.e. it is not a good default when providing images for customers 🤔.

[DrCWO]

ls -al /var/lib/dhcp/
total 8
drwxr-xr-x  2 root root 4096 Nov 17  2022 .
drwxr-xr-x 29 root root 4096 Feb 11  2023 ..

This is empty. But the installation gets IP by DHCP. Maybe I use a different client? Can't remember.
Setting the Router IP is not a good choice as it changes from Client to client.

But as far as I understood after deleting /etc/systemd/timesyncd.conf the NTP from the Router is checked first and then debian will be asked. Right? This is what I think is a good choice.

My Rouder did not provide NTP so I expected to see a timeout before debian got asked. If I enter a fixed IP of the Router I get a timeout and no debian request.

[MichaIng]

But as far as I understood after deleting /etc/systemd/timesyncd.conf the NTP from the Router is checked first and then debian will be asked. Right? This is what I think is a good choice.

Without the file, the NTP provided by the router via DHCP is used, if present in the lease, else the Debian NTP pool is used. There is no fallback after timeout, it is always only 1 single server or pool tried. But this only works if either systemd-networkd or isc-dhcp-client/dhclient are used as DHCP client. systemd-timesyncd seems to have no hook for other DHCP clients like dhcpcd: https://packages.debian.org/bookworm/amd64/systemd-timesyncd/filelist

E.g. htop should show the DHCP client process, or

ps aux | grep '[d]hcp'

... actually, not a fallback, but another way would be to add a pool + the router IP to the same NTP= line. It is usually meant to be used for multiple instances of an NTP pool, but in the end, AFAIK, systemd-timesyncd just sends an NTP request to all listed servers and takes the first response. This does not rely on DHCP or any specific DHCP client. From the perspective of NTP pool operators, it isn't ideal, as their pool is (ab)used even if the router does provide NTP functionality. But for edge cases where the router does provide NTP functionality, but for whatever reason does not send it via DHCP, or no supported DHCP client is used, it is handy. Also, probably it is not as bad when defining the router IP in the front of the NTP pool hostnames. On the man page it says that systemd-timesyncd "contact all configured system or per-interface servers in turn, until one responds". Probably it gives each a little time before contacting the next, and the router should answer pretty fast, if it has NTP functionality.

[DrCWO]

Ok, dhcpcd is running 👎
So the question is how to get the IP number of the Router plus the name of the Pool in the file?
This must be ready before systemd-timesyncd runs for the first time???

[MichaIng]

This must be ready before systemd-timesyncd runs for the first time???

You could do this via dietpi.txt, but you must know the router IP first:

CONFIG_NTP_MIRROR=192.168.1.1 debian.pool.ntp.org

If this turns out to work nicely, and does not call all 4 pool servers on every sync, despite the router answering first/fast, I'll add some native setting for this, so that you can use:

CONFIG_NTP_MIRROR=gateway debian.pool.ntp.org

Uff, I see this section's comments are pretty outdated, talking about /etc/ntp.conf, and default is not the default 😄.
EDIT: Better: 0283693