Firmware problem with DS-7616NI-I2/16P

[MikeC504]

I updated the firmware on my DS-7616NI HIK NVR. This was the first time I ever had done this. I believe the new firmware revision is V4.40.010build 200430.

The unit appears to work after the upgrade sort of. I had HikConnect set up prior to the upgrade and I am still able to view my cameras through that. On the iVMS-4200 PC desktop app, I can only mount the NVR through HikConnect. I can't mount the NVR through the local connection. The password seems wrong.

Using a direct connect monitor and keyboard, I attempted to do a direct login. I am unable to type in user names to enter 'admin' for my password and instead there is garbage characters user names (about 30 of them). See below.







I already did a bit of research on this. One post said just to hit enter (null password) on each of these. It does not work and I don't see why it would anyway as that suggests you don't need a password to log in. I also attempted the password reset where I email information to HIK and send me back an XML file to load through the SADP tool. This said it was successful but the password does not work at the terminal.


When I try to use IVMS-4200 on my PC, it just shows up as offline when I use the admin and password (the one I got from resetting with HIK tech support)







Any help would be greatly appreciated as I am really stuck.

 

[Trax95008]

First, what version was the firmware before the upgrade? Hikvision advises when upgrading to V4, that you are currently at a certain level or higher.

Second, I have experienced the multi user issue when upgrading in the past. I was able to overcome it. If you look at the list of users, at the end of the string there was a reference to “admin”. I think I had to hover the mouse over the string to get it to expand. Select that one, and use your original password. Then once you get it, go to the user page and delete all the additional users

 

[MikeC504]

unfortunately, I have no idea what version the previous firmware was. Also, as you can see in my pics, it is all garbage characters in all the "users". None of them say Admin. Is another firmware update required to fix this? How would I do that when I cannot even log into the unit. Thanks

 

[J3C]

I have the exactly problem with my Hikvision DS-9632. I made sure it was on v3.4.92, then upgrade to v4.22 only to encounter this problem. I tried the blank password but it does not work. I sent and received the XML file. SADP says that it's modified but there's no change on the login screen or IVMS. I came across the tftp method but I can't change the IP address of my NVR without the password.

 

[alastairstevenson]

I came across the tftp method but I can't change the IP address of my NVR without the password.

You don't need to change the IP address - in tftp updater mode it's fixed (bootloader variables) and is separate from the normally configured one.
But the Hikvision tftp updater won't work as the firmware filesize is above its 32MB limit.
Scott Lamb's tftp updater clone doesn't have the limit -

GitHub - scottlamb/hikvision-tftpd: Unbrick a Hikvision device (NVR or camera) via TFTP

Unbrick a Hikvision device (NVR or camera) via TFTP - scottlamb/hikvision-tftpd

github.com

 

[J3C]

I'm gonna give it a try and I'll update. Thanks for the quick response.

 

[MikeC504]

J3C,

sounds like you have the same issue I do.

What exactly is the tftp method? Presumably you are doing to this to load an entirely new firmware image. Why would you expect a different firmware image to not have a problem with the admin password?

In my case, I still have do have access to the NVR through the hikcloud service. Would it be better to just do a complete reset of the unit rather than do a firmware update which now seems likely a risky proposition at best?

Would this reset the admin password to default (whatever that is)?

See below:

 

[alastairstevenson]

When using the tftp updater method to apply firmware, the device is reset to the default configuration, thus eliminating the corrupted values in the configuration database that are preventing the ability to log on.

 

[alastairstevenson]

In my case, I still have do have access to the NVR through the hikcloud service. Would it be better to just do a complete reset of the unit rather than do a firmware update which now seems likely a risky proposition at best?

Yes, that's worth trying - if you can reset back to defaults you should have recovered the situation.
The reference to updating firmware is purely linked to the Hikvision tftp updater facility, which automatically does a reset to defaults as part of the process.

With the device still in its inaccessible state via the web GUI access - it might be interesting to see if the Batch Configuration Tool is able to log in to the device.
Within it's configuration options there is also a reset to defaults.
Though I have a recollection the people have tried this for the same problem, without success.

Batch Config Tool

