Hi there, could you try that again running chronyd -q "pool pool.ntp.org iburst" to see if it that changes the result? It looks like chronyd gives up after the first server, so it might be just a thing of forcing it to try multiple sources.
Also, when the chronyd service is running you can also try cronyc reselect to force the NTP daemon to change the source. Some more information is available here (just in case you haven’t seen it)
root@2479276:~# chronyd -q "pool pool.ntp.org iburst"
2000-01-01T01:07:18Z chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK +RTC -PRIVDROP -SCFILTER -SIGND +ASYNCDNS -SECHASH +IPV6 -DEBUG)
2000-01-01T01:07:31Z No suitable source for synchronisation
2000-01-01T01:07:31Z chronyd exiting
root@2479276:~# chronyc reselect
200 OK
root@2479276:~# date
Sat Jan 1 01:08:21 UTC 2000
I’ve looked at the tcpdump output of the chronyd execution that you attached above and I see that the transmit timestamps originating from the device are quite off. Packets are going in and out, so it does not seem a problem with the networking itself. The ntpdate timestamps on the other hard are corresponding to the current system time. Running chrony on my laptop I also see that the timestamps are quite off, but it succeeds, so it could be by design.
Can you please make a new capture? This time use -w to specify an output file - it will be easier to dissect with wireshark.
And also do not limit the capture on udp port 123 as I would like to see all the traffic at the time when you issue the command.
You may use a service like transfer.sh or file.io to grab the capture file from the device more easily. After you grab it with transfer.sh or file.io you can attach it directly here with the upload button, so that the file does not expire for some reason.
Thanks,
Zahari
Hi, requested data is here
https://transfer.sh/SWEoE/transferntp
I used this command
chronyd -6 -4 -q “server pool.ntp.org iburst”
BTW, this time i have RTC clock in this machine, but it still doesnt working
root@0b30aefe7a1f:/app# chronyd -6 -4 -q “server pool.ntp.org iburst”
2020-08-07T14:38:52Z chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
2020-08-07T14:39:04Z No suitable source for synchronisation
2020-08-07T14:39:04Z chronyd exiting
So here is a summary of the capture:
No. Time Source Destination Protocol Length Info
1 0.000000 172.17.0.5 10.114.102.1 DNS 72 Standard query 0x828d A pool.ntp.org
2 0.040232 10.114.102.1 172.17.0.5 DNS 136 Standard query response 0x828d A pool.ntp.org A 94.247.111.10 A 83.163.190.85 A 37.120.179.169 A 89.111.15.218
3 0.244047 172.17.0.5 94.247.111.10 NTP 90 NTP Version 4, client
4 2.253438 172.17.0.5 94.247.111.10 NTP 90 NTP Version 4, client
5 4.284504 172.17.0.5 94.247.111.10 NTP 90 NTP Version 4, client
6 6.321406 172.17.0.5 94.247.111.10 NTP 90 NTP Version 4, client
7 8.351907 172.17.0.5 94.247.111.10 NTP 90 NTP Version 4, client
8 8.462008 94.247.111.10 172.17.0.5 NTP 90 NTP Version 4, server
9 8.462161 172.17.0.5 94.247.111.10 ICMP 118 Destination unreachable (Port unreachable)
10 10.358454 172.17.0.5 94.247.111.10 NTP 90 NTP Version 4, client
11 10.468840 94.247.111.10 172.17.0.5 NTP 90 NTP Version 4, server
12 10.468994 172.17.0.5 94.247.111.10 ICMP 118 Destination unreachable (Port unreachable)
So I see first 4 packets are sent by chrony and they do not have response. The 5th one has a response, but then it is followed by an port unreachable error sent back to the NTP server. That probably means that chrony is not listening on port 123 as it should. Could it be something else listening on that port?
Maybe this was original chrony i forgot to disable it
Scan again here:
https://transfer.sh/Xl0oK/test2
Scan with ntpdate -
https://transfer.sh/bB08o/test2
Nothing is listening on this machine on this port
Looks like ntpdate is going smoothly, and chrony not?
It’s totally strange
Same error as before. Is this running chrony on the host OS? Can you please run it in a container as well and see whether you get the same result?
This is running in container, not on host os
Hi @Razikus – thanks for the additional detail. We definitely don’t expect chrony to refuse to work in this way. Can I ask you:
All the best,
Hugh
Hi, do you have a running device that you can enable support access to it? I tried reproducing locally as well but without success. If you have such a device please paste here the dashboard link to it and enable support access (it is safe as we only can open it).
Thanks,
Zahari
We have a working theory on why chrony is failing, but ntpdate is not. The ntpdate tool uses port 123 as both source and destination port, whereas chrony uses port 123 as destination by default. There is a acquisitionport setting that changes this default behavior.
Is the device you have been testing behind a firewall, or is there anything else special with the networking environment/configuration of the device?
Hello
Sorry for long answer
Dashboard access: https://dashboard.balena-cloud.com/devices/8810dfc913cb91eb6066b6483f472155/summary
I have a running server here with 123 UDP exposed but i dont think that it should affect that much
I think in 99% before i exposed that port it was the same
I don’t have any hardware firewall
Awesome, thanks for sharing access. I will get back shortly to you.
I can confirm that using acquisitionport 123 on your device fixes the issue. Without it on reboot the date is pointing to February. After enabling this setting the OS starts displaying the correct date. I will communicate this with our OS team so that we include it in a next OS release.
Wow, that’s awesome! You are awesome guys!
Is there any workaround for this now? Somehow can i add it persisted before flashing an image?
Unfortunately no. The only way is to go and modify the OS after booting the device. After this if the OS is updated, the change will be lost. So the only way to resolve this properly is to wait for an OS release that includes the fix.
I will need to still use your device for an hour or so, to do some final packet captures and double verify things up. I will let you know once I am finished with using the device.
Doing the packet captures knocked the device offline (not so uncommon with the WiFi driver on the RPi). Can you please power cycle it whenever you have a chance?
I did it
It looks like the device went offline an hour after you brought it back, so I did not have a chance to take the captures.