Bricked DS-2CD2342WD-I TFTP Firmware loads ok but still bricked

[slingy_]

I bought a second hand DS-2CD2342WD-I that appears to be bricked (and I've learnt my lesson about buying second hand cameras without testing them first! - I was unaware of the problems these cameras can have).

- The first thing I did was run SADP with the camera plugged into a POE switch on my network, but I couldn't see it. The red IR light is on, so it looks like power is working.

- I then attempted with it plugged directly into my PC with the external power plugged in. Still no luck with SADP.

- Running Wireshark I can see ARP request from a Hikvision device on 192.0.0.64 looking for 192.0.0.128. I also see some IMCPv6 router/neighbour discovery requests that appear to be coming from the camera, but I don't run IPv6. I occasionally see 192.0.0.64 appear in the arp table, and sometime it responds to a few pings before disappearing again.

- I have run the Hikvision TFTP tool and the wendelltron/scottlamb hikvision-tftpd Python tool to attempt Firmware (re)loading. All the tools seem to work correctly but the camera's behaviour doesn't change, it still just does arp requests and I can't see it in SADP. I have tried various versions of the firmware, including the original one that it was shipped with (according to the box it's SV: V5.4.5_170124 )



I think success would look like the device booting up and setting itself to it's proper factory default IP address of 192.168.1.64 and appearing in SADP.
Any ideas on where I go from here?

 

[Revo2Maxx]

I would double check the Ethernet Transformer in the camera. This is going to be a multi pin little black box. There are different ones so I don't know what one they used in that camera. If that is bad the camera could power one but would never get any data.. Power on would be caused by using the second part of the power device.. If you have a cable that is setup with 1, 2, 3 and 6 pins and if you were to plug this cable into the camera if it don't power on. Then camera would dead! Because of the Ethernet Transformer, Then camera would only power on by 12v but still will be no data because the Ethernet Transformer is dead.. If it still powers on then transformer is good and would need to look at the ethernet circuit. Would need some board level tech ability and or have some handy tech tools for repairing these cameras.. Main issue with trying to repair these is getting to the testing pins on the chips because they are so small in package design that it can be a tough troubleshooting.. But with the right tools it can be done. Once you know if it is Ethernet Chip or the Power Circuit for the Ethernet chip then being able to find the replacement is going to be the hardest part.. I am still using my PTZ AI camera with 12v because my POE chip died and I can't find out what the Chip is to source the replacement.. The Manufacture in my case Uniview don't want to provide any Schematics so someone can have an easier time making repairs and kind of sad to be honest when the camera is less then 4 years old and cost more then i would want to pay again so in my case I will just keep it on 12v..

 

[Revo2Maxx]

Here is a picture of PCB of a PTZ camera that needed repair, It is older picture but was one that I had of the Transformer on the PCB seeing I can't find any damaged ones. I thought I might have had a few laying around that I replaced but I guess they made it to the round file aka trash bin lol..

 

[slingy_]

I would double check the Ethernet Transformer in the camera. This is going to be a multi pin little black box. There are different ones so I don't know what one they used in that camera. If that is bad the camera could power one but would never get any data.. Power on would be caused by using the second part of the power device.. If you have a cable that is setup with 1, 2, 3 and 6 pins and if you were to plug this cable into the camera if it don't power on. Then camera would dead! Because of the Ethernet Transformer, Then camera would only power on by 12v but still will be no data because the Ethernet Transformer is dead.. If it still powers on then transformer is good and would need to look at the ethernet circuit. Would need some board level tech ability and or have some handy tech tools for repairing these cameras.. Main issue with trying to repair these is getting to the testing pins on the chips because they are so small in package design that it can be a tough troubleshooting.. But with the right tools it can be done. Once you know if it is Ethernet Chip or the Power Circuit for the Ethernet chip then being able to find the replacement is going to be the hardest part.. I am still using my PTZ AI camera with 12v because my POE chip died and I can't find out what the Chip is to source the replacement.. The Manufacture in my case Uniview don't want to provide any Schematics so someone can have an easier time making repairs and kind of sad to be honest when the camera is less then 4 years old and cost more then i would want to pay again so in my case I will just keep it on 12v..

Power works fine through POE and through the separate 12v input. I don't think power is the issue.
I also don't think there's any hardware network issue because I see the ARP requests and TFTP works. I also see the magic handshake packet over UDP

 

[Revo2Maxx]

Well that is the issue, At times the ethernet transformer can be just dead enough to not work.. Something to try if you have not already.. if the Transformer is going bad but still not 100% burnt out connect a known good 3 foot cable and see if the camera connects. If that lets the camera work so you can gain access to the WebUI and access the camera. Replace the Ethernet Transformer it is bad..

Edit: Keep in mind that even if a camera connects when you plug in a POE camera to POE NVR or POE Switch or Injector there are 2 ways that the camera can get powered on if you are using full 8 pin ethernet cable. If the camera don't power on using as I said before 1,2,3,6 pins it will take power from the last 4 pins by default.. The first 4 that I mentioned are for Power and Data and work using a Ethernet Transformer so even with one being bad it would get power from second set of that only powers don't offer any data..

 

[alastairstevenson]

Any ideas on where I go from here?

To get more information on why firmware updates don't bring the camera back to fully booting up, you could connect to the serial console.
Hikvision's cameras are pretty chatty on the console.

The camera will have a serial console connector that looks like this example :

Hikvision NVR DS-7804N-E1/4P Bricked

Hello, i have NVR DS-7804N-E1/4P bricked when i flash wrong firmware DS-7604NI for it. So now it only boot to Logo then bip bip and auto restart. I tried flash TFTP very many time by set IP of my PC to 192.0.0.128 / subnet 255.255.255.0 and turn firewall is off. But no thing flashable although i...

ipcamtalk.com

To connect to it you will need :
A USB to serial TTL adaptor such as a PL2303TA based device.
A wired 4-pin 1.5mm JST ZH connector, usually sold in 10-packs.

 

[alastairstevenson]

Power works fine through POE and through the separate 12v input. I don't think power is the issue.
I also don't think there's any hardware network issue because I see the ARP requests and TFTP works. I also see the magic handshake packet over UDP

Agreed.
You are observing network traffic, and the tftp updater is working OK.
The network is fine.

There is another reason the camera isn't fully booting, and the serial console output will likely show why.

 

[slingy_]

Here is a picture of PCB of a PTZ camera that needed repair, It is older picture but was one that I had of the Transformer on the PCB seeing I can't find any damaged ones. I thought I might have had a few laying around that I replaced but I guess they made it to the round file aka trash bin lol..

To get more information on why firmware updates don't bring the camera back to fully booting up, you could connect to the serial console.
Hikvision's cameras are pretty chatty on the console.

The camera will have a serial console connector that looks like this example :

Hikvision NVR DS-7804N-E1/4P Bricked

Hello, i have NVR DS-7804N-E1/4P bricked when i flash wrong firmware DS-7604NI for it. So now it only boot to Logo then bip bip and auto restart. I tried flash TFTP very many time by set IP of my PC to 192.0.0.128 / subnet 255.255.255.0 and turn firewall is off. But no thing flashable although i...

ipcamtalk.com

To connect to it you will need :
A USB to serial TTL adaptor such as a PL2303TA based device.
A wired 4-pin 1.5mm JST ZH connector, usually sold in 10-packs.

I have a USB -> TTL adaptor on its way from Amazon. Will just use normal jumpers, don't need the fancy connector ;-)

 

[slingy_]

