5.4.5 Network Disconnected Exceptions

VorlonFrog said:
And it appears there were 89 "No Signal" exceptions logged overnight. :( :( :(

I've dropped the MTU to 1454, and decreased the video resolution and maximum bitrate. My feeling is, something is wonky with the network driver. Hikvision firmware should NOT be leaving the wired LAN connection active while the WiFi is active, and vice versa.

Even Foscam cameras don't have this problem.

View attachment 19503

Nope, even after decreasing the camera's values, the camera has still logged 16 "No Signal" exceptions in just the last 90 minutes. :(
Click to expand...

I spoke with Tech Support at BV Security / POE Depot this morning, and they now understand it's a problem in both firmware releases V5.4.4 and V5.4.5.
 
  • Like
Reactions: Bink
POE Depot's Tech Support spoke with me several times this afternoon, and elected to process a return for the camera I have. I told them I believe it's a firmware problem and not the actual hardware. They insisted on exchanging this questionable device, so I agreed. I cannot complain in any way with their support of the product. They've been helpful, listened carefully, and did a great job handling my camera problem. Thanks guys!!
 
  • Like
Reactions: Bink and alastairstevenson
I ran two different test scenarios with the cube camera overnight and all day today. Overnight it was connected via the LAN port and didn't log any No Signal exceptions at all. That was not terribly surprising. This morning I moved it into the same room as the wireless router (about twelve feet and one wall closer) and it's stayed connected all day with no exceptions. Checking the DD-WRT wireless router, it reports only 84% signal. At this close distance, it should be well over 95% signal strength. I'm guessing the wireless device in this camera (all of these?) is marginal.

Wifi Signal.jpg
 
VorlonFrog said:
I ran two different test scenarios with the cube camera overnight and all day today. Overnight it was connected via the LAN port and didn't log any No Signal exceptions at all. That was not terribly surprising. This morning I moved it into the same room as the wireless router (about twelve feet and one wall closer) and it's stayed connected all day with no exceptions. Checking the DD-WRT wireless router, it reports only 84% signal. At this close distance, it should be well over 95% signal strength. I'm guessing the wireless device in this camera (all of these?) is marginal.

View attachment 19548
Click to expand...

Both of mine are connected to wireless Bridges(along with my 3MP versions). And they use 5Ghz wifi. Since the cameras only use 2.4Ghz. I'm going to be getting a third 4MP one soon.
 
  • Like
Reactions: VorlonFrog
aaronwt said:
Both of mine are connected to wireless Bridges(along with my 3MP versions). And they use 5Ghz wifi. Since the cameras only use 2.4Ghz. I'm going to be getting a third 4MP one soon.
Click to expand...
Excellent idea. The wireless network logic in these cameras definitely needs some work. You get the advantage of a LAN connection AND using your 5GHz signal. Which wireless bridge are you using? Or is it a router repurposed as a wireless bridge? If so, which router? Just wondering.
 
VorlonFrog said:
Excellent idea. The wireless network logic in these cameras definitely needs some work. You get the advantage of a LAN connection AND using your 5GHz signal. Which wireless bridge are you using? Or is it a router repurposed as a wireless bridge? If so, which router? Just wondering.
Click to expand...

I use a bunch of the old Dlink DAP1522 APs in bridge mode(they have four GigE ports). I used to use them as Access Points a long time ago, but replaced them with Asus routers running in AP mode. The DAP1522s have no problem using 150Mb/s throughput over a wireless N 5Ghz connection. So the lower bitrate of the cameras are no problems.
 
AirGain Embedded WiFi Antenna.jpg
I opened up the replacement DS-2CD2442FWD-IW camera that arrived today to inspect the wifi antenna inside. Hikvision are using a newer style AirGain embedded antenna. I don't care what Airgain's design notes or marketing text says, the overall wifi performance is significantly degraded compared to an older Foscam C1 camera which uses an adhesive foil strip antenna inside the camera shell. Either that, or the tiny wifi daughterboard inside the camera is just weak. The power supply shipped with the cameras is only 500mA, which tells me the overall power draw of this cube camera is fairly low. It could also be starving the wifi daughterboard. I ordered a couple of 12VDC/2A adapters. I'll let you know if that makes any difference.
 
VorlonFrog said:
View attachment 19633
I opened up the replacement DS-2CD2442FWD-IW camera that arrived today to inspect the wifi antenna inside. ... The power supply shipped with the cameras is only 500mA, which tells me the overall power draw of this cube camera is fairly low. It could also be starving the wifi daughterboard. I ordered a couple of 12VDC/2A adapters...
Click to expand...
I seriously appreciate your feedback and insight here VorlonFrog, but I think we’re getting a bit off topic—the focus was on the networking issues/disconnects via the LAN port. While I can’t comment on the Wi-Fi—I think fixed devices using Wi-Fi is a bit dumb, particularly since you need to have power there anyway, but I can see why one would want to use it in a pinch—I can say that my PoE switch reports the actual wattage use of the camera to be around 3W and registering as a class 3 device.
 
  • Like
Reactions: VorlonFrog
For what it’s worth, I just upgraded my DS-2CD2432F-IW to 5.4.5 and it exhibits the same issue—worked without incident prior. I updated the thread title to reflect the firmware version instead of the model of camera... :/
 
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.
 
  • Like
Reactions: fenderman, marku2, ypoosn and 2 others
Nice sleuthing alastairstevenson! I wonder what the undocumented code for the diagnose item does and it actually appears they might be resetting often as opposed to rebooting, and the flags you noted denote a reboot.
 
Certainly worth a try - here is a sample, but not a lot to show:
Code: 
Thu Jul  6 09:32:27 2017
diagnose_way = 10, repair_way = 1, interval = 60
Thu Jul  6 09:35:27 2017
no tx packets
Thu Jul  6 09:35:27 2017
reset eth0.
Thu Jul  6 09:39:28 2017
no tx packets
Thu Jul  6 09:39:28 2017
reset eth0.
Thu Jul  6 09:43:29 2017
no tx packets
Thu Jul  6 09:43:29 2017
reset eth0.
Thu Jul  6 09:47:30 2017
no tx packets
Thu Jul  6 09:47:30 2017
reset eth0.
Thu Jul  6 09:53:31 2017
no tx packets
Thu Jul  6 09:53:31 2017
reset eth0.

I could take a look at the code later (I'm out today) but I don't think it will tell us much more, apart from explaining better how the command options are implemented.
Basically - Hikvision have introduced a new network diagnostic / fix tool aimed presumably at improving uptime, and with the settings chosen it's catching cameras that are not transmitting any packets over 4 minutes and resetting the ethernet interface on the assumption the hardware has hung.
 
  • Like
Reactions: ypoosn, VorlonFrog and Bink
Just thought I’d update this thread to say, it appears, 5.5 resolves this issue! Wooohooo! Hikvision didn’t bother to mention it in the “Release Note” though! I’ll reply to this thread again if I’m wrong!
 
I take this back. Seems the problem still persists, it’s just less consistent. Instead of the network being disconnected every 1-3 minutes, it now happens every five. Guess I still need to ping my cameras, but I won’t have to every minute :/ .
 
Same problem here, Ds-2CD2132F-IS firmware 5.4.5
I have add a ping every 5 minute but no success, lot of network disconnection...
Any news ? No 5.5.0 for this model..
 
You must log in or register to reply here.
Top Bottom