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

[whoslooking]

What does the label on the camera say I.E default fw and manufacturing date.

 

[business4]

Thank you whoslooking it's back up and running. I'll never upgrade the firmware again lol.

 

[brainy]

Thank you whoslooking it's back up and running. I'll never upgrade the firmware again lol.

Your screenshot is exactly like mine. How did you get it back up and running?

 

[business4]

Using the firmware whoslooking posted.

 

[Kyle]

I have a LTN7716 NVR, which is a DS-7716ni-st. It currently has firmware V3.1.1 build 140611 and i'm trying to upgrade it to version V3.3.4_150616 via TFTP. But I'm receiving the following error in tftp. Any idea's? Thanks everyone.

[2015-10-12 15:38:36] Connect client success [192.168.1.130]Success

[2015-10-12 15:38:36] Open file failure[C:\Auto Update\econt_Vision-AV2000]

 

[alastairstevenson]

On the face of it (assuming the LTN7716 works like the Hikvision products) you are not using the required 192.0.0.128 IP address for the Hikvision-specific tftp updater.

 

[Kyle]

On the face of it (assuming the LTN7716 works like the Hikvision products) you are not using the required 192.0.0.128 IP address for the Hikvision-specific tftp updater.

I set the ip address to 192.0.0.128 just like it said . I double checked the settings also

 

[alastairstevenson]

[2015-10-12 15:38:36] Open file failure[C:\Auto Update\econt_Vision-AV2000]

This isn't so much an error as what usually occurs after the NVR has fully booted on its normal IP address. My theory is that it's some old left-over bit of code in the firmware, but I'm not sure. I'm pretty sure it can just be ignored.
So - if you are not seeing any 'client connect' from the assumed 192.0.0.64 IP address that the NVR uses temporarily during the update check after power-on, it would be worth checking your Windows firewall settings in case the probe packet from the NVR is being blocked.
Windows firewall | Advanced settings | Inbound rules - check there are 'Allow' rules for TCP and UDP for Public and Private for the program 'tftpserve.exe'

 

[Kyle]

This isn't so much an error as what usually occurs after the NVR has fully booted on its normal IP address. My theory is that it's some old left-over bit of code in the firmware, but I'm not sure. I'm pretty sure it can just be ignored.
So - if you are not seeing any 'client connect' from the assumed 192.0.0.64 IP address that the NVR uses temporarily during the update check after power-on, it would be worth checking your Windows firewall settings in case the probe packet from the NVR is being blocked.
Windows firewall | Advanced settings | Inbound rules - check there are 'Allow' rules for TCP and UDP for Public and Private for the program 'tftpserve.exe'

I disabled windows firewall and my anti virus when I tried this.. I'm gonna give this another try when I get home and just add it to windows firewall... I would ping -t 192.0.0.64 when the NVR would boot.. It did see it was there.. but once that message showed up it would boot as normal. .

 

[aster1x]

Ensure that the both PC/laptop and NVR are the only ones connected to the switch. Avoid using a router with a DHCP server running and also do not use a crossover cable connecting the NVR directly to the PC/laptop. In the past I have sniffed in the network that if the PC/laptop LAN port does not see any traffic it changes from the static IP you have assigned, to the local loopback of 127.0.0.1 and by that time the NVR does not receive any packet from the TFTP server and continues to boot normally, hence the response from the NVR IP which in your case is the 192.168.1.130 which I believe you have set statically to the NVR.

 

[maxideus]

I disabled windows firewall and my anti virus when I tried this.. I'm gonna give this another try when I get home and just add it to windows firewall... I would ping -t 192.0.0.64 when the NVR would boot.. It did see it was there.. but once that message showed up it would boot as normal. .

I had this issue before and you can find my fix on page 2 of this thread.

You may need to reboot the NVR many times until the TFTP server gets picked up. I found that my NVR does not ever work on the first go around. As well, make sure your NVR is not statically addressed.

 

[Kyle]

I had this issue before and you can find my fix on page 2 of this thread.

You may need to reboot the NVR many times until the TFTP server gets picked up. I found that my NVR does not ever work on the first go around. As well, make sure your NVR is not statically addressed.

Thank you.. I was able to upgrade to firmware that supports my 4MP stream..

 

[nstechhelp]

I keep getting the same error as others in this post:

[2015-18-11 07:42:02] TFTP server [192.0.0.128] initialized
[2015-18-11 07:42:25] Connect client success [192.0.0.64]Success
[2015-18-11 07:42:25] Open file failure[C:\tftp\econt_Vision-AV2000]

I tried to upgrade the firmware, put in the new secure password and now it will not allow be to login. I cannot put in a username. I believe this is why the TFTP keeps failing. I have used SADP and the web gui to try and login but nothing works. I emailed HikVision for the password reset code, however that did not work either. I am hoping some of the people here more familiar with Hikvision can help out. We just got these 9016 NVRs last week and now can't use them.

When I use puTTy it says it is connected but I can't type or see anything so CTRL-U is not working on boot. Telnet and SSH drops the connection with a time out error, why I'm thinking it is somehow looking for a password.

Thank you

 

[alastairstevenson]

9016 is unfamiliar to me so I'm probably not much help.
I think on the newly manufactured products Hikvision have reduced the functionality of the tftp updater process, you may now need to use the serial console.
Does the 9016 have an RS232 DB9 plug on the back?

When I use puTTy it says it is connected but I can't type or see anything so CTRL-U is not working on boot.

Serial connection? Are you using 115200 baud rate, 8N1 parity?
Normally the serial console is fairly chatty even with no user input.

What does SADP show? An IP address on your normal LAN range?

 

[nstechhelp]

Yes it has a serial port. I have tried with the cable from the laptop to the NVR as well as using a null modem USB to Serial and nothing is showing.

Those are the settings I am using both on puTTy and in device manager. The IP on SADP is 192.0.0.64 and I have the laptop set to 192.0.0.128 255.255.255.0 with AV and firewall turned off.

 

[alastairstevenson]

The on-board serial console on cameras and NVRs is typically a TTL level serial facility. I'm wondering what the external DB9 standard is - classic RS232, and therefore what standard is the adaptor on your laptop.
Another forum member used the DB9 on the back panel - but I didn't have a recollection of the standard of serial connection that was used.
This may be worth reading:
https://www.ipcamtalk.com/showthread.php/5756-Think-I-bricked-my-NVR-Help!/page3?highlight=db9

Surprisingly (I haven't seen this myself) there was a post a while back where the Win7 firewall was apparently off, but the connection did not work because a block rule was operating.
If the rules are set correctly, there is no need to disable the firewall.
Shut down the tftp server. Enable the firewall.
Start | Control panel | Windows firewall | Advanced Settings | Inbound rules then find and delete all rules associated with the program 'tftpserve.exe'
Start the tftp server, and when the 'Do you want Windows ... ' message box pops up, tick both Public and Private and click allow.

 

[nstechhelp]

I just checked the specs on the 9016 it says it has a RS-232 DB9 serial port on rear panel, to which I am connected. I will try enabling the firewall when I'm back at it tomorrow. Thanks for the help so far I will let you know how it goes.

 

[nstechhelp]

I removed the computer from our domain, enabled the firewall and added all the ports to allow. It still doesn't work, but I am no longer dropping UDP packet as per the firewall log.

Next I am going to try removing any programs that may conflict with COM port settings.

 

[alastairstevenson]

but I am no longer dropping UDP packet as per the firewall log.

That's how the NVR/cameras 'probe' for the Hikvision-specific tftp updater. The UDP packet holds the magic number.

 

[nstechhelp]

It seems to be connecting on the TFTP but still getting the Avocent issue and no communication on puTTy. Was using an WinXP machine because that's the only one with a serial port, going to try a Win7 machine now once I get it ready

- - - Updated - - -

2015-11-20 08:16:17 CLOSE UDP 192.0.0.100 192.0.0.64 1094 3352 - - - - - - - - -
2015-11-20 08:25:26 OPEN UDP 192.0.0.128 192.0.0.64 1131 3352 - - - - - - - - -
2015-11-20 08:27:17 CLOSE UDP 192.0.0.128 192.0.0.64 1131 3352 - - - - - - - - -
2015-11-20 08:30:33 OPEN UDP 192.0.0.128 192.0.0.64 1140 3352 - - - - - - - - -
2015-11-20 08:32:17 CLOSE UDP 192.0.0.128 192.0.0.64 1140 3352 - - - - - - - - -

The Close is when I power cycle the NVR