accepting requests..
Open TFTP Server MultiThreaded Version 1.64 Windows Built 2001
starting TFTP...
alias / is mapped to root\
permitted clients: all
server port range: all
max blksize: 65464
default blksize: 512
default timeout: 60
file read allowed: Yes
file create allowed: No
file overwrite allowed: No
thread pool size: 1
Listening On: 192.168.254.254:69
Client 192.168.1.108:1091 root\failed.txt, 1 Blocks Served
I am using method 2, my laptop has IP 192.168.1.1 and 192.168.254.254 asigned and I am using a cable to connect the VTO to my laptop who is disconnected from the network.
Console.bat is showing this :
C:\TFTP>console.bat
Ncat: Version 7.40 ( Ncat - Netcat for the 21st Century )
Ncat: Listening on 192.168.254.254:5002
I am using method 2, my laptop has IP 192.168.1.1 and 192.168.254.254 asigned and I am using a cable to connect the VTO to my laptop who is disconnected from the network.
That will most likely be an ethernet link detect timing problem.
It's missing the first file.
Ideally - both devices need to be connected via a switch so the PC link detect is always on, as opposed to being directly connected.
I also tried using a switch (simple one, not a router) but nothing happens.
I guess this method is not working for me, I need to go with TTL firmware upgrade.
now I see your post again.
681 243.998038 192.168.1.108 192.168.254.254 TFTP 111 Read Request, File: upgrade_info_7db780a713a4.txt, Transfer type: octet, timeout=1, tsize=0, blksize=1468
690 245.171387 192.168.1.108 192.168.254.254 TFTP 92 Read Request, File: failed.txt, Transfer type: octet, timeout=1, tsize=0, blksize=1468
reading this I notice that the vto listening on tftp server...
so I noticed that you didn't flash the bootloader I think that in your case you need to try to flash bootloader too, I did.
use the same commands I use in my guideline and generate the upgrade file
try 3 o 4 times to flash with tftp.
I extracted all the files DH_IPC-HX5X3X-Rhea_MultiLang_NP_Stream3_V2.800.0000013.0.R.191202.bin using the trick to make it a zip file (change the first 2 byte to PK).
I put these files into the tftp "root" folder per the instructions:
I followed all the TFTP networking instructions. The server failed to respond, because Windows Firewall stealth enabled itself on the USB LAN adapter I was using....
After disabling that.....
c:\Dahua_TFTPBackup>TFTPServer.bat
accepting requests..
Open TFTP Server MultiThreaded Version 1.64 Windows Built 2001
starting TFTP...
alias / is mapped to root\
permitted clients: all
server port range: all
max blksize: 65464
default blksize: 512
default timeout: 60
file read allowed: Yes
file create allowed: No
file overwrite allowed: No
thread pool size: 1
Listening On: 192.168.254.254:69
Client 192.168.1.108:2721 root\upgrade_info_7db780a713a4.txt, 1 Blocks Served
Client 192.168.1.108:2879 root\kernel.img, 1074 Blocks Served
Client 192.168.1.108:2912 root\partition-x.cramfs.img, 8 Blocks Served
Client 192.168.1.108:3596 root\romfs-x.squashfs.img, 2251 Blocks Served
Client 192.168.1.108:3535 root\pd-x.squashfs.img, 58 Blocks Served
Client 192.168.1.108:1665 root\user-x.squashfs.img, 10181 Blocks Served
Client 192.168.1.108:1900 root\custom-x.squashfs.img, 513 Blocks Served
Client 192.168.1.108:1757 root\web-x.squashfs.img, 3451 Blocks Served
Client 192.168.1.108:2582 root\.FLASHING_DONE_STOP_TFTP_NOW, 1 Blocks Served
Client 192.168.1.108:1789 root\success.txt, File not found or No Access
...and then:
Device Type IPC-HFW4830E-S
System Version V2.800.0000013.0.R, Build Date: 2019-12-02
WEB Version V3.2.1.825578
ONVIF Version 16.12(V2.4.3.822559)
Security Baseline VersionV1.4
Yay.
Wire shark certainly shows the TFTP request! I have the camera as the only device on the hub and the network configured precisely as above (with only that one adapter enabled). Image now out of date after fixing firewall.
No they don't come up on Config tool, Although they do have lights lit up inside them when I open them up? Is there a business that does this for a living as this stuff goes over my head.
If your camera still has a working bootloader (assume it does) then you can flash it easily, because:
The camera tries to download a file called "upgrade_info_7db780a713a4.txt" from a TFTP server running on 192.168.254.254 and executes the commands in said file in the bootloader (U-Boot) shell.
For more in-depth information, read this post: Dahua Firmware Mod Kit + Modded Dahua Firmware
Step 1, Configuring the network correctly.
The cameras IP is 192.168.1.108, the subnet mask is 255.255.255.0.
The camera uses 192.168.1.1 as gateway to connect to 192.168.254.254.
(It sends packets addressed to 192.168.254.254 to 192.168.1.1 because it's outside of the subnet)
There are two options to make the camera be able to reach your computer. Option 1)
If you have a router on 192.168.1.1, add a static route to it which redirects all packets which are meant for 192.168.254.254 to your computer (mine is 192.168.1.4):
If your router doesn't have this function then it fucking sucks and doesn't deserve to be called a router.
Option 2)
Plug the camera straight into your computers ethernet jack OR plug it into an ethernet switch where ONLY your computer and the camera are on (that's EXACTLY TWO devices).
Now you need to add the IP 192.168.254.254 with a subnet mask of 255.255.0.0 to your NIC.
If you opted for Option 1 you must not do steps 5, 6 and 7. (Or at least don't use the same IP as your router ^^)
If you opted for Option 2 you need to do all steps.
(Please remember to undo the changes after you're done)
It certainly would be nice to know if your network setup even works now, wouldn't it?
You could try to capture all the traffic on your ethernet card with wireshark and see if you are receiving anything from the camera (192.168.1.108) when you power it up.
You can skip this ^ and come back to it if the stuff below isn't working.
Step 2, download this archive which has all the necessary tools (TFTP server, upgrade_info tool, netcat for console log):
run dr
run dk
run du
run dw
run dp
run dc
tftp 0x82000000 pd-x.squashfs.img; flwrite
tftp 0x82000000 .FLASHING_DONE_STOP_TFTP_NOW
sleep 5
Step 3, flash it!
If you modified commands.txt, run Commands.bat.
Run TFTPServer.bat and Console.bat.
Power up your camera, it should start downloading from the TFTP server.
Close the TFTP server once you see "FLASHING_DONE_STOP_TFTP_NOW".
Done?
Thanks to @resegun for figuring out the magic behind upgrade_info_7db780a713a4.txt.
(If this helped you and you have some spare for a student: paypal.me/BotoX)
Just wanted to say that this helped me and unbricked an Amcrest cam of mine after a failed firmware update. I had no way of getting into my camera and it would simply reboot over & over. I was able to download the firmware and flash it using the method above. I didn't have to change any of the commands, it simply worked out of the box for me. I went with the direct connection to my laptop option as that seemed easier than messing with my router.
One thing I did notice is that after flashing the firmware the camera still would reboot over & over listening for the update over the network even after it had updated the first time. I saw another user had the same issue so what I did was watch the lights on my network switch and "caught" the camera in-between a reboot. When the lights went down I unplugged the camera and stopped the update server/script on my laptop. I then plugged the camera back in and voila it initialized normally doing its calibration spin. After then I could log into the normal web UI.
I was out of warranty so thanks again for helping save this thing!
It had firmware V20.1.23.6.5 or something.
It did not have "Humanoid alarm" option and I tried to put a different firmware. I renamed the file to be similar to V20.1.23.6..... aaaand...bricked it.
After searching the internet I ended up on this forum and managed to get to UART serial port.
I managed to setup TFTP server and I can get files through tftpboot, but not sure what to do with them.
Here is what I have (U boot pass: HI2105CHIP) reset:
"
System startup
Relocation Offset is: 0375e000
Relocating to 43f5e000, new gd at 43f1def0, sp at 43f1ded0
SPI Nor: Check Flash Memory Controller v100 ... Found
SPI Nor ID Table Version 1.0
SPI Nor(cs 0) ID: 0x20 0x70 0x17
Block:64KB Chip:8MB Name:"XM25QH64AHIG"
SPI Nor total size: 8MB
NAND: 0 MiB
In: serial
Out: serial
Err: serial
Net: eth0
Hit any key to stop autoboot: 0
device 0 offset 0x40000, size 0x1a0000
SF: 1703936 bytes @ 0x40000 Read: OK
Wrong Image Format for bootm command
ERROR: can't get kernel image!
### Please input uboot password: ###
" printenv:
As far as I can figure out, the Linux does not boot for some reason.
How can I get a working firmware and install it back on the "brick"?
I would need steps "translated" for dummies, please!
Please Help. when sending the commands it writes but then it restarts
XVR4116HS-S2
Used: SecureCRT
TFTP32
hisilicon # run da
ETH0: PHY(phyaddr=0, rmii) link UP: DUPLEX=FULL : SPEED=100M
MAC: 14-A7-8B-18-A5-98 TFTP from server 192.168.254.254; our IP address is 192.168.254.108
Download Filename 'u-boot.bin.img'.
Download to address: 0x82000000
Downloading: #################################################
done
Bytes transferred = 312108 (4c32c hex)
close frondboard!
Header CRC Checking ... OK
Data CRC Checking ... OK
Image Name: hi3521Aboot
Image Type: ARM Linux Standalone Program (gzip compressed)
Data Size: 312044 Bytes = 304.7 KiB
Load Address: a0000000
Entry Point: a0050000
img_addr 0x82000000 write to: 0xa0000000
write : 100%
done
connect frondboard!
resetting ...
hisilicon # run up
ETH0: PHY(phyaddr=0, rmii) link UP: DUPLEX=FULL : SPEED=100M
MAC: 14-A7-8B-18-A5-98
TFTP from server 192.168.254.254; our IP address is 192.168.254.108
Download Filename 'update.img'.
Download to address: 0x82000000
Downloading: #################################################
done
Bytes transferred = 14512448 (dd7140 hex)
close frondboard!
Header CRC Checking ... OK
Data CRC Checking ... OK
Image Name: linux
Image Type: ARM Linux Standalone Program (gzip compressed)
Data Size: 4096 Bytes = 4 KiB
Load Address: a0f40000
Entry Point: a0f60000
img_addr 0x82000040 write to: 0xa0f40000
write : 100%
done
Header CRC Checking ... OK
Data CRC Checking ... OK
Image Name: hi3521Aromfs
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 12816384 Bytes = 12.2 MiB
Load Address: a0060000
Entry Point: a0da0000
img_addr 0x82001080 write to: 0xa0060000
write : 100%
done
Header CRC Checking ... OK
Data CRC Checking ... OK
Image Name: linux
Image Type: ARM Linux Standalone Program (gzip compressed)
Data Size: 12288 Bytes = 12 KiB
Load Address: a0f60000
Entry Point: a0f80000
img_addr 0x82c3a0c0 write to: 0xa0f60000
write : 100%
done
Header CRC Checking ... OK
Data CRC Checking ... OK
Image Name: linux
Image Type: ARM Linux Standalone Program (gzip compressed)
Data Size: 1679360 Bytes = 1.6 MiB
Load Address: a0da0000
Entry Point: a0f40000
img_addr 0x82c3d100 write to: 0xa0da0000
write : 100%
done
connect frondboard!
resetting ...
TFTP from server 192.168.254.254; our IP address is 192.168.1.108; sending through gateway 192.168.1.1
Download Filename 'ID_3M03803PBQKJB9Q.txt'.
Download to address: 0x82000000
Downloading: T T T
Retry count exceeded; starting again
After trying to update my Dahua VTO2000a via ConfigTool on General_VTOXXX-data_EngDthFrnGerItlPorSpa_P_16M_SIP_PART_V4.300.0000001.0.R.20190322.bin firmware, my VTO is bricked ! I think I have the wrong firmware.
Cannot find the VTO on the network.
I tried to unbrick it with the TFTP procedure.
My VTO and PC are connected to the POE Dahua switch.
My PC's network configuration is as follows :
I connect the VTO2000a to the switch. I am doing a network analysis with Wireshark :
The VTO responds well ! I disconnect it from the network.
I downloaded and unzipped the " Dahua_TFTPBackup " application on my PC :
I unzipped (7zip) the firmware " General_VTOXXX_Eng_P_16M_SIP_V4.300.0000000.1.R.20190305.bin " in the " root " directory :
Except that the " Install " file is wrong :
Q1 : normal ?
Then I modified the " commands.txt " file :
I run " Commands.bat " which generates me " upgrade_info_7db780a713a4.txt " :
Then run the batch script " Console.bat " and " TFTPServer.bat " :
I connect the VTO2000a to the switch POE Dahua.
I am doing a network analysis with Wireshark. The VTO downloads the files :
At the level of the application " Sahua_TFTPBackup " I have this :
Q2 : normal ?
The process runs in a loop :
As some suggested, I created a file in " root\failed.txt ".
Same thing, it turns in a loop :
I restarted the VTO2000a after downloading the firmware.
I stopped " Dahua_TFTPBackup " and connected the VTO on the switch POE Dahua.
But unfortunately the VTO is still looking for a TFTP server :
Some firmware need the tftp line to be 0x0800000 or 0x02000000 instead of 0x82000000 depending on the size of the RAM on the device, I don't think it's an issue due to the upgrade failing after Web-X being served instead of the PD and DC. I suspect either you still have the wrong firmware or a too modern firmware, Dahua on a number of devices have changed the partition table at some point in the firmware cycle to make some (notably Web and Kernel) partitions bigger this works during a web GUI upgrade as it resizes and aligns the partition table but I was never able to get the TFTP to accomplish it which results in the firmware failing due to the write being bigger then the partition.
I would suggest that you try to find a copy (or as close to it) of the version that was already on the camera, if you flashed the wrong firmware and it changed the partition layout I'm unsure how you would be able to recover that and you might need to resort to connecting with a Serial connection using RS232.
It is also normal that the process loops as the cameral will contact the TFTP server each boot and if it connects will execute the magic file, succeed or failure it will reboot after executing and if the TFTP is still active rerun (you need to stop the TFTP server if you see the request for a success.txt file)
Certains micrologiciels ont besoin que la ligne tftp soit 0x0800000 ou 0x02000000 au lieu de 0x82000000 en fonction de la taille de la RAM sur l'appareil, je ne pense pas que ce soit un problème en raison de l'échec de la mise à niveau après que Web-X ait été servi au lieu du PD et du DC . Je soupçonne que vous avez toujours le mauvais firmware ou un firmware trop moderne, Dahua sur un certain nombre d'appareils a modifié la table de partition à un moment donné du cycle du firmware pour agrandir certaines partitions (notamment Web et Kernel), cela fonctionne pendant une interface graphique Web mise à niveau au fur et à mesure qu'il redimensionne et aligne la table de partition, mais je n'ai jamais pu obtenir le TFTP pour l'accomplir, ce qui entraîne l'échec du micrologiciel en raison de l'écriture plus grande que la partition.
Je vous suggère d'essayer de trouver une copie (ou aussi proche de celle-ci) de la version qui était déjà sur l'appareil photo, si vous avez flashé le mauvais firmware et que cela a changé la disposition de la partition, je ne sais pas comment vous pourriez récupérer cela et vous devrez peut-être recourir à une connexion série via RS232.
Il est également normal que le processus se boucle car la caméra contacte le serveur TFTP à chaque démarrage et s'il se connecte, il exécutera le fichier magique, réussira ou échouera, il redémarrera après l'exécution et si le TFTP est toujours actif, relancez (vous devez arrêter le serveur TFTP si vous voyez la demande d'un fichier success.txt)
A l'origine, mon VOT200a était en version 3.100.0
J'ai essayé avec le firmware General_Multi3_VTO2000A_EngItlFreGetDutSpaPor_P_16M_V3.200.0000.0.R.20190221.bin :
J'ai modifié le fichier "commandes.txt":
Voici le résultat :
mais :
mon VTO n'a toujours pas d'IP visible dans "ConfigTool".
Success.txt means that it worked, if it's still not accessible then something else might have gone on as I also am not sure why the "Read Request, File: failed.txt" exists if it succeeded?
Would suggest to ensure you shut down the TFTP as soon as the success.txt appears, also try to change the 0x82000000 to 0x02000000 and see if that does anything, you can also create a success.txt file with a simple "it works" inside it, sometimes the camera actually wants the file to be served for it to commit the flash.
Thank you both 
