DS-2CD2142FWD-I bricked itself, can't get it unbricked

[rosenqui]

I've got 4 DS-2CD2142FWD-I dome cameras that I bought from an eBay vendor. As far as I know, they're all the North American version. They were sold as "Original English Hikvision DS-2CD2142FWD-I 4MP Full HD Dome Network Camera".

I connected all 4 of them when I first got them and configured them for DHCP. Then I put 3 of them back in their boxes (awaiting warmer weather for outdoor installation) and installed one in the basement.

Sometime after March 24th, the basement camera bricked itself. I don't recall if automatic firmware updates were enabled, but that seems to be the most likely culprit. It doesn't show up in the SADP tool and a Wireshark capture reveals it trying to do TFTP after startup, then nothing other than some IPV6 discovery traffic.

I've tried reflashing firmware 5.4.5_170124 (what it shipped with according to the box sticker) as well as 5.5.0_170725. In either case, the TFTP tool completes the transfer, then gives the "success" messages a few seconds later. I quit the TFTP tool and wait, but nothing happens (I've got wireshark capturing everything from the camera's MAC address). It still doesn't show up in SADP and I can't ping it. A power cycle doesn't solve anything - it just goes back to trying the TFTP.

I tried a hard reset (holding down the button on the circuit board) while powering up, but that didn't make any difference either.

Any suggestions? Is there a specific firmware version I should try?

I'd like to get to the bottom of this before installing the other 3 cameras.

 

[alastairstevenson]

I don't recall if automatic firmware updates were enabled, but that seems to be the most likely culprit.

I don't believe there is any such feature.
It's more likely to have been messed with from the internet if UPnP is enabled on your router.
With UPnP enabled by default on the camera, it will open multiple ports on the router and allow the entire internet to access it.
With the 'Hikvision backdoor' in most firmware before 5.4.5, anything is possible.

In either case, the TFTP tool completes the transfer, then gives the "success" messages a few seconds later.

If 'success' isn't just 'file transfer completed' but also 'system update completed' you're probably going to have to look in more detail for the root cause of the problem, and to see if it's fixable.

Suggestion, as you do seem to be comfortable with some techy stuff :
Gather the needed parts to access the serial console.
A serial TTL to USB convertor. The PL2303HX based versions sold in large numbers for Arduino etc work well.
A wired 4-pin 1.5mm JST ZH connector, widely available on eBay, usually sold in 10-packs.

 

[rosenqui]

Thanks for the suggestions.

UPnP is disabled on my router and I disabled UPnP on the camera when I set it up, plus the camera was running 5.4.5_170124 which was supposed to have the backdoor fix in place.

As for the TFTP, I would always get the "Completed file..." and then a few seconds later the "System update completed" message. The latter seemed to correspond to the TFTP server receiving another UDP packet on port 9989.

I'm powering the camera using PoE from my switch. Hopefully that's not an issue or I'll have to search my junk drawer for a 12V power supply with the correct plug.

Interestingly, when I fire up one of the other 3 cameras that have been sitting in their boxes, they do an initial ARP request using the 192.168.0.* subnet:

Broadcast ARP 60 Who has 192.0.0.128? Tell 192.0.0.64​

After about 30 seconds they give up and do a DHCP handshake since that's what I configured them to use.

The bricked camera is on 191.168.1.*, and 192.168.1.64 is the default IP as per the sticker on the box and was what the camera was using (reported by the SADP tool) when I first fired up all 4 of them.

Does the camera get tripped up by other LAN traffic during the TFTP firmware process, i.e., do I need to play around with port isolation and other switch settings to get the TFTP firmware update to take? If I have to resort to ordering a USB->TTL device and accessing the serial port we're talking another whole afternoon wasted on the unbricking. At some point I'll be better off just buying a new camera rather than sinking several more hours into this one.

My main concern is making sure this doesn't happen to the other 3 cameras once they go live since they'll be outdoors and much more troublesome to access physically.

Any other suggestions? Specific firmware versions to try etc?

 

[alastairstevenson]

UPnP is disabled on my router and I disabled UPnP on the camera when I set it up, plus the camera was running 5.4.5_170124 which was supposed to have the backdoor fix in place.

OK, on both counts that blows my thought on the potential cause out of the water.
Though there has been a lot of that type of activity going on.

and then a few seconds later the "System update completed"

That seems unusually short, though I do have limited experience with R6 cameras.
It transfers the file, validates it, then if OK writes almost the entire flash memory, then indicates update completed.
I'm assuming here that triggering the 'downgrade block' doesn't erroneously signal the TFTP updater that the update was successful.

Interestingly, when I fire up one of the other 3 cameras that have been sitting in their boxes, they do an initial ARP request using the 192.168.0.* subnet:
Broadcast ARP 60 Who has 192.0.0.128? Tell 192.0.0.64

That's normal, part of the TFTP probe/handshake process.

The bricked camera is on 191.168.1.*, and 192.168.1.64 is the default IP as per the sticker on the box and was what the camera was using (reported by the SADP tool) when I first fired up all 4 of them.

Yes, that's the default IP address as used by the 5.4.5 firmware.

Does the camera get tripped up by other LAN traffic during the TFTP firmware process, i.e., do I need to play around with port isolation and other switch settings to get the TFTP firmware update to take?

I don't believe so. A slight risk is if other Hikvision devices are power-cycled or rebooted and find the TFTP server and react to it.

Specific firmware versions to try etc?

With the downgrade block that was introduced in 5.4.0, you can only go the same or upwards after 5.4.5 or 5.5.0 has been attempted.
Without seeing what the serial console shows I'm not sure what else to suggest.