What is the de-bricking process for HIKVision camera and NVR firmware updates?

We've seen that file reference elsewhere on this forum - I don't think there was an explanation of why such a foreign file would appear on a Hikvision NVR TFTP firmware update activity.​
But - what's interesting is the IP address that's connecting is that of the base of the network segment that Hikvision NVRs use by default for the PoE ports.
Presumably your PC and NVR are both still the only devices on the LAN - and no cameras still plugged in to the PoE ports?
And no PoE ports wired in to your LAN?

Hi firstly thank you for your reply
The nvr is on a bench in my workshop now with nothing plugged into it other than my laptop on the lan port.
But now you said that I'm going to try and disconnect the poe power supply see it that helps
 
tried that still comes back with the same fault code. If the chip on the board that holds the firmware was damage what error code would i get?
 
Very strange. There is clearly some firmware running because a TFTP client starts up and accesses your TFTP server at the 192.0.0.128 address - but from an address normally associated with the Hikvision NVR PoE ports. That's not an error message you're seeing - it's an attempted file access.

Completely off-the-wall idea - is it possible the internals are not a Hikvision board? Is the Amazon seller still selling the product? Googling econt_vision_av2000 yields no results.
Completely off-the-wall idea #2. Would there be anything lost by making a copy of the digicap.dav file and renaming it as the 'econt_vision_av2000' that it seems to be trying for? Though you might have to change the PC subnet mask to 255.0.0.0
 
Very strange. There is clearly some firmware running because a TFTP client starts up and accesses your TFTP server at the 192.0.0.128 address - but from an address normally associated with the Hikvision NVR PoE ports. That's not an error message you're seeing - it's an attempted file access.

Completely off-the-wall idea - is it possible the internals are not a Hikvision board? Is the Amazon seller still selling the product? Googling econt_vision_av2000 yields no results.
Completely off-the-wall idea #2. Would there be anything lost by making a copy of the digicap.dav file and renaming it as the 'econt_vision_av2000' that it seems to be trying for? Though you might have to change the PC subnet mask to 255.0.0.0

Thank you
No the seller not amazon any more. How would find out if it's a genuine nvr pcb? is there anywhere i can type in serial number to find out?
your changing the file name was a good idea but it's still coming up with the exact same thing? :-(
If you think it's running some kind of firmware how can i get rid of it. So it doesn't boot up anything
 
Thank you
No the seller not amazon any more. How would find out if it's a genuine nvr pcb? is there anywhere i can type in serial number to find out?
your changing the file name was a good idea but it's still coming up with the exact same thing? :-(
If you think it's running some kind of firmware how can i get rid of it. So it doesn't boot up anything

unbelievably it started working. i was just about to give up so i plugged it back into my home network. for some strange reason it showed up on its original ip address on hik SADP but wouldn't stay there. just kept coming and going again and wouldn't log on to its web page. So I logged onto ivms 4200 and navigate to factory reset. then just kept on clicking reset and still accepted it.
then the unit restarted picture came up on screen, bob's your uncle, it was working.
 
Just to add, as I was flashing an updated firmware to our NVR 7616 something. After starting the flash, from 1000km away, it did its reboot and then I couldn't access it again.
So, found this thread and franticly tried to reflash what I assumed was a bad update. Three TFTP servers later and found it didn't need a reflash.

In the end it just ended up on a strange subnet/IP, 192.168.1.64

So I just wanted to put that here as I thought it would have defaulted to 192.0.0.64 so that it could reach my TFTP server on 192.0.0.128, but seems not?

Anyway, SADP found it, and then I could change it to my correct subnet and be running again.

