VTO2111D-WP bricked, won't recover

B

bobfather

Getting the hang of it
Jan 17, 2017
102
25
Hello all,

My VTO2111D-WP bricked during a firmware update and won't come back. It can't be seen by ConfigTool on port 3800, nor is port 23 or any other port accessible. It won't even respond to pings.

Here are the steps I have taken to try and fix it:

1. Followed all instructions in the Dahua IPC EASY unbricking / recovery over TFTP thread. The camera can see the TFTP files and tries to load them

2. For the firmware to reflash, I am using the Dahua Wiki firmware located here.

One problem - when using the standard commands for commands.txt, which are:

run dr
run dk
run du
run dw
run dp
run dc

The process fails before flashing all the files with the following output:

Client 192.168.1.108:1951 root\upgrade_info_7db780a713a4.txt, 1 Blocks Served
Client 192.168.1.108:1974 root\romfs-x.cramfs.img, 2118 Blocks Served
Client 192.168.1.108:1978 root\kernel-x.cramfs.img, 1207 Blocks Served
Client 192.168.1.108:3756 root\user-x.cramfs.img, 4496 Blocks Served
Client 192.168.1.108:1051 root\web-x.cramfs.img, 960 Blocks Served
Client 192.168.1.108:2470 root\failed.txt, 1 Blocks Served

If instead I specify writing each individual file like so:

tftp 0x82000000 romfs-x.cramfs.img; flwrite
tftp 0x82000000 kernel-x.cramfs.img; flwrite
tftp 0x82000000 user-x.cramfs.img; flwrite
tftp 0x82000000 web-x.cramfs.img; flwrite
tftp 0x82000000 pd-x.cramfs.img; flwrite
tftp 0x82000000 custom-x.cramfs.img; flwrite
tftp 0x82000000 .FLASHING_DONE_STOP_TFTP_NOW
sleep 5

I am successful with the following output:

Client 192.168.1.108:2077 root\upgrade_info_7db780a713a4.txt, 1 Blocks Served
Client 192.168.1.108:2099 root\romfs-x.cramfs.img, 2118 Blocks Served
Client 192.168.1.108:2651 root\kernel-x.cramfs.img, 1207 Blocks Served
Client 192.168.1.108:1359 root\user-x.cramfs.img, 4496 Blocks Served
Client 192.168.1.108:1801 root\web-x.cramfs.img, 960 Blocks Served
Client 192.168.1.108:3235 root\pd-x.cramfs.img, 31 Blocks Served
Client 192.168.1.108:3307 root\custom-x.cramfs.img, 9 Blocks Served
Client 192.168.1.108:3348 root\.FLASHING_DONE_STOP_TFTP_NOW, 1 Blocks Served
Client 192.168.1.108:2217 root\success.txt, 1 Blocks Served

However, the camera does not boot, can't be pinged, and isn't accessible via telnet or ConfigTool @ port 3800.

Does anyone have any words of wisdom for me here? Is this a typical error when trying to flash a hacked Chinese cam with an English firmware? If so, does anyone know where to get the chinese firmware for this camera?
 
run the following commands in your commands.txt instead of what you were doing:
partition
printenv

post the output.
 
tangent said:
run the following commands in your commands.txt instead of what you were doing:
partition
printenv

post the output.
Click to expand...

Thank you very much for helping me troubleshoot.

When I run Console.bat, the window never populates with anything except for this:

Ncat: Version 7.40 ( Ncat - Netcat for the 21st Century )
Ncat: Listening on 192.168.254.254:5002

I think I read that in some firmwares the bootloader isn't verbose. I have double checked and made sure that 5002 UDP is allowed to pass traffic in the firewall.

I'm guessing that troubleshooting this without being able to see the output of printenv will be tough?
 
bobfather said:
Thank you very much for helping me troubleshoot.

When I run Console.bat, the window never populates with anything except for this:

Ncat: Version 7.40 ( Ncat - Netcat for the 21st Century )
Ncat: Listening on 192.168.254.254:5002

I think I read that in some firmwares the bootloader isn't verbose. I have double checked and made sure that 5002 UDP is allowed to pass traffic in the firewall.