Well, here's the boot logs..:
I can't seem to use ctrl+u to interrupt it either, but keyboard commands do make it through.
U-Boot 3.1.6-263038 (Mar 14 2017-10:20:15)
boards:261284
Boot From: NAND 2048 RC
SYS_CONFIG: 0x30064059 POC: 100
Cortex freq: 600000000
ENET freq: 50000000
iDSP freq: 216000000
Dram freq: 564000000
Core freq: 216000000
AHB freq: 108000000
APB freq: 54000000
UART freq: 24000000
SD freq: 50000000
SDIO freq: 50000000
SDXC freq: 60000000
dev_modelS-2CD2342WD-I
Hit Ctrl+u to stop autoboot: 0
▒[ OK ]
UBI device number 1, total 272 LEBs (34537472 bytes, 32.9 MiB), available 0 LEBs (0 bytes), LEB size 126976 bytes (124.0 KiB)
waiting for /dev/ubi1_0.
pri_iUpgSuccCnt:1, sec_iUpgSuccCnt:1
UBI device number 3, total 48 LEBs (6094848 bytes, 5.8 MiB), available 0 LEBs (0 bytes), LEB size 126976 bytes (124.0 KiB)
waiting for /dev/ubi3_0.
waiting for /dev/ubi3_0.
Check dir /davinci ok! (0)
UBI device number 4, total 48 LEBs (6094848 bytes, 5.8 MiB), available 0 LEBs (0 bytes), LEB size 126976 bytes (124.0 KiB)
waiting for /dev/ubi4_0.
waiting for /dev/ubi4_0.
Check dir /config ok! (0)
diagnose_way = 15, repair_way = 1, interval = 60
route: ioctl 0x890c failed: No such process
Default method to init without VIN drivers...
Cat this file to find out what VIN can be supported.
Default init without lens driver
Use default settings
/home/script/init.sh: line 553: which: not found
/
[ 23.612471] [ kernel version: svn-594950 ]
map_size = 0x400000, nr_item = 3
addr_offset = 0x00000000, filename = orccode.bin
addr_offset = 0x00300000, filename = orcme.bin
addr_offset = 0x003a0000, filename = default_binary.bin
mmap returns 0x76ad0000
loading /home/firmware/orccode.bin...addr = 0x76ad0000, size = 0x171cca
loading /home/firmware/orcme.bin...addr = 0x76dd0000, size = 0x51644
loading /home/firmware/default_binary.bin...addr = 0x76e70000, size = 0x40000
===============================================
ucode (S2L) version = 2017/5/25 271820.271498
===============================================
ln: prtLensCurve: File exists
ln: /dev/ttyS1: File exists
ln: /bin/t1: File exists
cp: can't stat '/dav/libutils.so': No such file or directory
chmod: /lib/libutils.so: No such file or directory
ln: /dev/rtc: File exists
=====check_config start=====
===db file doesn't exist===
===db file doesn't exist===
==== both config files are broken====
infd read End
Unix bus 0 .

Enter DB_main-------------------
shared memory address is: 0x76c11000, sizeof(DEVICECONFIG) = 1159944

netprocess Infomation:
version: 8.11.3 [14:45:39-Jun 22 2018]
Path: /Camera/Platform/Trunk/FSP_network_protocol
Last Changed Rev: 404021
Last Changed Date: 2018-06-22 14:14:20 +0800 (Fri, 22 Jun 2018)
.
wait davinci set default...
[01-01 00:14:44][pid:572][STRM_ANLS][ERROR]daemon can not find Dst process.load_type 0x10012 is_need_ack 1
[01-01 00:14:44][pid:579][STRM_ANLS][ERROR] from daemon ack, dst not work len 0 , load_type is [0x10012]
[01-01 00:14:44][pid:579][UNI_IF][ERROR]65554:ipc_unix_call_service failed, ret = -3.
[01-01 00:14:44][pid:579][UNI_IF][ERROR]communicaite_to_davinci failed!!!
copy default.cls ok.
[01-01 00:14:45][pid:572][STRM_ANLS][ERROR]daemon can not find Dst process.load_type 0x10012 is_need_ack 1
[01-01 00:14:45][pid:579][STRM_ANLS][ERROR] from daemon ack, dst not work len 0 , load_type is [0x10012]
[01-01 00:14:45][pid:579][UNI_IF][ERROR]65554:ipc_unix_call_service failed, ret = -3.
[01-01 00:14:45][pid:579][UNI_IF][ERROR]communicaite_to_davinci failed!!!
[01-01 00:14:46][pid:572][STRM_ANLS][ERROR]daemon can not find Dst process.load_type 0x10012 is_need_ack 1
[01-01 00:14:46][pid:579][STRM_ANLS][ERROR] from daemon ack, dst not work len 0 , load_type is [0x10012]
[01-01 00:14:46][pid:579][UNI_IF][ERROR]65554:ipc_unix_call_service failed, ret = -3.
[01-01 00:14:46][pid:579][UNI_IF][ERROR]communicaite_to_davinci failed!!!
Unix bus End
shared memory address is: 0x76943000, sizeof(DEV_CAPABILITY) = 464336
[01-01 00:14:46][pid:593][HW_IF][ERROR]ioctl error errno=5
[01-01 00:14:46][pid:593][SYSINIT][ERROR]hwif_getsecinfo failed.
[01-01 00:14:46][pid:593][SYSINIT][ERROR]sys app init failed to reboot!
[01-01 00:14:47][pid:572][STRM_ANLS][ERROR]daemon can not find Dst process.load_type 0x10012 is_need_ack 1
[01-01 00:14:47][pid:579][STRM_ANLS][ERROR] from daemon ack, dst not work len 0 , load_type is [0x10012]
[01-01 00:14:47][pid:579][UNI_IF][ERROR]65554:ipc_unix_call_service failed, ret = -3.
[01-01 00:14:47][pid:579][UNI_IF][ERROR]communicaite_to_davinci failed!!!
[01-01 00:14:48][pid:572][STRM_ANLS][ERROR]daemon can not find Dst process.load_type 0x10012 is_need_ack 1
[01-01 00:14:48][pid:579][STRM_ANLS][ERROR] from daemon ack, dst not work len 0 , load_type is [0x10012]
[01-01 00:14:48][pid:579][UNI_IF][ERROR]65554:ipc_unix_call_service failed, ret = -3.
[01-01 00:14:48][pid:579][UNI_IF][ERROR]communicaite_to_davinci failed!!!
[ 34.593130] Restarting system.

 

