Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Time Server Issue in China #7010

Open
1 task done
DrCWO opened this issue Apr 9, 2024 · 21 comments
Open
1 task done

Time Server Issue in China #7010

DrCWO opened this issue Apr 9, 2024 · 21 comments

Comments

@DrCWO
Copy link

DrCWO commented Apr 9, 2024

Creating a bug report/issue

  • I have searched the existing open and closed issues

Required Information

  • DietPi version | cat /boot/dietpi/.version
    -G_DIETPI_VERSION_CORE=8
    G_DIETPI_VERSION_SUB=10
    G_DIETPI_VERSION_RC=2
    G_GITBRANCH='master'
    G_GITOWNER='MichaIng'

  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
    bullseye 0

  • Kernel version | uname -a
    Linux rooExtend 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022 aarch64 GNU/Linux

  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
    RPi 4 Model B (aarch64)

  • Power supply used | (EG: 5V 1A RAVpower)
    5V 1A

  • SD card used | (EG: SanDisk ultra)
    Sandisk Ultra

Additional Information (if applicable)

  • Software title | (EG: Nextcloud)
  • Was the software title installed freshly or updated/migrated?
    Fresh
  • Can this issue be replicated on a fresh installation of DietPi?
    Yes
  • Bug report ID | echo $G_HW_UUID

Steps to reproduce

One of my customers live in China and the time in his system was wrong as the debian time servers can not be accessed.
I added Chinese time servers in /etc/systemd/timesyncd.conf.
In the attached dialog you can see that this did not help.

image

Any idea would be appreciated :-)

Expected behaviour

  • ...

Actual behaviour

  • ...

Extra details

  • ...
@MichaIng
Copy link
Owner

MichaIng commented Apr 9, 2024

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
Copy link
Author

DrCWO commented Apr 9, 2024

Ever tested with Alibaba Cloud NTP server?

@MichaIng
Copy link
Owner

MichaIng commented Apr 9, 2024

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
Copy link
Author

DrCWO commented Apr 9, 2024

Did not work :-(
image

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

@Joulinar
Copy link
Collaborator

Joulinar commented Apr 9, 2024

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
Copy link
Author

DrCWO commented Apr 9, 2024

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

@DrCWO
Copy link
Author

DrCWO commented Apr 9, 2024

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
Copy link
Owner

MichaIng commented Apr 9, 2024

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
Copy link
Author

DrCWO commented Apr 9, 2024

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
Copy link
Author

DrCWO commented Apr 9, 2024

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

@MichaIng
Copy link
Owner

MichaIng commented Apr 9, 2024

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
Copy link
Author

DrCWO commented Apr 9, 2024

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
Copy link
Owner

MichaIng commented Apr 9, 2024

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

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

@DrCWO
Copy link
Author

DrCWO commented Apr 9, 2024

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

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

@MichaIng
Copy link
Owner

MichaIng commented Apr 9, 2024

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
Copy link
Collaborator

Joulinar commented Apr 9, 2024

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

@MichaIng
Copy link
Owner

MichaIng commented Apr 9, 2024

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

@DrCWO
Copy link
Author

DrCWO commented Apr 9, 2024

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
Copy link
Owner

MichaIng commented Apr 9, 2024

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
Copy link
Author

DrCWO commented Apr 9, 2024

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
Copy link
Owner

MichaIng commented Apr 9, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants