Hikvision DS-2CD2132F-IS bricked, in search of help

[Billkater]

Ok, got my camera back to English using

http://www.arden.ie/?p=319 and this

http://securitycameranet.com/download/IVMS_Hikvision_oem/hikvision orginal/Technical_Bulletin/2014/Quick Start Guide of Hikvision IP Camera & Synology NAS Connection_v1.1.pdf


Now, back to the original problem of unbricking my other camera.

 

[Billkater]

eg

Now cd to the external share, in this case:
cd /mnt/nfs00
Then copy mtdblock11 like so:
cat /dev/mtdblock11 > block11

Copy the block11 file into your TFTP folder if not already there.
Now telnet to the failing camera.
Change to somewhere with a bit of free space.
cd /dav
Start the TFTP server on your PC.

Transfer the needed file.
tftp -g -r block11 <your PC or NAS IP address>
Flash it to the required place
cat block11 > /dev/mtdblock11

And reboot and hope for the best.
reboot

Have fun ...

I did this but not sure if did it right. Still in boot loop

 

[alastairstevenson]

Well that's disappointing.
If the bootup is still not completing for the same reason, ie:

<6>Unpacking initramfs...
<0>Initramfs unpacking failed: junk in compressed archive
<6>Freeing initrd memory: 4096K

then I'd speculate that this particular camera boot loader is expecting only an initramfs and won't fall back to using an initrd (an earlier ramdisk standard) that the firmware has applied like the older cameras.

Do you have any idea for all 4 cameras what the manufacturing date is, and whether the failing one is a markedly different date than the others? On the labels, in the serial numbers?
I don't wish to waste any more of your time by sending you on further activities that don't yield anything - though I suppose that's your choice to do or not.

It seems to me that you may have a new-manufacture camera with updated boot loader that has had applied old enough firmware that it no longer fully boots because it doesn't provide the type of ramdisk image that the bootloader expects. If that makes sense.
This is similar to what many people have experienced when receiving cameras with hacked apparently 5.2.0 firmware from 5.2.8 original and upgrading to a lower that 5.2.8 version and no longer booting. Though I haven't seen any analysis such as what your kernel log showed as to the cause of the incomplete boot.
I have not been able to explore this directly as I don't have any 2015 manufacture cameras - my last fairly recent purchase came from earlier stock.
I'm tempted to buy another just to experiment with.

So I think one thing that you may not yet have tried is a normal TFTP update using a 2xx2 5.3.0 version firmware, such as this, sixth down on the page:
http://overseas.hikvision.com/en/download_89.html

 

[whoslooking]

Using 5.3.0 will cause the camera to go to mini-system 4.08 but it will allow you ftp access.

 

[Billkater]

This is what I got after uploading new block11. Forgot to attach it for you

I have a real hard time connectiong with PuTTy. I have to use the Hikvision tftp updater to update firmware each time before I can connect with PuttY.

Here is the latest log also.

And as long as you want to keep trying so do I. I hate to give up on stuff.

The mfg date is 4-2015

 

[alastairstevenson]

It's still the same problem.

<6>Unpacking initramfs...
<0>Initramfs unpacking failed: junk in compressed archive

That's a pretty new camera, manufactured with 5.2.8 firmware.
I've checked the 5.3.0 and the 5.1.6 firmware, and as far as I can see, the hroot.img is in initrd (ie not initramfs) format in both cases.
So what's not clear is why in your camera the firmware is expecting the ramdisk to be only in initramfs format and as a consequence not being able to complete the boot.
Going back somewhat - the camera stopped working of it's own accord, not the result of any attempted firmware updates?
Which firmware versions have you tried to apply so far?

 

[Billkater]

Going back somewhat - the camera stopped working of it's own accord, not the result of any attempted firmware updates?
Which firmware versions have you tried to apply so far?

Yes. I hung it inside a machine shed with a Samsung 32gig SD card installed. Attached to a poe switch. Worked for 2 days I think. Then was just off and in the state it is now. The only firmware I have tried is the 5.2.5 I have linked to earlier

 

[Billkater]

Here is the log to the working camera. It appears different to me from the bricked camera.

 

[alastairstevenson]

Yes, that kmsg is normal.
The key difference is here:

6>[ 0.401113] Trying to unpack rootfs image as initramfs...
<6>[ 0.403729] rootfs image is not initramfs (no cpio magic); looks like an initrd
<6>[ 0.438490] Freeing initrd memory: 4096K

where this camera is happy to use the initrd that's in mtdblock11 and does not require that it be initramfs and baulk when it isn't.
As you've already dropped the known working initrd mtdblock11 in your bricked camera and it made no difference, something else is making the firmware require an initramfs instead of the initrd for the ramdisk load.

As you seem quite comfortable with all this low-level messing about, here is something you could consider.
Tedious though it may be to do - it might be useful to grab a copy of mtdblock5 & 6 from the failing camera, and use HxD to do a comparison with the same file off your good camera.
There should be space in /dav to do a 'cat /dev/mtdblock5 > block5' then 'tftp -p -l block5 <IP address of the PC running the TFTP server>' and the same for mtdblock6. Maybe use 'rm block5' to free space before that.