I'm guessing that troubleshooting this without being able to see the output of printenv will be tough?
Click to expand...
You'll need to get a TTL serial adapter (this means 3.3-5v output not RS-232) and connect to the on board serial port.
 
Last edited:
bobfather said:
tftp 0x82000000 romfs-x.cramfs.img; flwrite
tftp 0x82000000 kernel-x.cramfs.img; flwrite
tftp 0x82000000 user-x.cramfs.img; flwrite
tftp 0x82000000 web-x.cramfs.img; flwrite
tftp 0x82000000 pd-x.cramfs.img; flwrite
tftp 0x82000000 custom-x.cramfs.img; flwrite
tftp 0x82000000 .FLASHING_DONE_STOP_TFTP_NOW
Click to expand...
I'm not sure those commands are doing what you want.

What makes you think you might have a china region product? Where'd you buy it from?
What firmware were you trying to load when you bricked it and where was it from?

Have you tried holding the reset button when power is applied for about 3 minutes?
 
Last edited:
  • Like
Reactions: bobfather
I bought it on Ebay back in December from a seller based in China, which is why I thought the cam might be China firmware hacked to English.

I flashed the firmware through ConfigTool v3 from the Dahua Wiki. It did not give any errors while flashing, and it completed successfully and gave the appropriate restart message when it reached 100%.

The specific firmware I flashed was this one, dated 2017-08-03. I thought it might fix some issues that the 2017-04-14 firmware has with image corruption after a few days.

I will reflash using all of the typical commands that work (basically run dr run dk run du run dw) and then try holding reset for 3 minutes.
 
Also, one thing I've noticed is that the bootloader on the firmware I linked above (2017-08-03) is DEFINITELY different than the official 2017-04-14 from Dahua Wiki. Could it be that the bootloader is incompatible with the lower firmware which is preventing the cam from starting?

I have not seen anyone describe the proper command to try flashing a new bootloader, but I'd be willing to try it!
 
alastairstevenson said:
Is there a run da for the bootloader?
Do you have access to the serial console for a printenv?
Click to expand...

I don't have a serial cable, but I'd be open to buying one since I see they're like $10 on Amazon for a CP2102.

Are you asking if I have tried using "run da" to load the bootloader? I have not done this (mostly because everyone says "don't flash the bootloader unless you REALLY NEED TO"). Is "run da" the appropriate command? I'm guessing I'll need to have the file "dm365_ubl_boot_16M.bin" in the /root directory for this to flash correctly?
 
bobfather said:
"don't flash the bootloader unless you REALLY NEED TO").
Click to expand...
I think that's generally good advice. Trash the bootloader and recovery is much harder.
But that's what I ended up doing to finally fix up a part-bricked Dahua 5208 NVR - though it turned out that reflashing the bootloader didn't so much fix a problem with the bootloader as reset all the environment variables to defaults, which fixed up one that was missing and would only have been found by a value-by-value comparison with a working same model.

The first step though would be to inspect the serial console log to see the nature of the problem.
 
Ok, here is what I've just done:

Ran the following commands using the official firmware from Dahua Wiki:

run dr
run dk
run du
run dw
tftp 0x82000000 pd-x.cramfs.img; flwrite
run dc

With all successful writes and success.txt as the output.

Notice I did not run "run dp", because that command explicitly fails on this camera.

I then powered the camera off, powered it on and waited 5 seconds, then held down the reset button for 3 minutes as recommended above. I unplugged and replugged the camera again and it is the same status as before.

I have had 100% success with flashing files using all of the run commands except for "run dp", so I am now considering running "run da" to try flashing the bootloader from the older firmware.

Edit: Throwing caution to the wind, I successfuly ran these commands:

run da
tftp 0x82000000 .FLASHING_DONE_STOP_TFTP_NOW
sleep 5

All successful output. Unplugged and replugged camera to see if it will come back.
 
Last edited:
Ok, flashed the bootloader and it flashed fine - camera isn't dead.

But, after having run all of these commands successfully with valid firmware, camera still doesn't boot :(

run da
run dr
run dk
run du
run dw
run dc

I still have not figured out how to successfully run "run dp". I thought perhaps the following command "tftp 0x82000000 pd-x.cramfs.img; flwrite" would accomplish the same effect, but even though that command completes with success still no boot.

