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

[alastairstevenson]

I still cannot access the web interface for the camera for some reason

Depending on the version of firmware that you did the final upgrade with, the camera may be on a default IP address that is in a different range from that the PC is using, such that browser access will fail.
What error did you get with the browser?
Much the best way to see the status of the camera after an upgrade activity is to use SADP. SADP Tool
It will find the camera across IP address ranges, and show if the camera is Active or Inactive, allow activation, allow network configuration, and show the running version of firmware.

I accidentally power cycled and it seems the brickfix firmware updated to that

Depending on the camera model - I would not have thought a HiWatch camera would accept an update from the BrickfixV2 firmware.
It's based on R0 V5.4.0 firmware and should simply be rejected as foreign firmware.
What does SADp show for the state of that camera?

 

[jericho]

It stayed on 192.0.0.64 and I used SADP to change it to 192.168.1.195 which is the range I used for my IPCameras.
I can ping it. I just telnet to it. I just cant access web interface.
Also, in SADP, the web port option is greyed out. Says SW version 4.08 Build 130906.


I cannot see the other camera at all on SADP.

I realise these are probably fairly basic issues but having spent 4-5 hour trying to fix them I'm at a dead end (and I do technology for a living but this might be beyond me).
I'd hate to have to scrap the cameras and buy new as they are both fairly decent and served me well - regret trying to upgrade firmware at all now.

 

[alastairstevenson]

I just cant access web interface.
Also, in SADP, the web port option is greyed out. Says SW version 4.08 Build 130906.

That's a pretty good clue.
That firmware version indicates that the camera is running in 'min-system recovery mode'.
This is entered when the main firmware won't run due to a problem.
It's a basic system with no web services.
The causes can be varied - but a problem with the contents of mtdblock6 versus the installed firmware may be one.
If you'd like to zip up the mtd6_orig and mtd6_mod and attach here I'll check it out for you.

eventually got to the end successfully with no error messages.

What firmware version did you use for the Stage3 firmware update?
And did you check out the contents of the fixup_log.txt activity transcript?

Also, I have a HikWatch camera (not grey market) that I accidentally power cycled and it seems the brickfix firmware updated to that - so I've somehow bricked that as well. Is there an easier process for recovering non grey market cameras?

Does the 'link detect' LED show on the switch/router port the camera is plugged in to?
Do you feel you could try a wireshark network capture timed to cover the power on of this camera then for a couple of minutes?
That might provide a clue as to the state of the camera, if SADP does not find it.
You could attach here for interpretation.

I'd hate to have to scrap the cameras and buy new as they are both fairly decent and served me well - regret trying to upgrade firmware at all now.

These should be able to be recovered, once the cause is understood and can be remedied.

 

[jericho]

I've attached the mtd6_orig and _mod >> Thank you very much for any help.

I've tried to run the process from scratch again on both cameras but for some reason now when I set pc to 192.0.0.128 and reboot either camera with Hikvision TFPT working nothing seems to connect.

The second camera does seem to be on the network, again, I can ping it now but can't access the web GUI, attached screenshot - thanks again for any advice.

(I had to rename the hex files with a .txt extension for the system to allow me to upload)

 

[jericho]

Ì should have added - the second camera is actually a DS-2CD2T42WD-I5 (and not a hiWatch as I mistakenly posted last night).

 

[alastairstevenson]

The mtd6_mod for the DS-2CD2032-I is fine, it looks like all you needed to do was correct the checksum.
The language byte was already set to 1, presumably from the original 2.

I'm guessing that the problem may be due to the firmware version that was used in the last stage.
What was the version?
If it was 5.4.41 that could be the cause.
Suggestion :
With the PC IP address set to 192.0.0.128, drop a copy of the digicap.dav from the 5.4.5 version into the folder where the tftpserve.exe is, start the tftp updater, connect using telnet to the camera.
At the root prompt, use the commands :

tftp -g -r digicap.dav -b 1400 192.0.0.128

/bin/upgrade /digicap.dav

The should download the firmware file and try an update.

