Hikvision DS-7616NI-SP Firmware issue

[CoreyX64]

Hi,
I have a DS-7616NI-SP that has had some small issues here and there, nothing absolutely critical, but just more of nuisances that have bothered me for about 6mo to a year. In checking for a firmware update I saw there was a 3.3.4 version available for the 76xx series NVRs and decided to apply it and am now quickly regretting it. Perhaps it wasn't meant for my box even though it was part of the series or I did something wrong. Oops.

While the upgrade completed successfully and technically didn't brick (the NVR boots up fine), it erased all of the users stored on the system (including admin) so I have no way to go in and make any changes or even revert back to a previous version. SADP shows the NVR but displays an IP of 0.0.0.0 of which I will never be able to connect to. TFTP with both a crossover and straight pair cable does not start the usual "test tftpserver" prompts. it says "client connect failure" or something like that twice. I've tried many of the obvious things but am lost now as to how to proceed to revive the NVR. There was another thread on here where someone's NVR did the same thing, but they were able to recover it using TFTP. (I can't find it at the moment) My computer is set to 192.0.0.128 and DG at 192.0.0.64.

Lastly, it is a genuine US-regioned device. No mods or otherwise. If anyone could shed some light on this it would be greatly appreciated. Thanks!

 

[alastairstevenson]

TFTP with both a crossover and straight pair cable

A direct connection can be unreliable depending on the timing of the PC NIC handling the interface up/down/up that occurs during the NVR bootup. But it sounds like you've done this successfully previously.
Much better to connect both as normal into your LAN, on the same switch or router. And be patient - it can take 5 or 6 minutes for the whole process, erasing the flash, writing new etc.

My computer is set to 192.0.0.128 and DG at 192.0.0.64.

192.0.0.64 is the IP address the NVR will use when testing the TFTP server. I don't know if that will cause a problem with the PC networking having the default gateway set to that - but it should be changed.

If all else fails, you should be able to do a firmware recovery if you can connect to the serial console.
If that's something you feel able to try, there is a thread on here somewhere (this forum is so big now that searching isn't so easy) that has a link to the 4-pin connectors needed, and USB to TTL serial are available in large numbers for low prices on eBay and Amazon etc.

 

[rommycam]

Hi CoreyX64,

You must use tftp server tool from Hikvision, otherwise recovery could'nt work :
- I still able to download from there www.hikvision.com/europe/download_more.asp?id=1336
- your ip setup is OK, make sur that your PC must able to ping the NVR address
Type : ping 192.0.0.64 -t
On the short time when power up - and it's will reboot again and again.
Cross cable is normally ok, directly between PC & NVR.
If you don't want to bother with which kind of cable, just connect the PC and NVR to one same switch.
- running the Hikvision Tftpserv on your PC, digicap.dav firmware file must be in the same folder as the server.
- make sure that firewall didn't block the tftpserv server, you have to authorize the software or deactivate firewall, but anyway check that tftpserv is not block
- before power up the NVR, make sure you have on screen : ping windows running, tftpserv windows running and ready to detect the NVR boot process
- power up the NVR look at ping windows return values - if ping is OK look at tftpserv windows normally must signal in few second NVR detection
then signal another new message line to inform download is initiated
- you must attentively survey the fourth messages signalling the complete download - immediately you have to close the tftpserv windows to halt the program - because the NVR will automatically reboot - and will restart the recovery process again if tftpserv still running.

After bricking my NVR.
I have done all theses steps last week to recover my 7616N-E2/P (Chinese ) and am able to upgrade it to 3.3.4.
I will describe the entire process with screens captures- when time permit.
Sorry for my English.

 

[CoreyX64]

Thank you for the replies. Typically in TFTP'ing firmware to the IP cams themselves I've needed to set the DG to the camera's default IP of .64. Setting the PC to .128 is needed because thats what Hik devices look for when trying to recover.

In any case, the TFTP server does not show responses from the NVR at all. only "client connect failure" twice. crossover, straight pair, or otherwise. I haven't tried to recover over my network, which I will do next and see if it makes a difference. I didn't think to check ping responses either. Good idea.

