Dahua Camera Crash/Reboot abort ?

[yozh 0]

You're not the first, nor the last person that will have problem with software NVRs (let's call them NVRs, although they are NAS devices). It's been 6 months and you still are chasing solutions for a problem that can be solved in a jiffy, with a simple solution.

 

Temporarly, you could get a NVR for a week for testing purposes to be sure that the problem is in the Synology software.

 

 

Look at the prices of the DVRs. This is my home setup. The Synology was working good... Seems the firmware on the cameras is the issues. I`m sorry, but if you have any input on where to get the firmware....

[dexterash 0]

If you disconnect the Synology from the IPC and the camera still reboots, then it's a problem with the camera. But if it only reboots when Synology connects to it, then the problem is in the client software that might issue random commands that could make the camera reboot.

 

We've been working for over 5 years with DAHUA products. There are no such bugs that could make the hardware reboot, unless either it's a hardware error (temperature, bad RAM, etc) or something that comes from an external source (like a 3rd party client software).

 

Ok, forgot the "bad install" error .

[yozh 0]

Im sorry Im not here to argue whos fault it is or not, but if ipc is shutting down from a nvr which using a view only account. That would seem a problem with an ipc specially that other 9 cameras from other brands and 1 from same brand model 2100 is not having this issue. I found a PAL version if the latest firm, do you guys think I can use that ?

[dexterash 0]

2100 is almost 2 years old and is already obsolete. 4100 is about 6-8 months old. In two years Synology had the time to fix any bugs that appear when connecting to that camera. 4100 might be a little bit too new.

 

I'm not here to argue, just wanted to try to point you in some directions to find the culprit.

[yozh 0]

Its a 4200s and it was working fine. I dont see how synology with view only account can shutdown a camera.

[dexterash 0]

It's simple: Synology cannot connect using the standard, proprietary protocol that DAHUA products use to communicate between them (port 37777), so it uses a general RTSP protocol(as defined per ONVIF standard) that, usually, relies on opensource live555 library. Live555 library is known to be buggy when decoding RTSP streams, encoded by different RTSP servers.

 

When setting up the RTSP connection, the client issues different commands as per protocol specifications, but some of these commands might be out of protocol specs or might be device-dependent. Actually the RTP/RTCP part of that protocol might pose those problems. So, sometimes it works ok, sometimes it doesn't. To be honest, seems more like a lucky dice throw.

[yozh 0]

Again pointing to a bug in the camera for not understanding standards.

 

Question at hand right now. Can I use PAL firmware ? I see the latest v2.42 can I use on the NTSC camera ? i know in synology I can change to use PAL as the source.

[dexterash 0]

You should try, but hardly will solve your problem.

[yozh 0]

If it stops rebooting/shutting down that this will fix my problem.

[yozh 0]

Ok so here is the thing. I have been going crazy with this for over a week. Last week it just started working. No crashes nothing, just began working. Then I saw that Synology had another update for the DSM and I updated it. When update started, just this 2 cameras crashed again. Had to be reboot and so the circle started again. SO me being sure it was the synology. I disabled the camera in synology and too my surprise, it crashed again. With nothing connected to it. Both cameras crash at almost always at x.45-55 on the hour. Like some kind of a job running on them. I sniffed the traffic to the cameras in wireshark and all I see are my pings, and some upnp discovery traffic (which I disabled on cams btw) I`m stuck. The old root password for dahua is not working to login and check maybe there is a cron working or something. I dont know, what else to do. I have a 2100 which is stable, but firmware is never on it. I really need help as I have to manually reboot (poe) my cameras.

 

Some more info:

 

The both crash at the same exact time, which is just bizarre.. The firmware is NTSC from December last year. I cant find newer for NTSC. I have just been stumped on what to do here. Some how Synology upgrade triggered the crashes, but with synology out of picture they are still continue to crash or something... Strange enough, I have a scheduled reboot at 2am, so if the camera drops of the network at lets say 1am, at 2am it will still reboot, but then at 3 will go down again, 2:55am to be exact.

[dexterash 0]

Reset the cameras to defaults. If that doesn't fix, reflash the cameras.

[yozh 0]

Reflash with what exactly ?

[dexterash 0]

With the latest firmware that you can get for the cameras.

[yozh 0]

I did this multiple times. One of the cams that I tried to reset from the button on the cam it self and it never recovered its dead now . I cant deal with this cameras any more.

[dexterash 0]