The DS-2CD2T42WD-I5 is also running in min-system mode.
Was it definitely the brickfixV2 firmware it picked up, or the final firmware used to update the DS-2CD2032-I ?
With your PC on it's usual 192.168.1.x IP address, you may be able to telnet in to the 192.168.1.64 address.

 

[jericho]

ok, thanks a million for your help. Halfway there - my DS-2CD2032-I is recovered and working, per your suggestion above I just repeated the process using the 5.4.5 firmware (i had tried a few others) and it worked.

Regarding my DS-2CD2T42WD-I5 - should I be following different instructions than this thread?
I don't know if it's grey market or not - the serial number suggests it is not, and I purchased from a UK seller.

I tried the brickfix EN firmware. I tried an official 5.4.4_161125 firmware but I'm still stuck. I can see it in SADP but it is refusing Putty connection on 192.168.1.64 from my device when I'm on 192.168.1.x

BTW - please let me know if I can contribute/ make a donation to you somewhere for your help - I was on the verge of scrapping and buying new cameras.

 

[alastairstevenson]

my DS-2CD2032-I is recovered and working

That's good.
One down, one to go.

I don't know if it's grey market or not - the serial number suggests it is not, and I purchased from a UK seller.

The group of 4 letters in the serial number being BBRR suggests it is not a CN region camera.

Regarding my DS-2CD2T42WD-I5 - should I be following different instructions than this thread?

What's required is to apply a firmware update, there should be no need to amend the contents of mtdblock6.

It's interesting that SADP is showing the IP address of 192.168.1.64 while it is running the min-system environment.
This suggests that the default IP address has been changed in that version of bootloader.

I tried the brickfix EN firmware. I tried an official 5.4.4_161125 firmware but I'm still stuck.

By this do you mean that the Hikvision tftp updater, when the PC is on the 192.0.0.128 IP address, does not show any messages at all when the camera is power cycled?

As a long shot, based on the possibility that the default IP address is set differently, maybe try this :
With the digicap.dav from the 5.4.5 firmware in the same folder as the tftpserve.exe program, set the PC IP address to 192.168.1.128
Start the tftp server and power cycle the camera, watching for any messages on the tftp updater window.
The tftp updater works best when both PC and camera are wired to ports on a switch or router.
It's not reliable when the 2 are directly connected, nor when the camera is being powered over PoE.

I do technology for a living

Sometimes an interesting option that can yield additional info on a problem is to see what network traffic the camera broadcasts on startup / bootup, or send to the PC with the tftp updater running, using a network capture tool such as wireshark.

BTW - please let me know if I can contribute/ make a donation to you somewhere for your help - I was on the verge of scrapping and buying new cameras.

Thank you for the kind thought - but not necessary. I'm happy to try to help.
Even with not success over the network - hooking up a serial console would allow recovery. No need to scrap them.

 

[alastairstevenson]

What's required is to apply a firmware update, there should be no need to amend the contents of mtdblock6.

I just had a stray thought - but I've never tried this on a 'bricked' camera, so I'm not sure if it would do anything.
On the assumption that either the previously-known admin password, or the old defaults of 12345 and 123456789abc may be accepted -
See if the Batch Configuration Tool would be well enough supported by the min-system environment to effect a firmware update.
Batch Config Tool

 

[jericho]

You were right first time. Rebooted pc.
Started from scratch on the second camera.

It just needed the correct firmware loading again.
I think Windows firewall was somehow blocking the connection so I disabled that and the update took.
Painful and time consuming lesson but I've learned a lot and this thread and your helpful replies have been a huge help.