I'm guessing the only way forward is via a serial connection to get console output? Anyone have any other ideas to resurrect this thing?

Edit: unfortunately, I appear to be in almost exactly the same boat as this fellow
 
bobfather said:
I'm guessing the only way forward is via a serial connection to get console output? Anyone have any other ideas to resurrect this thing?

Edit: unfortunately, I appear to be in almost exactly the same boat as this fellow
Click to expand...
You really need to get a serial adapter. I understand wanting to fix it, but some of the things you've done at this point could make fixing it more difficult.

Your problem is different from neketom22's.
 
Last edited:
bobfather said:
It can't be seen by ConfigTool
Click to expand...
Dahua has a special config tool just for the VTO and VTH units called VDPConfig. You can acquire it via the Dahua Toolbox, but you'll have to register for an account or you may be able to find a copy of VDPConfig.zip somewhere.

Why don't you see if it can detect the VTO and try flashing with it.
 
Last edited:
in my mind if it not reply to ping you dont have possibility to reboot.
in fact recovery tftp doesnt work with VTO, you must dont loose your time and return to your seller
 
Dear @bobfather
I Just ran into a similar situation.. turns out for the VTO units, the list of files to flash is slightly different: I succesfully un-bricked my VTO after doing the following:

setenv serverip 192.168.1.99

(if you have access to the serial console, use this command to avoid the whole static route / dual ip configuration on your PC).. just modify the OpenTFTPServerMT.ini file to listen on your IP instead on 192.168.254.254, otherwise, ignore the command and proceed ad usual


run dr
run dk
run du
run dw
run dd
run dc
tftp 0x82000000 pd-x.cramfs.img; flwrite
tftp 0x82000000 .FLASHING_DONE_STOP_TFTP_NOW

You don't need to use the "run dp" step, as it uploads part of the firmware needed for the cameras but not for the VTOs, but the missing piece was the "run dd" command which is the follwing:

dd=tftp 81a00000 data-x.cramfs.img; flwrite

Meaning in your case, the data partition was missing.. creating some trouble.

the other interesting finding is that you can use the TFTP method to upgrade / downgrade to unsigned firmwares, which allows us to have some custom fw with shell access, etc.. I still haven't come around to messing with it but I managed to upgrade my VTO2111D-WP to version 3.200 which was not signed.
 
  • Like
Reactions: catcamstar
Hi Diego,
I'm trying to upgrade my VTO2111D from v2.2 to 3.12 or 3.3 (with SIP) but I don't seem to be able to get the connection going.
I'm using Mac and Windows is running in VM. Tried running tftp server on both OSs and no luck.
Connection is direct using ethernet cable.

What am I missing?
 
Go88cE said:
Hi Diego,
I'm trying to upgrade my VTO2111D from v2.2 to 3.12 or 3.3 (with SIP) but I don't seem to be able to get the connection going.
I'm using Mac and Windows is running in VM. Tried running tftp server on both OSs and no luck.
Connection is direct using ethernet cable.

What am I missing?
Click to expand...
Did you do the static route /dual IP thing? You should run wireshark to see if you see any TFTP attempts from the camera. I wouldnt do the test inside the VM since in most cases the VM runs in NAT mode and thus you won't be able to run the TFTP server inside.
 
Hello, I have the same problem with my VTO (bricked after firmware update).

I made all the double routing config and updated the commands TXT file as described above, but when I run the TFTP server and Console, I get the following messages in the last line of the respective window, and thats it:

-TFTP Server: "Listening On:192.168.254.254:69
- Config: "Listening on 192.168.254.254:5002"

Can you please help me solving this issue?
Thanks
 
Hello, if up to that point the configuration is correct. By UART console you can see the advance process of installing the firmware...
Keep in mind the configuration steps of the network in the following link: https://ipcamtalk.com/threads/dahua-ipc-easy-unbricking-recovery-over-tftp.17189.

Annotations
- When the connection is established, the console remains active in listening for communication until the device is restarted.
- It is imperative to find the correct firmware with the correct files to obtain a successful output in the UART console
- In the console it is possible to see the operation associated with the command list when executing the instruction: printenv.
Attached file session.
 
Last edited:
You must log in or register to reply here.
Top Bottom