If you do the comparison, mtdblock6 will be the easiest to start with.
In the hardware descriptor block there will be differences for the Checksum-16 checksum (0x04-05), MAC address (0x35-4A), the manufacturing date (0x31-51). *edit* 0x41-51
Any other differences might provide a clue - perhaps at 0x56
And I suppose there could be large differences elsewhere - but I'm not sure what that could mean.

I have not tried this myself as I don't have one of these new-manufacture cameras, but @whoslooking has confirmed that a change such as incrementing the language byte and decrementing something not significant elsewhere such as manufacturing date does not brick the camera when the checksum is unchanged. So there may be potential to replace mtdblock5 & 6 from the working camera with a change to the MAC address so networking isn't broken.
Or if there is just a single difference, modify the copies you took from the failing camera using the whoislooking method. Remember there are 4 in total copies of the hardware descriptor block.
All speculative, of course, as unfortunately I don't have a suitable camera to test this on.

 

[Billkater]

Now you are over my head. I dont know anything about using HxD. I have looked but dont know what I am looking at. I attached the blocks from both cameras for you if you wanna have a look.



View attachment block5,6.rar

 

[whoslooking]

Now you are over my head. I dont know anything about using HxD. I have looked but dont know what I am looking at. I attached the blocks from both cameras for you if you wanna have a look.



View attachment 3506

I will take a look later for you and PM a link for the file. ;-)

 

[alastairstevenson]

I'll take a look and see if I can spot anything useful.

 

[whoslooking]

I've had a look at the file they seem ok although quite different from each other with totally different checksum's I think if you placed the them in the wrong camera it would fail and possible go to brick mode.

I've change them both to English and check the checksum and the values match.

https://www.dropbox.com/s/0z3kgxqlnw0satq/mtd5 & 6.rar?dl=0


Also you could try this copy I know this one works on 2015/01 may also work on later,

https://www.dropbox.com/sh/jdbjxlaukrehh15/AADOSefrwU0D7PRyr5whK4aFa?dl=0

 

[alastairstevenson]

Well - I also had a look at the files, and there are many differences between the good and the failing, too many to make any judgements unfortunately. And the same when comparing with others in my collection.
So, as a bit of a shot in the dark, here are the mtdblock5 & 6 from your good camera, with a small change to the MAC address to avoid a clash on your LAN, and a compensating change to the manufacturing date to preserve the checksum.
If you feel inclined - but you're probably getting a bit fed up with this long-distance attempt at problem solving (would be cheaper just to buy another!) - you could try applying these to your failing camera.
The commands, once you are able to telnet to a command prompt, would be something like this:
cd /dav
tftp -g -r block5_working_to_test <IP address of your TFTP server>
cat block5_working_to_test > /dev/mtdblock5
rm block5_working_to_test

and the equivalent for mtdblock6

reboot

 

[Billkater]

ok, I tried your block files alastairstevenson. I also tried both sets of yours whoslooking. Come up with the same results. Boot loop...

checked the log. Still has

<6>Unpacking initramfs...
<0>Initramfs unpacking failed: junk in compressed archive
<6>Freeing initrd memory: 4096K

Here is a thought. This was the only camera I had a SD card in. Could it of corrupted something on a reboot or does the camera even look for a card until after it has booted up?

Also, what do you think about trying upgrading to 5.3.0 or downgrading? If it didnt work I would still be in the same boat correct? Would I be able to get back to the 5.2.5?

 

[alastairstevenson]

Well, you can do firmware updates on an NVR via a memory stick in the USB port. I don't know about an SD card in a camera though.
Presumably the card was blank before you put it in the camera.

 

[Billkater]

I've change them both to English and check the checksum and the values match.

https://www.dropbox.com/s/0z3kgxqlnw0satq/mtd5 & 6.rar?dl=0

So if I put the working camera blocks back onto the working camera it will be in English correct?

- - - Updated - - -

Well, you can do firmware updates on an NVR via a memory stick in the USB port. I don't know about an SD card in a camera though.
Presumably the card was blank before you put it in the camera.

yes, I formatted it through the camera

 

[whoslooking]

correct yes it will be all in English.
Never tried to be honest, but if its going to work put the dav file in sd cards root and just reboot the camera, I would wait a while down power remove the card and power it again to see if it worked, worth a try.

 

[richisup]

Been reading through your post guys and thought i would plug in a dead DS-2CD2332 i have (V5.2.8) which I downgraded without researching first..

Interestingly it also gave
<6>Unpacking initramfs...
<0>Initramfs unpacking failed: junk in compressed archive
<6>Freeing initrd memory: 4096K

I tried the Block11 fix from another camera with no joy. However as the camera is bricked I upload the new 5.3.0 firmware just for fun... Now it shows up as DS-2CD-Min-system which is further than I got before but not exactly sure if this means anything?

Anyway just thought i would share this. I apologize for thread hijacking especially if its not relevant

 

[Billkater]

Been reading through your post guys and thought i would plug in a dead DS-2CD2332 i have (V5.2.8) which I downgraded without researching first..

Interestingly it also gave
<6>Unpacking initramfs...
<0>Initramfs unpacking failed: junk in compressed archive
<6>Freeing initrd memory: 4096K

What is the manufacturer date on your camera?. What firmware version does the tag show?