Activate or configure multiple Hikvision cameras or one at a time.

ipcamtalk.com

 

[J3C]

J3C,

sounds like you have the same issue I do.

What exactly is the tftp method? Presumably you are doing to this to load an entirely new firmware image. Why would you expect a different firmware image to not have a problem with the admin password?

In my case, I still have do have access to the NVR through the hikcloud service. Would it be better to just do a complete reset of the unit rather than do a firmware update which now seems likely a risky proposition at best?

Would this reset the admin password to default (whatever that is)?

See below:

View attachment 68704

I think restoring to default settings is the best option for you. I wish I had that option. Unfortunately I don't have hikcloud set up so that's not an option for me.

 

[J3C]

You don't need to change the IP address - in tftp updater mode it's fixed (bootloader variables) and is separate from the normally configured one.
But the Hikvision tftp updater won't work as the firmware filesize is above its 32MB limit.
Scott Lamb's tftp updater clone doesn't have the limit -

GitHub - scottlamb/hikvision-tftpd: Unbrick a Hikvision device (NVR or camera) via TFTP

Unbrick a Hikvision device (NVR or camera) via TFTP - scottlamb/hikvision-tftpd

github.com

I'm not sure if I fully understood the TFTP method. I proceeded based on a procedure that was given in a different thread. Simply to connect my computer to the NVR via a switch, run the application and it should load the digicap file automatically.

Using the file you sent, I followed the instructions and ran the application. The only thing that I wasn't able to do is to set my computer to IP 192.0.0.128, since the NVR is on a different IP address/subnet. I tried it with my standard IP for my computer and restarted the NVR hoping that it would connect as per the instructions. There was a brief moment of joy only to end in failure. The image will show this.......



I'm not sure what the "econt_Vision-AV2000" is. There is no such file in the directory.

 

[alastairstevenson]

I'm not sure what the "econt_Vision-AV2000"

It's just a consequence of the NVR doing a probe on normal start-up for any Arecont_vision devices on the network. The probe operates similarly to the probe for the Hikvision tftp updater, which gives the confusing message when it receives it. Which can be ignored.

I'm not sure if I fully understood the TFTP method.

The Hikvision tftp updater (or a functional close of it) waits for UDP probe requests on a specific IP address (192.0.0.128) on a specific port.
The NVR on startup issues a probe.
If the tftp updater receives it, they do a handshake and download a prospective firmware file for updating.
But with the 32MB filesize limite of the original Hikvision version, the Scott Lamb close would have to be used.

The only thing that I wasn't able to do is to set my computer to IP 192.0.0.128, since the NVR is on a different IP address/subnet.

That only applies to normal running.
The tftp updater uses a pre-defined, separate IP address.

You don't need to obscure local IP addresses - they are not private, we all have much the same.
Strictly - the original tftp updater requires that it uses 192.0.0.128
Which isn't what yours is set to.

 

[J3C]

So you're saying that regardless of what the NVR's IP is, once I set my computer to the pre-defined IP address (192.0.0.128), it should initiate the handshake and download the firmware?

I thought that since the NVR has an IP of 192.168.1.1 /24 and the computer's IP must be set to 192.0.0.128/24 that it wouldn't connect. That's why I didn't change the computer's IP.

and yes I downloaded the version from Scott Lamb in the link you provided earlier.

 

[J3C]

But with the 32MB filesize limite of the original Hikvision version, the Scott Lamb close would have to be used.

I made a slight mistake on my part. I downloaded the wrong TFTP application thinking it was Scott Lamb's. I see the python file/code. I'm not familiar with python scripts but I'll do some quick reading and give it another attempt.

 

[J3C]

It's just a consequence of the NVR doing a probe on normal start-up for any Arecont_vision devices on the network. The probe operates similarly to the probe for the Hikvision tftp updater, which gives the confusing message when it receives it. Which can be ignored.


The Hikvision tftp updater (or a functional close of it) waits for UDP probe requests on a specific IP address (192.0.0.128) on a specific port.
The NVR on startup issues a probe.
If the tftp updater receives it, they do a handshake and download a prospective firmware file for updating.
But with the 32MB filesize limite of the original Hikvision version, the Scott Lamb close would have to be used.


