TiOC PRO NTP "Update failed." on most recent firmware

[dnmr]

below is the message i already sent to dahua support for my region, wonder if anyone here has any idea since i'm not getting a reply from the official boys:


i have two DH-IPC-HDW3449H-AS-PV-PRO cameras that throw an "Update failed" error when trying to sync time with a chrony server (cturra/ntp) running in a container on the same computer as my frigate NVR.
There's also an IPC-HDW5442TM-ASE-0280B-S3 on the same network running 260427 firmware with the same NTP settings that syncs just fine.

All cams are on a secondary NIC of the frigate box with static IPs and no way outside. NTP server is confed as an IP as well, so no NAT, DNS or any other network related complications involved. No router there, just an unmanaged Ubiquiti PoE switch.
tcpdump shows that the NTP server communicates properly - the traces are identical for the 5442 that syncs fine and the 3449 that does not (pasted at the end of this message)


Device Model
DH-IPC-HDW3449H-AS-PV-PRO

System Version
V3.140.0000000.38.R, Build Date: 2026-09-11


I also have two of HFW1439TL1 that are not connected right now, and I think they also used the NTP setup just fine when i was testing them. Not sure if that matters since a 5442 that's running right now works and is probably a lot closer to TiOC tech wise.



Here are the dumps from 5442 and 3449 respectively

listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
20:38:23.709275 enp4s0 In IP 10.10.10.194.36095 > 10.10.10.1.123: NTPv4, Client, length 48
20:38:23.709322 br-64e46f527ce3 Out IP 10.10.10.194.36095 > 172.19.0.2.123: NTPv4, Client, length 48
20:38:23.709329 veth008b654 Out IP 10.10.10.194.36095 > 172.19.0.2.123: NTPv4, Client, length 48
20:38:23.709444 veth008b654 P IP 172.19.0.2.123 > 10.10.10.194.36095: NTPv4, Server, length 48
20:38:23.709444 br-64e46f527ce3 In IP 172.19.0.2.123 > 10.10.10.194.36095: NTPv4, Server, length 48
20:38:23.709470 enp4s0 Out IP 10.10.10.1.123 > 10.10.10.194.36095: NTPv4, Server, length 48
20:38:23.710882 enp4s0 In IP 10.10.10.194.36335 > 10.10.10.1.123: NTPv4, Client, length 48
20:38:23.710914 br-64e46f527ce3 Out IP 10.10.10.194.36335 > 172.19.0.2.123: NTPv4, Client, length 48
20:38:23.710919 veth008b654 Out IP 10.10.10.194.36335 > 172.19.0.2.123: NTPv4, Client, length 48
20:38:23.711005 veth008b654 P IP 172.19.0.2.123 > 10.10.10.194.36335: NTPv4, Server, length 48
20:38:23.711005 br-64e46f527ce3 In IP 172.19.0.2.123 > 10.10.10.194.36335: NTPv4, Server, length 48
20:38:23.711019 enp4s0 Out IP 10.10.10.1.123 > 10.10.10.194.36335: NTPv4, Server, length 48
20:38:23.712136 enp4s0 In IP 10.10.10.194.46219 > 10.10.10.1.123: NTPv4, Client, length 48
20:38:23.712171 br-64e46f527ce3 Out IP 10.10.10.194.46219 > 172.19.0.2.123: NTPv4, Client, length 48
20:38:23.712176 veth008b654 Out IP 10.10.10.194.46219 > 172.19.0.2.123: NTPv4, Client, length 48
20:38:23.712229 veth008b654 P IP 172.19.0.2.123 > 10.10.10.194.46219: NTPv4, Server, length 48
20:38:23.712229 br-64e46f527ce3 In IP 172.19.0.2.123 > 10.10.10.194.46219: NTPv4, Server, length 48
20:38:23.712244 enp4s0 Out IP 10.10.10.1.123 > 10.10.10.194.46219: NTPv4, Server, length 48

listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
20:38:56.632992 enp4s0 In IP 10.10.10.23.59208 > 10.10.10.1.123: NTPv4, Client, length 48
20:38:56.633032 br-64e46f527ce3 Out IP 10.10.10.23.59208 > 172.19.0.2.123: NTPv4, Client, length 48
20:38:56.633038 veth008b654 Out IP 10.10.10.23.59208 > 172.19.0.2.123: NTPv4, Client, length 48
20:38:56.633140 veth008b654 P IP 172.19.0.2.123 > 10.10.10.23.59208: NTPv4, Server, length 48
20:38:56.633140 br-64e46f527ce3 In IP 172.19.0.2.123 > 10.10.10.23.59208: NTPv4, Server, length 48
20:38:56.633164 enp4s0 Out IP 10.10.10.1.123 > 10.10.10.23.59208: NTPv4, Server, length 48
20:38:56.633721 enp4s0 In IP 10.10.10.23.46754 > 10.10.10.1.123: NTPv4, Client, length 48
20:38:56.633734 br-64e46f527ce3 Out IP 10.10.10.23.46754 > 172.19.0.2.123: NTPv4, Client, length 48
20:38:56.633737 veth008b654 Out IP 10.10.10.23.46754 > 172.19.0.2.123: NTPv4, Client, length 48
20:38:56.633780 veth008b654 P IP 172.19.0.2.123 > 10.10.10.23.46754: NTPv4, Server, length 48
20:38:56.633780 br-64e46f527ce3 In IP 172.19.0.2.123 > 10.10.10.23.46754: NTPv4, Server, length 48
20:38:56.633794 enp4s0 Out IP 10.10.10.1.123 > 10.10.10.23.46754: NTPv4, Server, length 48
20:38:56.634276 enp4s0 In IP 10.10.10.23.55269 > 10.10.10.1.123: NTPv4, Client, length 48
20:38:56.634289 br-64e46f527ce3 Out IP 10.10.10.23.55269 > 172.19.0.2.123: NTPv4, Client, length 48
20:38:56.634291 veth008b654 Out IP 10.10.10.23.55269 > 172.19.0.2.123: NTPv4, Client, length 48
20:38:56.634337 veth008b654 P IP 172.19.0.2.123 > 10.10.10.23.55269: NTPv4, Server, length 48
20:38:56.634337 br-64e46f527ce3 In IP 172.19.0.2.123 > 10.10.10.23.55269: NTPv4, Server, length 48
20:38:56.634352 enp4s0 Out IP 10.10.10.1.123 > 10.10.10.23.55269: NTPv4, Server, length 48

 

[dnmr]

never mind, 5442 only claims to update the time, it pops up the green check mark but time stays wrong. Tested by changing the date on this computer, syncing to camera and then trying to sync to the NTP server

 

[jeremyx]

One thing about that test: a container shares the host's kernel clock, so when you changed the date on the Frigate box, chrony in the container started serving that wrong date too. The 5442 may have synced fine, just to the wrong time. It's a cleaner test to set a wrong time on the camera itself and then hit sync.

