We've identified an issue when utilizing Dahua cameras with our VMS. This originates from an unexpected response to the Date and Time request sent from the server to the cameras.

Cause of the issue

Using Wireshark, you have the capability to capture communication between network devices, such as the request sent from the VMS server to the Dahua Camera, as shown below.

The VMS initiates the following request to the camera to retrieve accurate System Date and Time:

POST /onvif/device_service HTTP/1.1
Host: 172.16.5.53
User-Agent: gSOAP/2.8
Content-Type: application/soap+xml; charset=utf-8; action="http://www.onvif.org/ver10/device/wsdl/GetSystemDateAndTime"
Content-Length: 830
Connection: keep-alive
SOAPAction: "http://www.onvif.org/ver10/device/wsdl/GetSystemDateAndTime"

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" 
xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding" 
xmlns:onvifDevice="http://www.onvif.org/ver10/device/wsdl" 
xmlns:tt="http://www.onvif.org/ver10/schema" 
xmlns:wsa5="http://www.w3.org/2005/08/addressing" 
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" 
xmlns:xmime="http://tempuri.org/xmime.xsd" xmlns:xop="http://www.w3.org/2004/08/xop/include" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <SOAP-ENV:Body>
        <onvifDevice:GetSystemDateAndTime />
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>



 

In response, the camera provides the following reply:

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Connection: close
Content-Length: 1008

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:sc="http://www.w3.org/2003/05/soap-encoding" xmlns:tds="http://www.onvif.org/ver10/device/wsdl" xmlns:tt="http://www.onvif.org/ver10/schema">
    <s:Header />
    <s:Body>
        <tds:GetSystemDateAndTimeResponse>
            <tds:SystemDateAndTime>
                <tt:DateTimeType>NTP</tt:DateTimeType>
                <tt:DaylightSavings>true</tt:DaylightSavings>
                <tt:TimeZone>
<tt:TZ>GMT+00:00PDT,M3.5.0/01:00:00,M12.5.0/02:00:00</tt:TZ>
                </tt:TimeZone>
                <tt:UTCDateTime>
                    <tt:Time>
                        <tt:Hour>19</tt:Hour>
                        <tt:Minute>48</tt:Minute>
                        <tt:Second>11</tt:Second>
                    </tt:Time>
                    <tt:Date>
                        <tt:Year>2023</tt:Year>
                        <tt:Month>12</tt:Month>
                        <tt:Day>4</tt:Day>
                    </tt:Date>
                </tt:UTCDateTime>
                <tt:LocalDateTime>
                    <tt:Time>
                        <tt:Hour>19</tt:Hour>
                        <tt:Minute>48</tt:Minute>
                        <tt:Second>11</tt:Second>
                    </tt:Time>
                    <tt:Date>
                        <tt:Year>2023</tt:Year>
                        <tt:Month>12</tt:Month>
                        <tt:Day>4</tt:Day>
                    </tt:Date>
                </tt:LocalDateTime>
            </tds:SystemDateAndTime>
        </tds:GetSystemDateAndTimeResponse>
    </s:Body>
</s:Envelope>

When the status code HTTP/1.1 200 OK is received, it indicates the request was successful and is therefore utilized by the VMS.

In this instance, UTCDateTime matches LocalDateTime, whereas in reality, the local time is +1 hour ahead of the UTC time. Consequently, the UTCDateTime is incorrect and should have been 18:48:11.

Why is this important?

During authentication, nonces play a vital role in HTTP digest access authentication by enabling the calculation of an MD5 digest of the password. Given that nonces are time-based, and use the UTCDateTime, ensuring precise time is essential; otherwise, it will render the nonce invalid.

How to work around this issue?

Fortunately, there's a straightforward workaround for this issue. Simply ensure that the timezone set in the Camera matches the timezone set in the server OS, and disable Daylight Saving Time (DST) on the camera.

Limitations

Implementing this workaround will prevent the use and display of the On-Screen Display (OSD) time on the camera stream. However, during footage playback, the VMS itself will accurately display the correct time. Additionally, within the VMS Export settings, there is an option available to include a text overlay showcasing the accurate date and time aligned with the timestamp of the VMS server.