R0 / DS-2CD2x32 BrickfixV2 brick recovery and full upgrade tool - enhanced.

when I try to 'update /digicap.dav' it just hangs. Left it running for about ten minute, nothing happens.
That's a bummer, and a bit odd.
If the tftp client that's used by the update command can't connect, there is usually a timeout and the camera is left running the min-system kernel.
Did the tftp updater show 'initialised at 192.0.0.128' in the status window?
Does the switch/router link detect light show active?
Can you ping the camera at 192.0.0.64 ?

Don't know where to go to from here.
Where are you based?
 
Does it work with any tftp server to upload digicap.dav file to cameras when they boot?
Or does it have to be the one from Hikvision?
For the built-in probe for the tftp updater on power-up, it must be the Hikvision tftp updater tool.
The device and the tftp updater tool conduct a Hikvision-specific handshake as part of the process.

If you were operating at the command line with the serial console or a telnet session, it's possible to use a normal tftp server to transfer files in and out.
This is how the brickfixV2 method works, as the Hikvision tftp updater will only transfer in, not transfer out.
 
That's a bummer, and a bit odd.
If the tftp client that's used by the update command can't connect, there is usually a timeout and the camera is left running the min-system kernel.
Did the tftp updater show 'initialised at 192.0.0.128' in the status window?
Does the switch/router link detect light show active?
Can you ping the camera at 192.0.0.64 ?


Where are you based?

I used the Hikvision tftp server and it did show initialised at 192.0.0.128 buts that all. Nothing else happended.

Didn't appear to be any activity on switch connecting them. Haven't tried to ping the camera. Will try again.

Unfortunately I am half a world away from you in Australia.
 
For the built-in probe for the tftp updater on power-up, it must be the Hikvision tftp updater tool.
The device and the tftp updater tool conduct a Hikvision-specific handshake as part of the process.

If you were operating at the command line with the serial console or a telnet session, it's possible to use a normal tftp server to transfer files in and out.
This is how the brickfixV2 method works, as the Hikvision tftp updater will only transfer in, not transfer out.

So there is no way of using a linux OS for this procedure, one must run tftpserver.exe in a windows environment first?

Kind Regards
ehsab
 
So there is no way of using a linux OS for this procedure, one must run tftpserver.exe in a windows environment first?
There is a Python-based tftp updater on Github - some forum members have used it successfully.
If the camera is not bricked, and the web GUI is available, the brickfixv2EN.dav (or brickfixv2CN.dav) could be applied under a Linux browser - as far as I recall the webcomponents plugin isn't needed for that, though I'm not 100% sure.
And a Mac user recently posted about using a curl command to trigger the initial update.

After which the Linux telnet works OK to run the fixup script.
 
I used the Hikvision tftp server and it did show initialised at 192.0.0.128 buts that all. Nothing else happended.

Didn't appear to be any activity on switch connecting them. Haven't tried to ping the camera. Will try again.

Unfortunately I am half a world away from you in Australia.

Where in Australia are you? I'm here and just did five cams yesterday ;)

The Hik tftpserv will not proceed until you power cycle a camera that is on the same network. Note it must be a true power cycle and not just a reboot from web GUI. So that means unplug it and plug it back in. It must be on the same network as your PC, so if you set PC to 192.0.0.x then the camera must be 192.0.0.y

With tftpserv running, it will detect a camera start-up on your network and commence all of that fancy communication.

Use SADP to find the IP of the camera and change your PC to the same network.
 
Where in Australia are you? I'm here and just did five cams yesterday ;)

The Hik tftpserv will not proceed until you power cycle a camera that is on the same network. Note it must be a true power cycle and not just a reboot from web GUI. So that means unplug it and plug it back in. It must be on the same network as your PC, so if you set PC to 192.0.0.x then the camera must be 192.0.0.y

With tftpserv running, it will detect a camera start-up on your network and commence all of that fancy communication.

Use SADP to find the IP of the camera and change your PC to the same network.

Thanks for the reply but I have done all of that. I am in Sydney (Parramatta).

This camera is one of twelve I have done the hack on, just this one didn't like it (it was the only one with v5.3 firmware) and is well and truly bricked. If its recoverable at all, it will only be via serial console as that is all that works at the moment. Doesn't show up on SADP and TFTP doesn't work with it. It connects but says "test tftp" only and nothing else happens. I have the computer and camera connected via switch both on the same IP range.

Any helpful suggestions appreciated.
 
t connects but says "test tftp" only and nothing else happens.
When using the Hikvision tftp updater tool, the actual transfer and validation and installation of the digicap.dav file is handled by the 'min-system recovery' kernel and associated programs. This is in its own flash partition, under control of the bootloader.
If you use the serial console 'update' command at the bootloader, or the power-on probe for the tftp updater gets a response, the min-system recovery kernel is booted and the 'upgrade' program is run.
I'm wondering if the 'min-system recovery' partition or contents is damaged or unavailable in some way.
Clearly, for the tftp updater to work, the min-system recovery environment must work.
If not - no updates via that method are possible.

I have recovered other model cameras in the past by tftp booting a uImage over the network - but I don't remember whether the R0 bootloader has that facility.
I still have a couple of 2332s kicking around - I could drag one out and have a look.
But I'm away for a couple of days, so not immediately.
 
I have recovered other model cameras in the past by tftp booting a uImage over the network - but I don't remember whether the R0 bootloader has that facility.
I still have a couple of 2332s kicking around - I could drag one out and have a look.
But I'm away for a couple of days, so not immediately.

As I said, any assistance greatly appreciated.
No hurry, this camera has not been working for couple of months now. It was replaced in my setup when I first bricked it.
 
All five updated cameras seem to be working fine, with one exception;

My DS-2CD2432F-IW is not playing nice with recording on event/movement/alarm etc. It will record to NVR when set to 'continuous', but not for any other option. I have tried settings through camera web GUI and NVR to no avail.

Any ideas?
 
No hurry, this camera has not been working for couple of months now. It was replaced in my setup when I first bricked it.
Based on the content of the serial console log that you posted - there is a good amount of functionality still available when the camera boots up.
It might be interesting to explore that and see about fixing it up.
If you feel inclined to spend some more time on the problem, I could start a new thread and we could do some exploration.
Let me know what you'd like to do.
 
Are these the options under the NVR storage menu? Motion / Alarm / Event etc

3MkNPtp.jpg
 
That looks OK - and, as you've said, it should work to record smart events.

The strange thing about it was that when I walked in front of the camera initially, it would sound an alarm that I have never heard before. So I'm thinking that maybe it made this sound on an error or something?
 
Just want to Thank OP and whoever else made this possible. Both my DS-2CD2332-I are operational and updated to 5.4.5

P.S I went directly to 5.4.5 in stage 3 without issue on both cameras.

Thanks again.
 
Just want to Thank OP and whoever else made this possible. Both my DS-2CD2332-I are operational and updated to 5.4.5
Well done! Another good result.
OP and whoever else made this possible.
Yes indeed - it's a team effort when you add all the contributions together.
And if Hikvision didn't play tricks with the firmware we'd have nothing to do ...