For the 3449 "Update failed", I'd check whether chrony is actually telling clients it's synchronized. If it has no reachable upstream server (or hasn't locked on yet), it still answers, but it marks the reply as unsynchronized (leap indicator 3, stratum 16). A strict client will reject that, and it would look exactly like your trace, since plain tcpdump doesn't show those fields.

1. Run "chronyc tracking" inside the container and check that Leap status says Normal and the stratum isn't 0 or 16. "chronyc sources" shows whether it has an upstream selected (marked with *).
2. Run tcpdump with -v on port 123 and look at the Leap indicator and Stratum in the server replies.
3. If the box doesn't have reliable internet for chrony to sync upstream, add "local stratum 10" to the chrony config so it serves its own clock as synchronized when nothing upstream is reachable.

If chrony already shows Normal and a sane stratum, it's more likely the new firmware being picky, and the -v output would help narrow that down.

 

[dnmr]

That was a really quick reply jeremyx, thanks a ton for the effort!

The clock change test I did on a computer which is not the frigate box, should have clarified.

I seem to have fucked up some settings in the container or else, just went through a bunch of things again and it seemed to have straightened it out. Now all cameras pick up the NTP server's clock when the time settings in all cameras are changed back from wrong manual value to NTP. Sad part is I'm not sure what sort of a mistake it was and if quote marks in docker compose file's port settings could have made a difference in this case. I was changing it back and forth between only listening to the secondary nic, on both, or all interface to test if the server could be polled from elsewhere like this windows machine or a raspberry pi. Or maybe it was something else since i also restarted the container a couple of times.

It's just wild to me that the two camera models were behaving differently, that threw me off big time. Test results below if you care, but the thing seems to work now so these are probably useless at this point:


1. was fine before doing anything i think:

Reference ID : A29FC87B (time.cloudflare.com)
Stratum : 4
Ref time (UTC) : Thu Oct 22 17:39:12 2026
System time : 0.000093277 seconds slow of NTP time
Last offset : +0.000009091 seconds
RMS offset : 0.000989320 seconds
Frequency : 0.053 ppm slow
Residual freq : +0.004 ppm
Skew : 0.312 ppm
Root delay : 0.010918776 seconds
Root dispersion : 0.000228980 seconds
Update interval : 64.3 seconds
Leap status : Normal

2. looks ok as well now i think. First is a w32tm /stripchart call from windows, then 5442 and a 3449

21:15:27.091084 IP (tos 0x0, ttl 128, id 1706, offset 0, flags [none], proto UDP (17), length 76)
10.10.10.101.49793 > 10.10.10.1.ntp: NTPv1, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 4001681726.604128099 (2026-10-22T18:15:26Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 4001681726.604128099 (2026-10-22T18:15:26Z)
21:15:27.091361 IP (tos 0x0, ttl 63, id 61827, offset 0, flags [DF], proto UDP (17), length 76)
10.10.10.1.ntp > 10.10.10.101.49793: NTPv1, Server, length 48
Leap indicator: (0), Stratum 4 (secondary reference), poll 0 (1s), precision -26
Root Delay: 0.010879, Root dispersion: 0.000183, Reference-ID: 0xa29fc87b
Reference Timestamp: 4001681720.901341465 (2026-10-22T18:15:20Z)
Originator Timestamp: 4001681726.604128099 (2026-10-22T18:15:26Z)
Receive Timestamp: 4001681727.091302406 (2026-10-22T18:15:27Z)
Transmit Timestamp: 4001681727.091433238 (2026-10-22T18:15:27Z)
Originator - Receive Timestamp: +0.487174306
Originator - Transmit Timestamp: +0.487305138

21:15:45.655505 IP (tos 0x0, ttl 64, id 1943, offset 0, flags [DF], proto UDP (17), length 76)
10.10.10.194.52818 > 10.10.10.1.ntp: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 4 (16s), precision -6
Root Delay: 1.000000, Root dispersion: 1.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 4001681745.656189000 (2026-10-22T18:15:45Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 4001681745.656189000 (2026-10-22T18:15:45Z)
21:15:45.655676 IP (tos 0x0, ttl 63, id 46499, offset 0, flags [DF], proto UDP (17), length 76)
10.10.10.1.ntp > 10.10.10.194.52818: NTPv4, Server, length 48
Leap indicator: (0), Stratum 4 (secondary reference), poll 4 (16s), precision -26
Root Delay: 0.010879, Root dispersion: 0.000198, Reference-ID: 0xa29fc87b
Reference Timestamp: 4001681720.901341465 (2026-10-22T18:15:20Z)
Originator Timestamp: 4001681745.656189000 (2026-10-22T18:15:45Z)
Receive Timestamp: 4001681745.655674515 (2026-10-22T18:15:45Z)
Transmit Timestamp: 4001681745.655760977 (2026-10-22T18:15:45Z)
Originator - Receive Timestamp: -0.000514484
Originator - Transmit Timestamp: -0.000428022

21:15:49.793634 IP (tos 0x0, ttl 64, id 25257, offset 0, flags [DF], proto UDP (17), length 76)
10.10.10.23.36047 > 10.10.10.1.ntp: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 4 (16s), precision -6
Root Delay: 1.000000, Root dispersion: 1.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 4001681749.786431000 (2026-10-22T18:15:49Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 4001681749.786431000 (2026-10-22T18:15:49Z)
21:15:49.793797 IP (tos 0x0, ttl 63, id 14359, offset 0, flags [DF], proto UDP (17), length 76)
10.10.10.1.ntp > 10.10.10.23.36047: NTPv4, Server, length 48
Leap indicator: (0), Stratum 4 (secondary reference), poll 4 (16s), precision -26
Root Delay: 0.010879, Root dispersion: 0.000213, Reference-ID: 0xa29fc87b
Reference Timestamp: 4001681720.901341465 (2026-10-22T18:15:20Z)
Originator Timestamp: 4001681749.786431000 (2026-10-22T18:15:49Z)
Receive Timestamp: 4001681749.793798372 (2026-10-22T18:15:49Z)
Transmit Timestamp: 4001681749.793871429 (2026-10-22T18:15:49Z)
Originator - Receive Timestamp: +0.007367372
Originator - Transmit Timestamp: +0.007440429