[Revo2Maxx]

Sorry I disagree the network isn't working from what your log file is stating.. route: ioctl 0x890c failed: No such process

If I had to guess if you were to take the camera module out and remove the 8 to 12 screws that holds the 2 halves together this is going to be very small screws and 2 to 4 that would be little larger to hold the Zoom lens into the case, Without having a system in place you would need to remove the whole system in both the head and the base to gain access to the Motor connectors. Then once you removed the PTZ motors from the main board you would be able to take the camera that is fully removed from the case that is holding the camera sensor board, Main camera board lens and connect it to the camera base. Give it power and my guess is the 2 little LEDs for network RX and TX will do one of a couple of things.. Either NOTHING.. or it will give a flash as it tries to start up. Once the board fails to turn on the Ethernet the camera fails and either removes power form the ethernet circuit and or it is dead already and that will be known because the leds will not flash at all. But if it does then there is either a dead Ethernet chip or there is something within the bootloader that is failing to setup the ethernet and causing the camera to boot cycle.. That is in your logs that you printed out here...

 

[Revo2Maxx]

This is from a Dahua OEM that I repaired Jan 2023 took picture of the module before being removed. I have a Test setup from a 25x PTZ camera that I then take the module apart and do the board level troubleshooting .. If you don't already have the ability to test this camera module once removed the only way is to remove the base from the head and remove the 2 motor wires from the PCB because the camera being open air and a spinning head and base only spells disaster lol.. Once it has been done before it is a chore that can be take apart in 30min.. Getting everything out and module apart for testing again if no testing rig setup already would require 1 hour..

 

[Revo2Maxx]

However seeing you already have your system apart, to access the comunication port you are already almost there and must have taking the wires off the Pan motor and have to take the wire off to access the base PCB so tilt wires is off.. But for others following that wants to access for repair Arrow points to the 2 Connector spot for Pan and Tilt motors.. Would need to remove both... Yes I know you are working with Hikvision but it would still be something of same type of setup as the Dahua lines..

 

[slingy_]

Sorry I disagree the network isn't working from what your log file is stating.. route: ioctl 0x890c failed: No such process

If I had to guess if you were to take the camera module out and remove the 8 to 12 screws that holds the 2 halves together this is going to be very small screws and 2 to 4 that would be little larger to hold the Zoom lens into the case, Without having a system in place you would need to remove the whole system in both the head and the base to gain access to the Motor connectors. Then once you removed the PTZ motors from the main board you would be able to take the camera that is fully removed from the case that is holding the camera sensor board, Main camera board lens and connect it to the camera base. Give it power and m is the 2 little LEDs for network RX and TX will do one of a couple of things.. Either NOTHING.. or it will give a flash as it tries to start up. Once the board fails to turn on the Ethernet the camera fails and either removes power form the ethernet circuit and or it is dead already and that will be known because the leds will not flash at all. But if it does then there is either a dead Ethernet chip or there is something within the bootloader that is failing to setup the ethernet and causing the camera to boot cycle.. That is in your logs that you printed out here...

I appreciate the time and effort you've put into your posts but they're not relevant.

Ethernet works fine.
I can't interrupt the boot with ctrl+u but I can see the tftp tool working (I didn't share the logs that included that).

"0 Available LEBs" is a worry, could indicate NAND flash corruption..

