Bricked DS-2CD3132F-IWS, what am I doing wrong?

[Exiler]

Hi All,

I have read through a lot of threads here trying to find a solution, but seems like nothing has worked so far.
Wondering if anyone can shed a light on what I am really doing wrong here.

Got the camera from a friend who bricked it. So no idea what the actual firmware was initially, but must have been 5.3.0 150513 as the back of the Camera has the sticker as that.
Also note the Sticker has 08/2015 date, no idea what that means.

Info (See screeenshot):



IP of camera is now 192.168.1.64 (which from the threads here it is in 'minimal mode'.



Got the HikTools and also checked the SADP

First setup:
All AV and Windows Firwall disabled.
Laptop wired (wifi disabled) and IPC connected to a switch
Using 12V Adapter for the camera as POE yielded the same results
Laptop IP: 192.0.0.128
IPC: 192.168.1.64

Transmission is always successful, but never get a success. Waited a good 5-10 minutes/3 hours.

Tried the following firmware and still no changes in SDAP when checked for firmware.
IPC_R0_CN_STD_5.3.0_150513
IPC_R0_EN_STD_5.3.0_150513
IPC_R2_EN_STD_5.3.0_150513
IPC_R3_EN_STD_5.3.0_150513
5.30 Downgrader to 5.2.5 multilanguage

Tried through HikTools Batch upgrader and always stuck in 0%

Next, since all did not work, decided on adding secondary IP to laptop of 192.168.1.128 this allows me to ping 192.168.1.64 for testing.

Here is what I found out:
When Camera rebooted initially, 192.0.0.64 is pingable during transmission through Hikvision TFTP.
After transmission is successful, the 192.0.0.64 is no longer pingable and 192.168.1.64 is pingable again.



Also, seems like TFTP never works if Laptop IP is 192.168.1.128 which I assume is that Hik TFTP needs to handshake it on a 192.0.0.128 IP.

Surprising this person was able to upload it with 192.168.1.128 IP
How to Fix a Bricked Hikvision IP Camera Firmware - HandymanHowto.com

So, any idea what I can possibly be doing wrong here?Read up on this user post also and cannot seem to get it work:
I did a boo boo to a sketchy DS-2CD3132-IW from amazon.

Also, I tried the reset on the device and seem like holding 10 seconds/20 seconds, never really resets it as I never see the LED lights ever go off here.

Another thing, after the transmission is done, I have tried, waiting over 20 minutes and also tried, after transmission is completed, close off the Hik TFTP software.

One other thing, 192.168.1.64 is pinable indefinitely after transmission is completed, if the firmware is successful, will it auto-reboot automatically? I know mine does not as still pinable.
Only time it is not pinable is after I pull the power off IPC.
FYI: No IP conflict here as I have tried with only Switch here

 

[Exiler]

Just realized looking at device serial number it is CCRR and not CN, hence it was Russian first and then got Multi-L.
Which firmware should I be getting?
First step is to get it working and then can flag it to English I guess.

 

[alastairstevenson]

The firmware version showing in SADP (4.0.8) suggests that the camera is running in 'min-system mode'.
This is a basic Linux kernel with no web services that's entered when the camera has been loaded with incompatible firmware.
On the IP addresses you've pinged - what you have described is normal for a bricked Hikvision camera.
The bootloader uses 192.0.0.64 just after power-on to probe for the tftp updater (it's not just a tftp server) on 192.0.0.128
If it doesn't find it, the camera changes IP address to the default 192.168.1.64 when booting into recovery mode.

From the serial number and manufacturing date you've quoted, I'd have expected that

5.30 Downgrader to 5.2.5 multilanguage

would work OK.
But there is one thing you have not mentioned that you may not have tried.
Changing the language of the firmware header with the Hiktools 'lang' option : Hikvision FIRMWARE TOOLS - change language, extract files and create own firmware
If that does not work - then the next step to figure out why it won't properly boot would be to attach a serial TTL to USB convertor to the on-board serial console and watch the kernel bootup messages for the cause. Quite a few posts on how to do this.

Just one more thing.
When it's stable on 192.168.1.64 after a file transmit with the tftp updater, see if you can establish a telnet session to the 192.168.1.64 IP address.
Some cameras 'min-system recovery mode' pause after transmission with telnetd and ftp active.
If so - use root/12345 and
cat /proc/kmsg
to grab a copy of the kernel log.

 

[Exiler]

Hi alastairstevenson,

Gave that a go. The 5.30 Downgrader to 5.2.5 multilanguage had a language of 2 (CN) changed it to 1 (EN/MUL).
Guess that did not work.

As for Telnet connection, yeah, did a lot of that while trying out each time and can see the Telnet port is still closed. (Refused)

I guess will go the TTL to USB converter route.

Thanks