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.