I think all the other errors stem from there. I'll have to work out how to test it.
I can't interrupt the boot process with ctrl+u, but i can get to the prompt after doing the tftp firmware upload, but for some reason 'enter' doesn't work.
Might try a different tool, could be a Putty problem.. I think ctrl+u is a Putty hotkey/shortcut.

 

[Revo2Maxx]

Ok sorry for the misunderstanding. I repaired camera same type issue thought after failing access of trying network connection that you were working through uart or jtag debug ports, for direct connection with processor. With connection If the damage is limited to the data-handling logic but the electrical connection is intact, low-level protocols like TFTP might work sporadically.
Good luck.

 

[alastairstevenson]

[01-01 00:14:46][pid:593][SYSINIT][ERROR]hwif_getsecinfo failed.
[01-01 00:14:46][pid:593][SYSINIT][ERROR]sys app init failed to reboot!

This I believe is the cause of the reboot - the device hardware descriptor block cannot be read.
This holds the device-specific data such as region, serial number, model variant, capabilities etc.
So that's a fatal error when that data is missing.

I'm trying to remember, but I'm not sure, if this is one of those models where Hikvision used a chip-and-PIN chip (EMV chip) to hold the so-called bootpara data in a secure and protected way.
It had turned out to be possible for the 'security researchers' to gain access to bootpara data held in flash segment and mess with it, like telling the camera it's not actually a CN region device, so an alternative method was developed.
If that's the case - it's a hardware fault that can't realistically be fixed - the chips have tamper protection.
It would explain why firmware updates don't bring the device back to life.

 

[alastairstevenson]

"0 Available LEBs" is a worry, could indicate NAND flash corruption..

That's a standard comment when UBIFS is used for the file system - not quite sure what it means, maybe all available are allocated for use.

Here is a sample serial console from a somewhat similar model - DS-2CD2142FWD-I showing the use of the 'card' and also the LEBs comment.

Hit Ctrl+u to stop autoboot: 0
|BIND err|
cmd 'null' is not supported.
nand booting ...
booting from pri part...
load kernel...
[    1.517710] Card authentication succeeded
init started: BusyBox v1.19.3 (2017-01-23 16:59:43 CST)
starting pid 45, tty '': '/etc/init.d/rcS'
Starting udev:      [ OK ]
UBI device number 1, total 272 LEBs (34537472 bytes, 32.9 MiB), available 0 LEBs (0 bytes), LEB size 126976 bytes (124.0 KiB)
waiting for /dev/ubi1_0.
waiting for /dev/ubi1_0.
pri_iUpgSuccCnt:1, sec_iUpgSuccCnt:1
UBI device number 3, total 48 LEBs (6094848 bytes, 5.8 MiB), available 0 LEBs (0 bytes), LEB size 126976 bytes (124.0 KiB)
waiting for /dev/ubi3_0.
waiting for /dev/ubi3_0.
Check dir /davinci ok! (0)
UBI device number 4, total 48 LEBs (6094848 bytes, 5.8 MiB), available 0 LEBs (0 bytes), LEB size 126976 bytes (124.0 KiB)
waiting for /dev/ubi4_0.
Check dir /config ok! (0)
diagnose_way = 15, repair_way = 1, interval = 60
route: ioctl 0x890c failed: No such process
cp: can't stat 'half_secinfo.dat': No such file or directory
Default method to init without VIN drivers...
Cat this file to find out what VIN can be supported.
Default init without lens driver
Use default settings
/home/script/init.sh: line 378: which: not found

 

[alastairstevenson]

I'm trying to remember, but I'm not sure, if this is one of those models where Hikvision used a chip-and-PIN chip (EMV chip) to hold the so-called bootpara data in a secure and protected way.

A similar problem -

Post in thread 'DS-2CD2142FWD-IS reboots'

Mar 13, 2023

[03-13 10:39:30][pid:593][HW_IF][ERROR]ioctl error errno=5
[03-13 10:39:30][pid:593][SYSINIT][ERROR]hwif_getsecinfo failed.
[03-13 10:39:30][pid:593][SYSINIT][ERROR]sys app init failed to reboot!

The routine that reads the device-specific info (devtype, serial number, language, sensor type etc etc) is failing to do so.
That's a fatal error, hence the re-start.
I think on that device the device data is encoded in a separate security chip.

• alastairstevenson

• 

 

[slingy_]

Yeah it's not looking good.. I'm doing a bit more reading.