As far as serial goes, the 7616 has an RS232 serial port on it already connected to a serial header on the logic board. In theory I should be able to use this combined with PuTTY to do something with this thing. I have desktops with onboard serial ports I can use, as well as a CH340 USB-Serial adapter.

I have done TFTP before on IP cams successfully before. I know how the Auto Update tool works. Never tried it with an NVR, and this doesn't seem to be cooperating. The fact that SADP is reporting it at an IP of 0.0.0.0 worries me.

Also, can you confirm that 3.3.4 requires 5.3+ firmware on the cams themselves? Mine are chinese cams at 5.2 english currently. The specs say it requires 5.3 but they've said in previous versions that it needed 5.1.2, 5.1.2, 5.2, etc. as versions increased but I had no issue using older versions. Perhaps this is different. I love the new UI on this firmware though.

Screenshots to follow. I'm on a different computer than the ones they were snapped from.

 

[rommycam]

When i had brick my nvr after toying with various firmware - from 3.0.8 to 3.1.0(us), 3.3.2 and 3.3.4 (euro) by web gui, it' s continuously rebooting after 3 beeps. I was worry because my NVR model lack the serial interface - then couldn't reverse the process by using console. Fortunately when it's brick, it's IP address it's set to default 192.0.0.64 - but my PC couldn't reach it - until I deactivate the firewall.
I don't remember if SADP detect the NVR in brick state but ping do.

Also with tftpserv method, my nvr accept to be successfully downgrade from 3.3.2 to 3.1.0

My cam model is 5.2.5 ds-2cd2132f-is.

3.3.4 still lack snapshot attached to email alert, but offer the smart event line crossing detection (more reliable than motion detect), no telnet either (I hope to be able to upgrade with tftpserv).

 

[CoreyX64]

The new GUI is what I'm really after above all else. Email alerts I really don't use so that's a moot point.

Here are some screenshots

This is connected NVR-Switch-PC, or NVR-PC (DHCP excluded)

... and this is with tying that switch into the rest of my home network (DHCP included)

either way, it fails to read the file or update in any way shape or form. May break down and just go the serial method. Need to find a DB9 gender changer though.

 

[rommycam]

From second screen shot, it seems that your NVR nic is in auto mode and had an assign address by your home router's dhcp.
Do your home subnet is in the range of 10.60.3.xxx ?
I'm wonder if ping to 10.60.3.10 or SADP is working.
When you first upgrade to 3.3.4 do the NVR when restart is asking for new password to be assign? My do, like it first start from factory default.
May be NVR is work fine, just put your PC in the same network then restart browser with 10.60.3.10.

(Open file failure because of firmware language flag mistmatch with the one already in the NVR ?)

 

[alastairstevenson]

@rommycam

3.3.4 still lack snapshot attached to email alert,

I tested this on 1 7816N-E2 with the 3.3.4 firmware and it seemed to work OK. Apart from the small image sizes.
http://www.ipcamtalk.com/showthread...-DS-7608NI-E2-8P?p=40222&viewfull=1#post40222

 

[CoreyX64]

The NVR's MAC is registered with Static DHCP in the router. It pulls .10 every time. So in effect, is a static IP. However perhaps not as helpful for these kinds of diagnostics where it becomes DHCP reliant. Yes you are correct, 10.60.3.0/24 is the subnet used here at home.

10.60.3.10 is fully responsive, ping, web GUI, SADP, etc. as if its fully functional. I just have no way to login. When I first upgraded, yes, it did prompt me to enter a new password. However, there was no usernames in the user list to assign a new password to, so I could never get past this screen.

While it is a US-regioned NVR and I pulled the FW from the European site, the Web GUI took it gracefully. Besides, TFTP throws the same error when trying to restore the 3.1.5 US firmware. So that rules out language flags since it failed for US and non-US. I've done this with 2032 and 2132 cams many times before and it works great. It'll take both chinese and US FW via TFTP. never threw a fit. However this NVR is a different story. Won't accept anything.

 

[rommycam]

Without correct login, i dont't know if get in by console is possible? May be througt Ctrl U/u method during boot.

