tftp update - econt_Vision-AV2000 error (7716 NVR)

J

JohnnyBoy

n3wb
Feb 15, 2016
26
2
Hi I am trying to use the tpfp tool as the current software will not allow me to set a DDNS (just physically wont save, but that's another matter. See below video for example)

In any case, I cannot get the tftp tool to work, i get the same error message every time. Search on the web shows that most people can get around the error by simply rebooting the NVR over and over until it finally works. I have tried about 30times on 2 different computers and still no luck.

8F24B4DF-267D-4FDB-A9EE-7227E4A358CB_zpss2bshe9t.jpg



What ive done so far.
- NVR connected directly to computer (no cameras connected to NVR)
- NVR connected to switch, then to computer
- local network set to 192.0.0.128
- NVR set to 192.0.0.64
- Firewall disabled
- ran program as administrator
- installed in C directory

Does anyone have a method of getting the tool to work?

Very frustrating
Thanks




https://www.youtube.com/watch?v=m58lOEkHwt8
 
What's the current firmware version?
What version are you trying to update to?
Have you tried the update via the web GUI?
Have you tried the update via the USB port with a memory stick and the HDMI/VGA interface?
 
alastairstevenson said:
What's the current firmware version?
What version are you trying to update to?
Have you tried the update via the web GUI?
Have you tried the update via the USB port with a memory stick and the HDMI/VGA interface?
Click to expand...
Current Version V3.3.4 build 150616
Trying to update to 3.4.0 (but honestly i'll take any version)
Haven't tried via USB port. I was told i needed to run the tftp first from the support guy i bought it from. I would much rather do a USB update. (this is a Chinese NVR so not sure if that limits things)

They support guy asked a weird question about when the device was manufactured, was Feb 2016. Not really sure of the relevance of that though.

Thanks
 
They support guy asked a weird question about when the device was manufactured, was Feb 2016. Not really sure of the relevance of that though.
Click to expand...
I suspect, though I don't know for sure, that the tftp updater in the bootloader has been altered.
Definitely try the web GUI update method, then the USB update method, either should work OK.
 
NVRs do not TFTP in the same manner than cameras do. The process is not automatic. It requires a serial console to stop U-boot and instruct it to look for TFTP at a given address.

While I can't explain why the random garbage it spits out on the TFTP server side of things, I do know it appears their firmware is either borrowed or stolen from another lesser known manufacturer, ArecontVision. AV does manufacture a video server/recorder type of device with a model number of AV2000. Someone at Hikvision slipped up, as their branding still resides in current firmware releases.

Notice the truncated "econtVision?" That's where it's from.

As far as solving your actual problem, try fetching 3.4.2 from the Hikvision portal as that is most current and updating that through the web interface or copy digicap.mav onto a flash drive in the root directory and upgrade direct from the NVR display. I would send you a link but I'm not sure if you have the SP series or the E4 series. The firmware is not interchangeable.


Sent from my iPhone using Tapatalk
 
I had the same problem as Johnyboy had. Tried millions time, but failed, the same message as he posted. I am quite sure that the fw is for that particular model, because I could update the machine through regular flash drive method. The only reason I need tftp is for resetting forgot password. (like to take things into my own hand, not through their technical support.)

I guess the failure is related to the tightening security measure from Hikvision. They probably altered the way how tftp works, I dealt with different models from Hikvision and I can be sure that tftp was working fine before on the models that are not so secure(remember we still have the instruction on webpage reset password tool on this forum:-)

If any senior members from this forum post an instruction on how serial port works, will be really appreciated.
 
If all you need is a password reset, and you have a US NVR, just contact them, they will be able to help you. It's not worth the trouble of TFTP just to restore a password. Now, if the firmware update screwed up your admin user account (this happens on every one when upgrading from earlier 3.x versions to 3.3.x on up. It scrambles the letters and makes them unreadable characters and locks you out from being able to fix it. That is when serial recovery is absolutely required.

I've been meaning to write a full serial recovery guide in hopes of it becoming a sticky, but haven't had time. I'm hoping to get that done in the next couple weeks. In the mean time, you need:

-Windows computer with PuTTY and a Hikvision TFTP
- F/F serial RS-232 cable
- USB to RS-232 M cable
- set putty to connect via serial with settings BR 115200,DB 8, parity none, SB 1, FC none.

Connect it all together, open putty on the correct COM port (which can be found in device manager), set the connection settings then power on the NVR and be prepared to hit CTRL+U rather quickly. The rest is given in prompts. Make sure TFTP is running with digicap.mav contained within.

That's a quick crash course, I will include photos and screenshots in my yet-to-be-made guide. I've done this so many times since I buy a lot of somewhat older recorders and every one with older firmware bricks when upgrading. If it ships with 3.3.x and you upgrade from there, no issues. It all revolves around their new Activation feature. The TFTP recovery process has not changed one bit. Recorders simply behave differently than cameras do and always have.


Sent from my iPhone using Tapatalk
 
Last edited by a moderator:
  • Like
Reactions: kazirafiq and shaoalan79
I do know it appears their firmware is either borrowed or stolen from another lesser known manufacturer, ArecontVision.
Click to expand...
That, I'm sure is unfounded.

What's actually happening is that, on NVR bootup, after the configured network connection has been applied (not the temporary initial setting where the probe for the Hikvision tftp updater is done), the NVR sends out a string of broadcasts looking for some of the fair list of manufacturers of camera and NVR that it can be configured to connect to.
It just so happens that the Arecont products can be found with a tftp broadcast, and this probe is one of those transmitted by the NVR.
And here is the interesting bit - the Hikvision tftp updater is also designed to respond to tftp broadcasts - it picks up the Arecont probe thinking it's aimed at it, and complains about the content. 'no such file'. And there isn't. Unless you are an Arecont device.
You may notice that Arecont is in the drop-down list of manufacturers supported.
 
alastairstevenson said:
That, I'm sure is unfounded.

What's actually happening is that, on NVR bootup, after the configured network connection has been applied (not the temporary initial setting where the probe for the Hikvision tftp updater is done), the NVR sends out a string of broadcasts looking for some of the fair list of manufacturers of camera and NVR that it can be configured to connect to.
It just so happens that the Arecont products can be found with a tftp broadcast, and this probe is one of those transmitted by the NVR.
And here is the interesting bit - the Hikvision tftp updater is also designed to respond to tftp broadcasts - it picks up the Arecont probe thinking it's aimed at it, and complains about the content. 'no such file'. And there isn't. Unless you are an Arecont device.
You may notice that Arecont is in the drop-down list of manufacturers supported.
Click to expand...

alastairstevenson you're the man! In the past I had been given bogus information from Hikvision themselves as to why this was happening. Your knowledge of Arecont finally explains this behavior. In past firmware this did not happen and now it all makes sense in that once Hikvision added 3rd party camera support for Arecont this started occurring.

Just to reiterate for everyone else, the only time Hikvision NVRs will try a tftpload is if they can't boot to an image (or as CoreyX64 pointed the boot is interrupted by serial connection to the NVR). This is unlike Cameras which always try TFTP first.
 
  • Like
Reactions: CoreyX64
Your knowledge of Arecont finally explains this behaviour.
Click to expand...
Because this topic comes up every so often as an apparent error (which it isn't) on upgrade attempts and confuses people.
Thanks for the compliment but I just started the Hik tftp updater and rebooted my NVR and had a look at the traffic.
And had a sneaky peek somewhere else.
The missing (Ar)econt is because they missed out the tftp opcode in the firmware coding so the Ar gets swallowed as that.
 
alastairstevenson said:
That, I'm sure is unfounded.

What's actually happening is that, on NVR bootup, after the configured network connection has been applied (not the temporary initial setting where the probe for the Hikvision tftp updater is done), the NVR sends out a string of broadcasts looking for some of the fair list of manufacturers of camera and NVR that it can be configured to connect to.
It just so happens that the Arecont products can be found with a tftp broadcast, and this probe is one of those transmitted by the NVR.
And here is the interesting bit - the Hikvision tftp updater is also designed to respond to tftp broadcasts - it picks up the Arecont probe thinking it's aimed at it, and complains about the content. 'no such file'. And there isn't. Unless you are an Arecont device.
You may notice that Arecont is in the drop-down list of manufacturers supported.
Click to expand...

Be that as it may, code sharing is common practice, especially with cheap Chinese hardware and anymore it wouldn't surprise me to see code borrowed from other devices, especially if it's open source (android etc). I really doubted that Hikvision sunk that low, but it didn't make sense as to why it was spitting that out. You cleared that up perfectly.

As far as the TFTP recovery process is concerned, that is correct. The likelihood of a true brick to where the onboard flash is corrupted and it will auto-seek TFTP recovery is slim to none. So for practicality reasons, if you truly want to force a TFTP recovery, serial is the only way to do it. With IPCs, TFTP is sought before The Linux kernel is decompressed and boot process is initiated, which is why immediately after camera power up you start to see TFTP responses. The NVRs don't have that "pre-boot" seek, so it never scopes out TFTP first. That is its last-resort boot method. When forced serially, IP addresses don't matter (you don't have to use the hard coded 192.0.0.x/24 addresses defined by Hikvision spec). It'll prompt you to specify a device address (recorder) and server address (your computer). I've always just done this right over my main network and it does simplify things a bit. Aside from a bit of soldering (can't find a UART connector pigtail to save my life) it's been a fairly easy and straightforward process.
 
So does that mean the 3rd party support for Arecont is broken and will not work?
Click to expand...
Because it's looking for 'econt' as opposed to 'Arecont'?
I suppose that's possible - though it will depend on exactly how the Arecont device recognises and handles the broadcast.
Certainly the Hikvision tftp updater shows the truncated filename.
But presumably there would be no problem with a manual selection and configuration, as opposed to picking from the handy list of 'found devices' which may not have them.
 
Could you please help me to connect to a hikvision DVR? i did what you say on these posts but after hiting ctrl u command it doesn't upgrade...it show me only a comand line starting with HKVS $ . Where sould be the problem ?
 
catalin onofrei said:
Could you please help me to connect to a hikvision DVR? i did what you say on these posts but after hiting ctrl u command it doesn't upgrade...it show me only a comand line starting with HKVS $ . Where sould be the problem ?
Click to expand...
On that DVR Hikvision have tried to obscure the way in which commands can be issued at that bootloader.
To issue commands, you need to use 'setenv' and then enclose the command in single quotes and precede it with a semicolon.
For example :
Code: 
HKVS $ setenv ';printenv'
bootcmd=tftp 0x42000000 $(bootfile);bootm 0x42000000;
default=cramfsload 0x42000000 uImage;
sec=tftp 0x42000000 Ky2017-1-uImage_sec;bootm 0x42000000;
bootdelay=1
baudrate=115200
ipaddr=192.0.0.64
serverip=192.0.0.128
gatewayip=192.0.0.1
netmask=255.255.255.0
bootfile=uImage
passwd=Ff7mqPaKbKihTW5nC3vk5IoiCntz1B0tcwzUMtMOJFI=
phyaddr0=7
mdio_intf=rgmii
ethaddr=64:db:8b:8b:3e:01
stdin=serial
stdout=serial
stderr=serial
verify=n
bootargs=mem=296M console=ttyS0,115200n8 ;printenv

Environment size: 481/4092 bytes
HKVS $ setenv ';help'
?       - alias for 'help'
bootm   - boot application image from memory
brush   - brush a flash image to the Flash, Be Carefully.
bubt    - Burn an boot image on the Boot Flash.
cpld    - write cpld info to  encrypt media
cramfsload- cramfsload  - load binary file from a filesystem image
cramfsls- cramfsls      - list files in a directory (default /)
ddr     - ddr training function
erase_env- erase envirement info on flash
getinfo - print hardware information
help    - print command description/usage
loadb   - load binary file over serial line (kermit mode)
loady   - load binary file over serial line (ymodem mode)
md      - memory display
mii     - MII utility commands
mm      - memory modify (auto-incrementing address)
mw      - memory write (fill)
pflash  - print the compatibility list of flash.
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
tftp    - tftp  - download or upload image via network using TFTP protocol
update  - Update the digicap of the device.
version - print monitor version
HKVS $
 
JohnnyBoy said:
Current Version V3.3.4 build 150616
Trying to update to 3.4.0 (but honestly i'll take any version)
Haven't tried via USB port. I was told i needed to run the tftp first from the support guy i bought it from. I would much rather do a USB update. (this is a Chinese NVR so not sure if that limits things)

They support guy asked a weird question about when the device was manufactured, was Feb 2016. Not really sure of the relevance of that though.

Thanks
Click to expand...

I know from a fried about usb update but we need tftp in iso format and a bootable usb made with rufus and of course with tftp.iso and at the end copy paste *.dav on that usb and the nvr/dvr get update from ... but i dont find anyware that tftp.iso ...
 
CoreyX64 said:
If all you need is a password reset, and you have a US NVR, just contact them, they will be able to help you. It's not worth the trouble of TFTP just to restore a password. Now, if the firmware update screwed up your admin user account (this happens on every one when upgrading from earlier 3.x versions to 3.3.x on up. It scrambles the letters and makes them unreadable characters and locks you out from being able to fix it. That is when serial recovery is absolutely required.

I've been meaning to write a full serial recovery guide in hopes of it becoming a sticky, but haven't had time. I'm hoping to get that done in the next couple weeks. In the mean time, you need:

-Windows computer with PuTTY and a Hikvision TFTP
  • F/F serial RS-232 cable
  • USB to RS-232 M cable
  • set putty to connect via serial with settings BR 115200,DB 8, parity none, SB 1, FC none.

Connect it all together, open putty on the correct COM port (which can be found in device manager), set the connection settings then power on the NVR and be prepared to hit CTRL+U rather quickly. The rest is given in prompts. Make sure TFTP is running with digicap.mav contained within.

That's a quick crash course, I will include photos and screenshots in my yet-to-be-made guide. I've done this so many times since I buy a lot of somewhat older recorders and every one with older firmware bricks when upgrading. If it ships with 3.3.x and you upgrade from there, no issues. It all revolves around their new Activation feature. The TFTP recovery process has not changed one bit. Recorders simply behave differently than cameras do and always have.


Sent from my iPhone using Tapatalk
Click to expand...
Could you make a guide? I am a noob, need to reset admin password on an NVR, HIKVision denied to help as the product is from Gray Market. Help needed. TIA
 
Hi guys, pleasure to meet you all. I recently tried to log into my ds-7604ni-k1/4p after a power cycle but I am unable to enter a username & password does not work. Is there a way I can log into my nvr again? Thank you
 
kazirafiq said:
Could you make a guide? I am a noob, need to reset admin password on an NVR, HIKVision denied to help as the product is from Gray Market. Help needed. TIA
Click to expand...

That is not what this post was about when I made it several years ago. It allowed recovery of a corrupted login database, and was specific to SP model NVRs running older firmware.

If your unit is running older firmware, an older version of SADP couple with an online Hikvision password reset tool calculator might be able to bring it back to life.
 
You must log in or register to reply here.
Top Bottom