Out of curiosity I thought I'd check out the origin of this behaviour.
It turns out that it's a new program, introduced in the 5.4.0 version of the firmware, designed to provide an automated check / possible fix for network problems, perhaps due to common faults like poor cabling.
The run-time parameters have been changed a bit between firmware versions, and the implementation has not considered that the situation where a camera may just be sitting idle on the network, and not transmitting packets, is not a fault condition.
In the 5.4.0 and the 5.4.5 firmware the respective invocations of the network check program are as follows:
Code:
/bin/network_deamon -d 0x0F -r 0x01 -t 30 &
/bin/network_deamon -d 0x0a -r 0x01 -t 60 &
And the meaning of the command-line parameters in the network_deamon program (sic) can be interpreted as follows:
Code:
# network_deamon -h
Usage:./network_deamon [-d diagnose_item] [-r repair_way] [-t interval]
-d(hex): 0x00(def): check link status.
0x01(bit1): check whether rx packets change or not.
0x02(bit2): check whether tx packets change or not.
0x04(bit3): check whether err packets change or not.
0x08(bit4): check whether interrupts change or not.
0x10(bit5): check whether duplex is right or not.
-r(hex): 0x00(def): repair by reset netdev.
0x01(bit1): repair by reboot after the times of reset network more than 3.
0x02(bit2): repair by reboot.
0x04(bit3): repair by setting netdev mode to 10M/FULL.
-t(dec): check network status every interval senconds, default 30.
-f(str): specify log file.
-v: print version.
-h: help.
Example:./network_deamon -d 0x0f -r 0x01 -t 30 &
#
As we know that Hikvision do pay attention to this forum, hopefully they have picked up on the comments in this thread and will implement a better approach in the next revision.