- Language flag
My chinese NVR is trick by reseller and is arriving with English flag=1, and it accept the us 3.1.0 without flag modified, but after reboot.
3.1.0 is coming with protect shell psh, so only way to upgrade is by web gui or tftpserv.
But I have to modified language flag of euro firmware to 2 to get upgrade done.
Because I think the reseller trick is gone after first upgrade, my NVR had returned to chinese inside.

 

[alastairstevenson]

Because I think the reseller trick is gone after first upgrade, my NVR had returned to chinese inside.

Yes, that is correct, you have replaced the original firmware, which may have been modified by the seller.

Is the NVR working OK now after you have used the euro firmware with lang=2 by Hiktools?

 

[rommycam]

@alastairstevenson

Yes the NVR is working now with 3.3.4 euro firmware with Lang=2 with Hiktools.

 

[rommycam]

- Original getHardInfo of my NVR :

Start at 2015-08-01 11:15:36
Serial NO :16201xxxxxxxxxxxxxxxxxxxxxxx
V3.0.8 build 140825
KernelVersion: V1.0.0 build 140512
dspSoftVersion: V5.0 build 140816
codecVersion: V5.0 build 080808
hardwareVersion = 0xb000
encodeChans = 0
decodeChans = 16
alarmInNums = 0
alarmOutNums = 0
ataCtrlNums = 2
flashsize = 0x10
ramSize = 0x400
networksNums = 2
language = 1
devTypeS-7616N-E2/8P
bootPartition = 2
randomCode = QGQKQW

-Updating my NVR with Hikvision tftpserv :

[2015-08-01 15:29:55] TFTP server[192.0.0.128] initialized


[2015-08-01 15:30:20] Device[192.0.0.64] test tftpserver


[2015-08-01 15:30:20] Connect client[192.0.0.64] success


[2015-08-01 15:30:20] Start file[D:\Hikvision\NVR\Updater\tftp\tftp\digicap.dav] transmitting


[2015-08-01 15:30:41] Completed file[D:\Hikvision\NVR\Updater\tftp\tftp\digicap.dav] transmit

- 3.3.4 System Information snap-shot

- Smart Event Snapshot

 

[alastairstevenson]

Hey, looking good! Well done.
Don't forget to save the device configuration in a safe place when you have finished configuring.

 

[rommycam]

The new GUI is what I'm really after above all else. Email alerts I really don't use so that's a moot point.

Here are some screenshots

This is connected NVR-Switch-PC, or NVR-PC (DHCP excluded)

... and this is with tying that switch into the rest of my home network (DHCP included)

either way, it fails to read the file or update in any way shape or form. May break down and just go the serial method. Need to find a DB9 gender changer though.

@CoreyX64

Hi Corey,

From experience tftpserv recovery on my NVR today, I get the same failure message here :
[2015-08-08 22:41:38] TFTP server[192.0.0.128] initialized
[2015-08-08 22:42:39] Connect client[192.168.9.216] success
[2015-08-08 22:42:39] Open file[D:\Hikvision\NVR\Updater\tftp\tftp\econt_Vision-AV2000] failure

I had figure out that if NVR ip is not equal to 192.0.0.64 then the recovery will fail.
Here below with the correct address :
[2015-08-08 22:52:23] TFTP server[192.168.9.210] initialized
[2015-08-08 22:53:35] Device[192.0.0.64] test tftpserver
[2015-08-08 22:53:35] Connect client[192.0.0.64] success
[2015-08-08 22:53:35] Start file[D:\Hikvision\NVR\Updater\tftp\tftp\digicap.dav] transmitting
[2015-08-08 22:53:56] Completed file[D:\Hikvision\NVR\Updater\tftp\tftp\digicap.dav] transmit


In your case, the challenge is to get to correct NVR address.
You can try by setting your home router subnet to 192.0.0.1/24 and narowing the dhcp server address range : start address = 192.0.0.64, stop address = 192.0.0.64,
to have just only the NVR and the computer (with static 192.0.0.68) connect to the router ( this to ensure that 192.0.0.64 will be assign to NVR by dhcp server).