Now if HK could put an email test button into the web gui, as I still can't test my emails on latest f/w from 1000km's away :(

a.
 
Hi Everyone,
Last night I appeared to brick Hikvision DS-2CD2532 Mini Dome.
I have followed the instructions on this forum as much as I can, and I think I have had partial success.
I downloaded the digicap file from the HV website, put it in the Auto Update folder, I set my IP to 192.0.0.128, ran the TFTP application, rebooted the camera, on the TFTP app I got the update success message.
However, while I can access the camera via 192.0.0.64 through FTP when my IP is set to 192.0.0.128, It does not show on the SADP, I cannot access the HTTP page. I have run a IP scanner to see if my router reassigned the IP but the camera does not show.
Appreciate any help!
 
  • Like
Reactions: seydemi
Hello all, I recently updated my 7604ni-se/p and it failed to boot. I downloaded tftp as viewed in the forums and after some tweaking I got the tftp to connect but ended up with the " Open file failure[H:\Auto Update\econt_Vision-AV2000]" message. I tried multiple firmware downloads in the root file with tftp but no joy, any help would be appreciated. -Andy
 
Andy - a couple of things to suggest, apologies if you've already done this:
The TFTP server must be the Hikvision-specific one, as seen in the window title 'Hikvision TFTP server'.
And don't connect the PC directly via a cable to the NVR, make sure both are just connected to ports on your normal network switch or router, ideally the same one. You don't need to isolate the router or switch.
I've found on the NVR that the TFTP server can spin round on timeouts for 2-3 minutes before it does a re-try and catches the download. And then the upgrade can take 2-3 minutes while it erases and writes the flash.
So if you're not watching the action via a serial console connection, some patience is needed.
 
  • Like
Reactions: abusch13
Andy - a couple of things to suggest, apologies if you've already done this:
The TFTP server must be the Hikvision-specific one, as seen in the window title 'Hikvision TFTP server'.
And don't connect the PC directly via a cable to the NVR, make sure both are just connected to ports on your normal network switch or router, ideally the same one. You don't need to isolate the router or switch.
I've found on the NVR that the TFTP server can spin round on timeouts for 2-3 minutes before it does a re-try and catches the download. And then the upgrade can take 2-3 minutes while it erases and writes the flash.
So if you're not watching the action via a serial console connection, some patience is needed.

Thanks Alastair for the quick reply. I put the NVR on my router instead of a direct connection to the PC, I also went back and forth between normal and crossover cable and it finally worked with a normal 568B cable. I was able to go back to 2.3.10 and everything seems to be working. Maybe my NVR will hold the date now instead of reverting to 1970 after a reboot.

A note to others with trouble, after not connecting initially (connect client failure) with the PC ip set to 192.0.0.128 I tried setting the PC ip to 192.168.1.128 thinking that my ip may have remained when I bricked the NVR, this made tftp connect but left me with the aforementioned " Open file failure[H:\Auto Update\econt_Vision-AV2000]" message. Plugging it in to my router and switching back to 192.0.0.128 did the trick, thanks again Alastair
 
Hi All,

Trying to recover a bricked DS-2CD2032-I. Lots of good posts here but I have a couple of questions on the tftp recovery process:
1. I see a number of references to the Hikvision tftp auto updater utility but all links mentioned on this thread
as well as others seem to be broken (I get the instructions but not the tool). Anyone know where I can find it?
2. Is the Hikvision auto updater required? I am running tftp server on my Mac. Can I just place the upgrade
firmware file in my tftp root directory and plug in the camera or is there an intermediate binary that gets loaded first?

Thanks in advance.
 
1. I see a number of references to the Hikvision tftp auto updater utility but all links mentioned on this thread
as well as others seem to be broken (I get the instructions but not the tool). Anyone know where I can find it?
http://www.hikvision.com/europe/download_more.asp?id=1336

2. Is the Hikvision auto updater required? I am running tftp server on my Mac. Can I just place the upgrade
firmware file in my tftp root directory and plug in the camera or is there an intermediate binary that gets loaded first?
It must be the Hikvision-specific Windows TFTP server (Says Hikvision TFTP Server in the window title bar) because the camera does a Hikvision-specific handshake with it before it will use it.
The digicap.dav file needs to be placed in the same folder as the tftp executable, and the PC must have a static IP address of 192.0.0.128
All very specific.
And best not to connect the camera and PC directly with a network cable - wire each into a router or switch with their own cable. The router and switch doesn't have to be isolated from the normal network.

When the camera powers on, the bootloader enables the Ethernet interface with an IP address of 192.0.0.64, does an ARP request for the device on 192.0.0.128 and sends a UDP packet to port 9978 with the Hikvision 'Magic number' SWKH to look for a Hikvision-specific response from the TFTP server. If the TFPT server provides the response (a UDP packet on 9979 with the Magic number in the payload), the camera will connect to it and attempt a download and install of digicap.dav for the firmware update.
Your normal TFTP server will be ignored for the purposes of a firmware update.
 
Well, No luck on recovering my camera. I bricked it trying to apply the 2.5.2 NFS patch. The only thing I could have done was to corrupt the /dav/davinci.tar.gz file but per another post on the NFS issue that should be recoverable with a tftp upgrade. I have the Auto-update SW installed on a windows 7 PC in C:\ along with the update file. The Auto-update initializes on 192.0.0.128 as expected but I never see a request from the camera. I have the laptop and camera on an isolated 100Mb L2 switch with nothing else on any other port. My receive packet counter on the laptop is at zero so the camera is never even issuing the 'who is' broadcast. Weird thing is that the camera does look to be alive in that the LED's come on if I dim the lights and the link comes up on the switch immediately with power and then blinks about 5 seconds later (like the driver has initialized it). Anyway, I much appreciate the help.
 
Well that's not good. Usually there is at least some activity on a TFTP recovery even if the end result isn't always successful. The software to do this is built into the bootstrap, so generally untouched and always available.
I don't think corrupting the /dav/davinci.tar.gz would cause a permanent problem as it is replaced on the firmware update.

You will presumably be using the Hikvision version of the TFTP server. I don't know if having it in the root of your drive would be a problem - but that is different from how it's usually done, in a folder.
To finally check if there are any signs of life at all, on the PC at a command prompt, you could set a continuous ping going with 'ping -t 192.0.0.64' and check for the 2 or 3 replies that occur after the camera is powered on.
 
  • Like
Reactions: ichi
The pdf hikvision supplies has bad instructions. I was running into this same problem. Once I had the HIKTOOL server running BEFORE I turned on the NVR, it worked properly. Hikvision's pdf told me to wait 3 seconds.


I can try that then. It just doesn't make sense if my computer can't ping 192.0.0.64 while in the 192.0.0.x/24 subnet.

Will report back.

EDIT: REPORTING BACK

It worked! The trick was that the NVR needed to be rebooted multiple times for it to finally detect the TFTP server. I am so relived, thank you so much!
 
I've found by watching the serial console that for the NVR, it can take 5 or 6 minutes for the tftp server to be recognised, if the first attempted access fails, which it seems to do fairly often. Some sort of timing issue.
The u-boot tftp client spins round in a loop until it eventually times out after about 3-4 minutes, then does a retry and it 'catches'.
But that's not obvious if you don't have the serial console to watch.
 
  • Like
Reactions: catseyenu
I have a DS-2CD2332-I that I tried to update the fireware and now its bricked. Once I try to use the tftp tool it stops, see the image below
attachment.php
 

Attachments

  • Capture.PNG
    Capture.PNG
    84.5 KB · Views: 575