I owe you a debt, and you've saved me a few hundred euros so I'd genuinely like to contribute or repay in some way.
If you have a means of me doing so please let me know (via pm if you'd prefer) . And if not to you, maybe to a charity of your choice.

Your contribution on this thread is of immense value to myself and users like me. Thank you.

 

[alastairstevenson]

I think Windows firewall was somehow blocking the connection so I disabled that and the update took.

Well, that's a brilliant result, I'm pleased to hear it.

Whilst I know that the brickfixV2 method has benefited lots of people(and presumably many non-members who don't post about their experience) despite Hikvision's attempts to punish their customers it does bug me when there is a negative experience.
So it's good to eventually get to a positive end result from an initial failure, even though it may have involved a level of effort that in business would be considered uneconomic.
But we don't really count the cost of exercising our mental facilities, pursuing our hobbies, learning from experiences, being determined to take something to a conclusion rather than give up etc. If we did, we would not do what we do.

I owe you a debt, and you've saved me a few hundred euros so I'd genuinely like to contribute or repay in some way.

As I said before - a good thought, which is much appreciated, but I'm just happy that there was a good conclusion.
I'm sure though that @Mike would be pleased to accept a small contribution to the running costs of this lively and useful forum which so many enjoy and contribute to - IP Cam Talk Donations | IP Cam Talk

- Feeling nicely chilled on a Friday evening after some glasses of a really nice Malbec.
And after having just successfully hacked an interesting XM530 IMX307 camera module I'd built into a varifocal shell.

 

[jericho]

Done. Thank you and enjoy the long weekend.

 

[Heuer]

Many thanks Alistair. I have upgraded a DS-2CD2332 from 5.1.x to V5.4.5 although I did quickly learn that using V5.4.1 will not work. Maybe worth adding a note in your otherwise excellent instructions. I also found it was necessary to pause my ESET firewall manually as it gave no warnings and I sat looking at the Hikvision tftp updater for 10 minutes with nothing happening! Flushed with success I then had a go at my semi-bricked DS-2CD2632 which was misbehaving after a normal upgrade to V5.4.1. Once again it worked like a dream and all cameras are now working and on the same f/w.

You are a star!

 

[alastairstevenson]

Once again it worked like a dream and all cameras are now working and on the same f/w.

Brilliant!
Well done, and thanks for sharing your experience, that's what the forum is all about!

 

[Mike]

Well, that's a brilliant result, I'm pleased to hear it.

Whilst I know that the brickfixV2 method has benefited lots of people(and presumably many non-members who don't post about their experience) despite Hikvision's attempts to punish their customers it does bug me when there is a negative experience.
So it's good to eventually get to a positive end result from an initial failure, even though it may have involved a level of effort that in business would be considered uneconomic.
But we don't really count the cost of exercising our mental facilities, pursuing our hobbies, learning from experiences, being determined to take something to a conclusion rather than give up etc. If we did, we would not do what we do.


As I said before - a good thought, which is much appreciated, but I'm just happy that there was a good conclusion.
I'm sure though that @Mike would be pleased to accept a small contribution to the running costs of this lively and useful forum which so many enjoy and contribute to - IP Cam Talk Donations | IP Cam Talk

- Feeling nicely chilled on a Friday evening after some glasses of a really nice Malbec.
And after having just successfully hacked an interesting XM530 IMX307 camera module I'd built into a varifocal shell.

Done. Thank you and enjoy the long weekend.

Thank you both!

 

[robpur]

I recently upgraded a DS-2CD3332-I to the latest firmware using brickfix. Everything went smoothly but after the upgrade the camera will no longer work with a POE network switch. I've been using the camera since 2014 with a TP-Link TL-SF1008P but now when connecting the camera to the switch the front LEDs do not show that a device is connected and the camera doesn't work. I also have a ZyXel GS100-8HP and a TP-Link TL-SG108PE Smart Switch and the camera doesn't work with either of them. However, I have a PowerDsine 3501G POE injector that powers the camera via POE just fine so I know that POE is working in the camera. I know that my POE switches are working correctly since I have other POE devices connected that are functioning correctly. I've switched the wire around to see if perhaps I have a dead port on the switch, but the camera doesn't work no matter which port I use.

I have ruled out a network cable issue as being the problem. If I remove the network cable feeding the camera from the POE injector and plug it directly into the switch, it doesn't work. But then after moving it back to the POE injector the camera works correctly. I have also tried a different cable.

Has anyone else seen POE issues with Hikvision cameras that are not related to corroded contacts in the connector or blown POE within the camera? Again, my POE works, just not with the switches that I own. I can only use POE with an injector.

My next step is to do a factory reset on the camera but if that doesn't fix it the problem then I don't have a clue as to how to proceeded to resolve the issue. However, I'm not stuck since the camera works fine with a POE injector.

Just to be clear, the POE injector powers the camera through the Ethernet connector, not the coax power connector.

Thanks,

Rob

 

[alastairstevenson]

I recently upgraded a DS-2CD3332-I to the latest firmware using brickfix. Everything went smoothly but after the upgrade the camera will no longer work with a POE network switch.

That's certainly odd.
I don't see an obvious connection between the version of firmware in the camera and whether the camera hardware triggers the supply of power from the PoE switch.
When you plug it in, not even the bootloader is running, and it's a few seconds before the full bootup even starts.

However, I have a PowerDsine 3501G POE injector that powers the camera via POE just fine

That's a midspan PoE injector, unlike the PoE switches.
That might suggest a problem with the camera pigtail cable, as Hikvision connect all 8 wires in their cables.

 

[robpur]

It could possibly be a pigtail issue and not related to the firmware upgrade since before upgrading I pulled the camera from its location, cleaned it, and held it up in a couple of places with a network wire dangling to check a new mounting location before doing the firmware upgrade. I used the PoE injector during the upgrade and for later testing before running a permanent wire and connecting to a PoE switch. Point is that there was a lot of handling and a dangling wire that could have put stress on the pigtail around the same time I did the firmware upgrade.

The odd part is that it works with the PoE injector and not a PoE switch which are both 802.3af compliant. So at least in theory the PoE switch should work the same as the PoE injector, at least as far as providing power to the device. I knew that some forms of PoE do handshaking but I didn't know the details, and assumed that the firmware could be involved with the handshake. I looked it up and found that 802.3af does hardware handshaking so the firmware would not be involved. The initial handshake is just a short voltage pulse to see how much power the device draws.

Even though the PoE switch and injector should perform the same during handshake since they are both 802.3af, perhaps the camera is performing marginally and slight differences in the PoE supplies implementation of 802.3af allow one to work and not the other.

When cleaning the camera I noticed some tarnish on the pins of the network connection and cleaned it with alcohol, but the pins didn't get much brighter. I'll try cleaning again with something more volatile such as carburetor cleaner on a Q-Tip. If that doesn't work then I'll dissemble the the camera and check the pigtail with an ohm meter.

 

[alastairstevenson]

Even though the PoE switch and injector should perform the same during handshake since they are both 802.3af,

I'm speculating a bit here - but the midspan injector is a Gigabit device, looks like Mode B, so the power may be supplied on different wires than your switches if they are Mode A.

 

[robpur]

Thanks for the heads up about mode A and B. According to the specs of my PoE injector positive power is supplied on pins 4 and 5, with pins 7 and 8 being negative, so it's mode B. According to a support article from TP-Link, the manufacturer of the switch that once worked with the camera, all TP-Link PoE switches are mode A so they supply power on pin pairs 1/2 and 3/6. This is exactly what you speculated. The camera should be able to work mode A or B, and since it won't work mode A then the problem could be with the 1/2 or 3/6 pairs. However, according to a chart that Google gave me those pairs are also used for signal for both modes, whether it's 100 Mbps or Gigabit. If one of those wires were completely open then I would think that the camera would not work even with a mode B adapter. Even though it could get power from pin pairs 4/5 and 7/8, data would not be able to get through on pin pairs 1/2 and 4/6. I suppose that instead of a complete open on the 1/2 or 3/6 pairs that there could be a connection with low enough resistance to pass signals, but too high of a resistance to power the camera. Just guessing at this point but clearly I need to poke around in the camera and check out the pigtail.

Thanks for your input and I apologize for going a bit off topic in this thread. I doubt that my issue has anything to do with the firmware upgrade.