I am on QuTS hero h6.0.1.3564.
Even though I get valid ntp packets back from the server (I tried timer.jku.at, pool.ntp·org, time.google·com and more) the packets are not interpreted by ntpdate. [Replacing the last . to avoid the fqdn to be set as a link]
A tcpdump shows:
16:19:52.599055 IP (tos 0x90, ttl 58, id 59855, offset 0, flags [DF], proto UDP (17), length 76)
162.159.200.123.123 > 140.78.96.43.44965: NTPv4, length 48
Server, Leap indicator: (0), Stratum 3 (secondary reference), poll 3 (8s), precision -26
Root Delay: 0.019332, Root dispersion: 0.000167, Reference-ID: 10.224.8.4
Reference Timestamp: 3994841982.467231570 (2026/08/04 16:19:42)
Originator Timestamp: 3994841992.595168680 (2026/08/04 16:19:52)
Receive Timestamp: 3994841998.402424755 (2026/08/04 16:19:58)
Transmit Timestamp: 3994841998.402487656 (2026/08/04 16:19:58)
Originator - Receive Timestamp: +5.807256074
Originator - Transmit Timestamp: +5.807318975
But $ ntpdate -b -d pool.ntp·org says:
4 Aug 16:19:45 ntpdate[5622]: ntpdate 4.2.8p10.1@1.3728-o Wed Jul 22 18:16:06 UTC 2026 (1)
Looking for host pool.ntp·org and service ntp
78.41.116.149 reversed to time1.funkfeuer.at
host found : time1.funkfeuer.at
4 Aug 16:19:45 ntpdate[5622]: Port 0: 1001
4 Aug 16:19:45 ntpdate[5622]: Port 1: 123
transmit(78.41.116.149)
transmit(94.199.174.89)
transmit(152.53.15.127)
transmit(162.159.200.123)
[…]
server 162.159.200.123, port 123
stratum 0, precision 0, leap 00, trust 000
refid [162.159.200.123], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
originate timestamp: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
transmit timestamp: ee1c7388.985cf984 Tue, Aug 4 2026 16:19:52.595
filter delay: 0.00000 0.00000 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000
4 Aug 16:19:54 ntpdate[5622]: no server suitable for synchronization found
Since tcpdump sees and interprets replies it can not be a dns or firewall issue.
Any ideas how to address this issue?