Where's the logic? The system worked (in a way), then you upgraded (for some reason) a part of the system, the whole system failed to work after the upgrade, and you are still blaming the rest of the components, but not the one that you changed/upgrade?!

 

No, there is no cron in DAHUA(lacks from the Linux). The Synology just f*cks servers implemented in cameras due to poor implementation of client commands.

 

BTW, have you talked with Synology about this?

[yozh 0]

There is no logic .... But how would a system that had only view account would screw up the cams ? But i dont have synology in picture now and they are still rebooting. I cant explain it can you ?

[dexterash 0]

As I stated before, Synology sends some "setup" requests to the cameras, before the actual streaming begins. In these requests the client tries to change the servers' streaming parameters so it can match Synology's decoding power/decoding library/decoding client. So the "view" also implies some setup/parameter changes in cameras' RTSP server.

 

And yes, they are still rebooting. We had a similar case where a Synology NAS screwed the voice communication of the cameras(in the setup portion of the RTSP protocol). We had to completely wipe the flash and rewrite the firmware. After that, all went ok - but we recommended not to use Synology's client anymore. And the system has worked flawlessly since that.

[yozh 0]

Ok now we getting somewhere. How did you wipe flash before updating firmware. Ill do that. I have a 2100 which is working flawless ... With this NVR. But it is newer firmware. I tried reseting one camera with onboard reset button but it never recovered. The intresting part about all this that when I was upgrading last time the cameras went down when SS service was disabled. I misswrote they are not rebooting. They are dying, dropping of the network and never coming back, Im guessing they are hanging. I can not get any other NVR at this time, Im invested in to synology and this cameras. This is what I have right now, changing NVR is not an option specially that 8 other cameras are working perfect including 1 dahua. And they worked fine before as well. So please help me with my setup not help me change it at this time.

[dexterash 0]

Our wiping involved desoldering the flash(NAND ic), wiping it through a flash eraser and rewriting the whole flash. We tried at cameras' Linux level with no luck (most partitions are read-only), so no telnet/root access can help and the commands/utilities available are very limited.

 

And yes, newest firmwares have dynamic root passwords (due to publicly available root password a patch was created and implemented).

[dexterash 0]

They are dying, dropping of the network and never coming back, Im guessing they are hanging.

Ok, thay can hang from some reasons, but I've never seen one device that will not come back alive. The software/hardware combination does not allow this.

So, either the camera come backs but at a point it hangs and you never see it online (and enters a reboot loop) or the hardware has a problem.

All the software in these cameras is monitored by the hardware. If the software hangs, the hardware reboots the cameras.

[yozh 0]

Intresting. They hang. No reboot. Have to manually reboot or the scheduled reboot at 2am reboots them.

[dexterash 0]

Ok, define "hang".

 

Ping requests?

Webserver alive(port 80)?

Proprietary data server (port 37777) alive?

ConfigTool sees them alive?

[yozh 0]

None of those show camera as a live, no MAC on the port eather and not ARPing out.

[dexterash 0]

no MAC on the port eather and not ARPing out.

Huh? What does arping have to do with checking tcp ports' response? Or the MAC?

 

So the camera doesn't even respond to ping? Check the hardware/network. The network part of the cameras starts way before any other server/service. Even with a broken firmware, 50% of the cameras are able to respond to ping requests. Something's fishy around there.

[yozh 0]

no MAC on the port eather and not ARPing out.

Huh? What does arping have to do with checking tcp ports' response? Or the MAC?

 

So the camera doesn't even respond to ping? Check the hardware/network. The network part of the cameras starts way before any other server/service. Even with a broken firmware, 50% of the cameras are able to respond to ping requests. Something's fishy around there.

 

 

LOL I`m sorry, I`m a network person. The way networking works, when a device becomes active on a network it first sends it MAC address and switch ports stores this address in the MAC address table (CAM) this MAC can be seen on a managed switch on the port that device is connected to. When another device wants to communicate on layer 3 via IP to another device on the network, its sends out a ARP request (still at layer 2), basically saying "who has IP X.X.X.X, please tell me" the device that has that address sends back the ARP request with its MAC address, the device then stores the ARP to IP entree for a specific time and does not have to reARP again.... Anyway back to this when the camera crashes/hangs there is no MAC on the switch port, hence no ARP there for no PING, or IP, TCP (Layer 4) communication going on, while layer 1 (physical connection) is still up...

 

 

SO yes something fishy going on and I dont know what...