That only applies to normal running.
The tftp updater uses a pre-defined, separate IP address.

You don't need to obscure local IP addresses - they are not private, we all have much the same.
Strictly - the original tftp updater requires that it uses 192.0.0.128
Which isn't what yours is set to.

I made another attempt and configured my computer's IP address to 192.0.0.128\24. The IP address on the NVR is 192.168.120.200\24. I ran the script and this is what I'm getting



I assume it's because I can't reach the device on this IP and subnet. I tried \8 but since the NVR is \24, it won't work(well at least I don't think it is/will)

I am relatively new when it comes to IP cameras so forgive my lack of experience. I appreciate your assistance in helping me debrick this NVR. At this point I think the computer at 192.0.0.128 needs to be able to talk to the NVR at 192.168.120.200, unless there's something I'm missing.

 

[alastairstevenson]

At this point I think the computer at 192.0.0.128 needs to be able to talk to the NVR at 192.168.120.200

No, the tftp update process uses an IP address that's configured in the bootloader environment variables, as opposed to the normal running IP address that's configured separately in the web GUI.
Historically, that bootloader address has been set as 192.0.0.128
But for some years Hikvision have been withdrawing support for this firmware update method, and there have been indications that it is absent in newer devices.
However - I seem to recall that there were posts suggesting the target address had changed to 192.168.1.128 on newer NVRs.
That would be worth trying.

You appear to have managed to get the Python app running.
Though that doesn't mean access would be allowed in through the Windows firewall - it may be best to disable that temporarily.

 

[J3C]

No, the tftp update process uses an IP address that's configured in the bootloader environment variables, as opposed to the normal running IP address that's configured separately in the web GUI.
Historically, that bootloader address has been set as 192.0.0.128
But for some years Hikvision have been withdrawing support for this firmware update method, and there have been indications that it is absent in newer devices.
However - I seem to recall that there were posts suggesting the target address had changed to 192.168.1.128 on newer NVRs.
That would be worth trying.

You appear to have managed to get the Python app running.
Though that doesn't mean access would be allowed in through the Windows firewall - it may be best to disable that temporarily.

I disabled the firewall and made another attempt. Initially I only got what I sent in my previous post but after restarting the NVR I got this message "08/17/20 15:04:06: received unexpected tftp bytes '417265636f6e745f566973696f6e2d41563230303001' from 192.168.120.200:3352" and nothing after that. It just seems to be hanging.

I also tried with the computer IP as 192.168.1.128 to no avail.

 

[J3C]

No, the tftp update process uses an IP address that's configured in the bootloader environment variables, as opposed to the normal running IP address that's configured separately in the web GUI.
Historically, that bootloader address has been set as 192.0.0.128
But for some years Hikvision have been withdrawing support for this firmware update method, and there have been indications that it is absent in newer devices.
However - I seem to recall that there were posts suggesting the target address had changed to 192.168.1.128 on newer NVRs.
That would be worth trying.

You appear to have managed to get the Python app running.
Though that doesn't mean access would be allowed in through the Windows firewall - it may be best to disable that temporarily.

UPDATE: I finally got through!!!. I realized that I had been trying to go through only one LAN port when the other was configured with IP 192.0.0.64. Once I connected it and rebooted the NVR. It installed the firmware and reset it to factory defaults.



Now I have to reconfigure the NVR. Many thanks for all your help and patience.

 

[alastairstevenson]

Wow! Well done indeed for persisting.
It was looking like a 'well now you need to hook up to the serial console, so buy these items' a bit longer task.

I realized that I had been trying to go through only one LAN port when the other was configured with IP 192.0.0.64.

This is LAN ports on the NVR, it's a model with 2?
That may help others, thanks for sharing that info.

 

[J3C]

Yes, on the DS-9632NI-I8 there are two LAN ports. I use one to connect through the network/Web GUI and the other is on a separate network (192.0.0.64) for the cameras only. All this time I was using the first port to do the TFTP, then just when I was about to give up I remembered there's a second port with the addressing scheme of 192.0.0.64. So yeah that saved me. Thanks again for all your help. I'm new to this forum but already I see the community in this community.