search

agsh / onvif

ONVIF node.js implementation
http://agsh.github.io/onvif/
MIT License
693 stars 236 forks source link

Bug - problem with Axis camera replay attack protection when local PC time changes (via NTP) #172

Open RogerHardiman opened 3 years ago

RogerHardiman commented 3 years ago

Just a bug report for myself so I can go back and fix this at a later date. Summary:- We need to use a monotonic clock in Linux when processing GetSystemDateAndTime and not the local PC's currnet time.

Details:- I have an Axis Camera with the default ONVIF Replay Attack Protection switched on. This means the camera checks the time/date of ONVIF messages and they must be timestamped to be within 10 seconds of the Camera's time.

This is why the library use GetSystemDateAndTime and calculate the difference between the local time on the PC running NodeJS and the clock in the Camera.

The problem is that a Raspberry Pi does not have a battery backed up Real Time Clock. When the Pi boots the clock is set to time based on when the Pi last shut down. Then after the Pi has booted, NTP is used to get the actual time and date.

I am starting the agsh/onvif library on the Pi at bootup and it calls GetSystemDateAndTime and works out the time offset (delta) between PC time and Camera time. At this point the Pi does not have an accurate clock. (it is based on the time the Pi was last shut down) Then the NTP process then runs and the Pi's clock is set to a real value. At this point all the ONVIF commands to the Axis camera fail.

Workaround - disable Replay Attack Protection on the Axis camera int he Plain Config mentus

Proper fix - either re-run GetSystemDateAndTime and calculate the offset on a more regular basis, maybe after a command fails with a Not Authorized reply OR use the kernel Monotonic Clock for the delta offset.

chriswiggins commented 3 years ago

@RogerHardiman closing - good bug to have found, except this is more of a problem with your PC time changing and not the library. In saying that, a PR to fix it would be awesome :D

RogerHardiman commented 3 years ago

Re-opening this. It issue report was open for my own benefit so I would remember to come back and fix it. It still needs one more fix, to update timeshift if getSystemDateAndTime is re-run in case the far end camera has a change to its time (Eg if it was offline, clock drifted and then the camera got NTP and adjusted its time at which point 'timeShift' is wrong. So would be good to leave this open to remind me to fix a bug, unless there is a better place for me to write bug reports for myself.