NVR stuck in login page :
I have experience the same with firmware 3.3.4.
It's happen with the input of the strong new password at the fresh start.
First i have input a new password with mix of letters and numbers upper/lower case like : Ashley23 and get stuck just after that : impossible to log in to the NVR.
But hopefully my NVR is still had 192.0.0.64 address allowing me to recover with tftpserv.

Letters and number is not sufficient i have to add special character to avoid the stuck login something like : Ashley23#%


Do you have try SADP password recovery with the manufacture code ? may be it's better .

 

[alastairstevenson]

[2015-08-08 22:42:39] Open file[D:\Hikvision\NVR\Updater\tftp\tftp\econt_Vision-AV2000
] failure

Just for info - this message means nothing, it's not a real failure, it looks like just some old code left behind in the Linux image. The NVR does this test after it has started up normally, and is using its normal IP address.

NVR stuck in login page :
I have experience the same with firmware 3.3.4.
It's happen with the input of the strong new password at the fresh start.
First i have input a new password with mix of letters and numbers upper/lower case like : Ashley23 and get stuck just after that : impossible to log in to the NVR.
But hopefully my NVR is still had 192.0.0.64 address allowing me to recover with tftpserv.

Does this sticking have a timeout, such as 20 minutes? Or did you find that it was permanent?

 

[rommycam]

I do have an usual timeout for 30 minutes after a sixth trie - anyway the new password that had been created isn't recognise.

 

[CoreyX64]

Thank you for the suggestion. I am always able to set a strong password but I have absolutely no idea what user ID it's assigning it to. That's the root problem. I am able to bring the NVR to 3.1.7 safely through a web upgrade. this provides me with the newer UI on the system itself, however the web UI is still the old interface. With that being said, 3.1.7's UI now provides a local FW upgrade method by connecting a USB storage device with the correct firmware placed on it. It even has a mini file browser too allowing you to delete files from said drive and pick the digicap file out of a bunch of folders. It's actually not too bad. However, this new feature was the key to bringing this NVR current and more importantly, back to life.

In the case of the 7700 series NVRs (this is CONFIRMED tested with a 7616-NI-SP and a 7732 of the same class). I do have some 7600s that I have not tried this on yet, however those have different firmware and more importantly, no serial port to recover. Until I get a TTL adapter, I'm not going to try that just yet.

Here is what I did:
1. Backed up config file of the original functional firmware (in my case, 3.1.5)
2. I spent some time upgrading to each new version at a time to determine where the fault was. From 3.1.7 to 3.2.1 via web GUI upgrades brought the problem back to life. Serial flashes didn't make the problem go away either.
3. Once I determined 3.1.7 to be the last known functional FW, I clean-flashed 3.1.7 onto the NVR and set it up brand new using the wizard.
4. Being amazed at how user friendly the new UI looked compared to the old, I went snooping for a bit under the assumption I was going to kill it for the 6th time. In doing so, I found the local firmware upgrade section.
5. Since the Web UI and RS232 both failed to bring this back to life on anything newer than what I had, I decided to upgrade locally from 3.1.7 to 3.3.4. It worked! I now have 3.3.4 running on a 7716 and a 7732.

This was a lot of trial and error and testing the waters but it worked for me and hopefully this helps anyone else out here with the no username issue.

Also, another thing to note, in answering my own question about an NVR requiring a certain firmware, my cameras are a mix of 5.2.0 and 5.2.3. The notes say it required 5.3.0 I believe (can't recall exactly), and the older IPC firmwares work fine. Now as far as regioning goes, all of mine are modded. I've left them as-is from the seller, so can't speak on that note. Wasn't there a pre-modded 5.2.5 somewhere floating around from CBX? with the region change already incorporated? Around February 2015 that thread got scalding hot between people and I lost track of things. I have a pre-modded 5.2.0 on hand for my older cameras, but the post- December 2014 cams that firmware will brick them so it's rather useless to me now.

Thanks again for everyone's help. Appreciate it.

 

[kccustom]

What exactly is "local FW upgrade" and how do you do it? I am in the same boat with my nvr stuck at the login with no username.

 

[CoreyX64]

the newer firmwares allow you to dump the firmware file onto a flash drive and upgrade it directly on the NVR. Local, as in not via ethernet, serial, or otherwise. directing in the NVR's GUI.