I’ve just downloaded Toradex OS Quarterly 6.4.0+build.5 for my Verdin iMX8M Plus and I connect it to the web.
As an example, I can ping google.com successfully.
But I see that the timestamp is wrong, and not updated from the web, even if the NTP service is active.
And since the datetime is quite old, when I call docker compose ... up
and the container is not available locally, the SoM cannot download it because a certificate issue similar to this one
current time 2023-07-27T11:53:36Z is before 2023-10-05T00:00:00Z
That’s strange on my side this seems to be working fine:
torizon@verdin-imx8mp-06849059:~$ date
Mon Nov 13 21:38:50 UTC 2023
torizon@verdin-imx8mp-06849059:~$ timedatectl
Local time: Mon 2023-11-13 21:38:55 UTC
Universal time: Mon 2023-11-13 21:38:55 UTC
RTC time: Mon 2023-11-13 21:38:55
Time zone: Universal (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
This is on 6.4.0 same version as you. Is this behavior reproducible for you? Also can you check the logs of systemd-timesyncd.service. Maybe something went wrong with the time sync service here.
* systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2023-02-22 23:10:52 UTC; 4min 22s ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 684 (systemd-timesyn)
Status: "Idle."
Tasks: 2 (limit: 4073)
Memory: 3.1M
CGroup: /system.slice/systemd-timesyncd.service
`- 684 /usr/lib/systemd/systemd-timesyncd
Feb 22 23:13:00 verdin-imx8mp-06849059 systemd-timesyncd[684]: Timed out waiting for reply from 216.239.35.0:123 (time1.google.com).
Feb 22 23:13:11 verdin-imx8mp-06849059 systemd-timesyncd[684]: Timed out waiting for reply from 216.239.35.4:123 (time2.google.com).
Feb 22 23:13:21 verdin-imx8mp-06849059 systemd-timesyncd[684]: Timed out waiting for reply from 216.239.35.8:123 (time3.google.com).
Feb 22 23:13:31 verdin-imx8mp-06849059 systemd-timesyncd[684]: Timed out waiting for reply from 216.239.35.12:123 (time4.google.com).
Feb 22 23:14:14 verdin-imx8mp-06849059 systemd-timesyncd[684]: Timed out waiting for reply from 162.159.200.123:123 (time.cloudflare.com).
Feb 22 23:14:24 verdin-imx8mp-06849059 systemd-timesyncd[684]: Timed out waiting for reply from 162.159.200.1:123 (time.cloudflare.com).
Feb 22 23:14:34 verdin-imx8mp-06849059 systemd-timesyncd[684]: Timed out waiting for reply from 216.239.35.0:123 (time1.google.com).
Feb 22 23:14:44 verdin-imx8mp-06849059 systemd-timesyncd[684]: Timed out waiting for reply from 216.239.35.4:123 (time2.google.com).
Feb 22 23:14:55 verdin-imx8mp-06849059 systemd-timesyncd[684]: Timed out waiting for reply from 216.239.35.8:123 (time3.google.com).
Feb 22 23:15:05 verdin-imx8mp-06849059 systemd-timesyncd[684]: Timed out waiting for reply from 216.239.35.12:123 (time4.google.com).
Probably the port(s) used by NTP service is(are) blocked by my corporate firewall.
is this the port UDP 123? Or a different port?
Do you think this can be the case?
It should be, that’s the default port for this service and we didn’t change this in Torizon.
Do you think this can be the case?
It’s plausible, corporate network settings have caused some strange issues for other customers as well. It also should be relatively simple for you to confirm/deny whether it’s your firewall or not.
I got the info from my IT dept.
All the NTP packages (UDP port 123) are redirected to a NTP server available in the local network (I have to IP address).
How can I add this to the list of NTP servers to be used by Torizon?
