Time Server Problem
by PK232 from LinuxQuestions.org on (#6EKTS)
I recently purchased an additional security camera for a network without Internet access. After installing it, I noted the camera does not keep good time. It does however have a provision to routinely access timeservers for synchronization. Unfortunately it only lets you choose one of several Internet based time servers. You cannot enter your own IP address or server name so you cannot use a local time server. My solution was to put a local name server on the network and configure it so that the name of the Internet based time server resolved to my local time server.
The solution at first appeared to be a good one. The name server worked as it should and the camera queried the local Linux based GPS time server (Raspberry Pi), but the server did not respond. I next tried it with my backup time server, a Slackware based server with chronyd installed, and in that case the time server did respond. The bad news is that even though it appears the camera received the needed information, it did not update its time.
Any idea what is going on and is there a possible solution?
I first thought it might be DNS related (DNSSEC), but I think that unlikely if the camera did try to use the local time server in all tests. I next thought it might be something embedded in the return packets that identified where they came from, but at least in the time.nist.gov instance, it appears you have to make arrangements to use particular servers for that service.
The solution at first appeared to be a good one. The name server worked as it should and the camera queried the local Linux based GPS time server (Raspberry Pi), but the server did not respond. I next tried it with my backup time server, a Slackware based server with chronyd installed, and in that case the time server did respond. The bad news is that even though it appears the camera received the needed information, it did not update its time.
Any idea what is going on and is there a possible solution?
I first thought it might be DNS related (DNSSEC), but I think that unlikely if the camera did try to use the local time server in all tests. I next thought it might be something embedded in the return packets that identified where they came from, but at least in the time.nist.gov instance, it appears you have to make arrangements to use particular servers for that service.