Flashed DS-2DE2103-DE3/W with 5.39 build 150910 - Login issue... SOLVED!

developer said:
Do you have any suggestions as to what I should do next? Thanks Alastair.
Click to expand...
If you're up for what might be a bumpy ride - there are a couple of rather speculative things that could be tried.

But first there is a slight puzzle, which might be explained if you didn't source the 2 cameras together.
Assuming the R0 link is valid, the working camera that you attached mtd6ro from should be happy to accept stock EN/ML firmware without a language mismatch.
Unlike the problem camera.
Which may suggest either that the problem camera might not have the same form of 'fixed' mtd6ro content, or that the firmware you updated it with has additional language requirements over the true R0 stock firmware.
The former would be good as it can be tweaked.

On the things to try ideas (don't do these yet as additional info would be needed) -
I'm thinking that my 'brickfixV2' tweaked firmware, which is R0-based, might provide the working environment to :
Extract mtd6ro and see if it's had the 'enhanced MTD hack' and if not, do it and the camera should be able to be upgraded with stock EN/ML firmware.
Apply selected parts of the extracted firmware from the good camera (excluding mtd6ro and earlier partitions) and if it is 'hacked to EN firmware' the camera will work OK again.
 
I'm game. :-) Bumpy rides are a-ok. So brickfixV2 gets me past psh and I can get the mtd6ro which I figure I'm going to diff against the one I got from the good cam and if so, then I use bfv2 to put selected parts (gui?) back onto the problem cam and I'm good to go. BTW, when I use the batch tool, I can configure everything except telnet...
 
developer said:
BTW, when I use the batch tool, I can configure everything except telnet...
Click to expand...
Yes, telnet was removed in the running system a while back. SSH replaces it.

The brickfixV2 firmware installs a changed version of the 'min-system recovery environment' that does not have psh, has telnet, does not run any of the usual camera apps, but has a full kernel that can be used at the root shell.
After it's installed, it boots into it, ready for use.
For normal R0 cameras, the /dav/fixup.sh shellscript takes the process through 3 stages, reducing much of the need for the user to handle the low-level techy stuff.

A possible approach would be to simply follow the brickfixV2 method, and use the 5.3.9 firmware as the upgrade file in Stage 3.
What I'm thinking is - update the camera with brickfixV2, probably the CN version, if not try the EN version.
Try this using either the Batch Config Tool, or the Hikvision tftp updater.
But either way, you'd need to change the PC IP address to 192.0.0.128 to be able to telnet in to the camera using admin/12345 after it's been power cycled after the brickfixV2 install.
There should be a root shell prompt to allow the /dav/fixup.sh shellscript to be run.

Another approach would be to use the min-system recovery environment of brickfixV2 to manually extract and replace the flash partitions using either tftp or the mounted NFS NAS share.
 
Seems like there is enough info here, plus your video and instructions. I'll look at your shell script too, just so I can see what its doing. If I lose the cam, I lose the cam. If not however, there will be a procedure for others to deal with it. Thanks, and I will let you know how it goes or if I run into an issue.
 
Hi Alastair.

I've been able to put several different versions of software on the cam. None work properly, but I'm not giving up. These are indeed R0 cams. I found a spreadsheet that is quite useful. I've attached it.

So I found a firmware file that I absolutely know is for this cam. I've pulled it apart. I see that when we transfer the firmware, nothing happens until the cam reboots. At that point, it seems to get preconfigured via initrun.sh. Once everything is done, then I assume it reboots again and now runs with the configured layout.

So, thanks to the cam's initial search for a tftp server @.128, I can send it whatever I want. I've sent a lot as I said, but I'm focusing on the known firmware file. I've had that go in ok and rebooted. After a while, SADP sees it and I can change the IP without an issue. Then however, I can't login because it refuses the connection. Same for telnet and same for SSH. So, it may be that the daemon that sits on those ports is not working right. When I switch to another box and fire up the batch config tool, it sees it but when I try to configure it, I get an error that it has no config library. So, something in that initial preconfiguration didn't complete properly or wasn't undertaken.

This is where I am.

I plan to check through the initrun.sh to see exactly what it's doing. I assume the gibberish lines in the file are comments in Chinese?

I have also pulled apart your firmware file. I haven't had a chance to look at it, but I figure you're doing something similar and setting up the daemon (getty?) on these ports.

Any pointers on how to continue on or am I on the right track, given the current circumstance?

Thanks Alastair! :-)
 

Attachments

developer said:
I have also pulled apart your firmware file.
Click to expand...
How - using hiktools to unpack?
The brickfixV2EN or CN firmware is just a stripped-down version of the 5.4.0 R0 stock firmware.
The essence of what it does is within this very slightly obscured script.
Code: 
#!/bin/sh
if [ -e /dav/notice ]; then
    echo "[Brick-fix tool] Initialising fixup_log.txt" > /dav/fixup_log.txt
    echo "Hello Hikvision! Enabling rollback ..."
    cat /dav/notice > /dev/mtdblock8
    rm /dav/notice
    echo "Enabled."
    echo "Payload dropped, rollback re-enabled" >> /dav/fixup_log.txt
    echo "Initialising fixup current status to stage1" >> /dav/fixup_log.txt
    rm /dav/fixup_stage?.txt
    echo "Fixup stage1 completed - rollback payload dropped" > /dav/fixup_stage1.txt
fi
echo "[Brick-fix tool] Initiating reboot into min-system " >> /dav/fixup_log.txt
/usr/sbin/set_sysflag -m 1
/sbin/reboot
The payload is a different version of the 'min-system' recovery image, that does not have the anti-rollback 'feature', has telnet access and provides a handy environment for running the /dav/fixup.sh script which takes the user through the 3 stages of extracting mtd6ro, imported a modified version of mtd6ro, and triggering a firmware update with the selected digicap.dav, which on a regular R0 camera can be direct to the 5.4.5 version.

I think the key first step for you would be to somehow get an export of mtd6ro to determine if it represents a CN region camera that depended on 'hacked to EN' firmware, or, if like the working camera, it already appears to have been tweaked to convert to EN.
But to do that, you need to get to a shell prompt by some means.
The brickfixV2 firmware might just be that means, the uncertainty being whether it is a proper match to the camera.
 
developer said:
you have a lot of stdout action... how does the user see that when they are doing this?
Click to expand...
It's stdout associated with the telnet session that's running the software. All other output goes to the serial console.
developer said:
I thought it had to be closed following the transfer, otherwise it would repeat after a reboot.
Click to expand...
Yes, once the Hikvision tftp updater has done the initial transfer, it does need to be shut down so that it doesn't get probed and found and activated again at the next startup.
developer said:
Also, I have a good mtdblock6 from the good cam extraction. Can't I use that one for stage 2 without modding it?
Click to expand...
Ideally not - the MAC address would be duplicated, impacting local networking, the serial number would be duplicated, though not much of a problem. And the assumption is that camera options are identical.
But if you can import a modded one - you can just as easily check out and if needed fix up the exported one.
As I said - it would be very interesting to see if it has valid contents for an EN language camera.
I would guess not, as you're into a 'language mismatch' situation.
If so - it's easily fixed.
 
Ok, I deleted my last entry because I went back through your instructions very, very carefully.

It's fixed!

My problem was not paying careful attention to the steps and a config issue on my end. The brickfix English version did not work (CH in serial), so I tried the Chinese. That did give me the telnet and I was able to see the messages. Also, earlier after firing up the 2nd tftp server, I had neglected set it to use my gigabit network card instead of the slower built-in, which is an ethernet dead-end. Once I corrected that, I was on the road again.

I then ran fixup.sh and went through the steps exactly. In the modification of mtd6ro, the device type was correct, but I had to change the language from Chinese (2) to English (1). That required an update to the checksum, which I did. Instruction-wise, I wasn't sure if your fixup.sh would want the newly-saved _mod file or if it had to be renamed (which it does not). You might want to update your doc there for newbies like me. You also can now add type 1C23 for DS-2DE2103-DE3/W to the enhanced_mtd_hack.txt doc, so this is indeed going to help some folks out there! :-)

So, yeah... I'm getting a little slow in my old age, but I have to commend you on making this rescue possible. You obviously did a lot of the dirty work to make this a 15-minute job.

I guess my next bit of fun is to mod the other half-dozen cams I have to make them English-upgradable, but first I'm going to play with the new features in the updated gui!

Alastair, you are indeed a talented and slick coder as well as a patient gentleman for folks like me.

Thanks so much for your help!!!

-Andy
 
developer said:
It's fixed!
Click to expand...
Wow! That is a brilliant result, I'm really pleased that you got there. Well done!
And we all learned some things along the way.

developer said:
In the modification of mtd6ro, the device type was correct, but I had to change the language from Chinese (2) to English (1). That required an update to the checksum,
Click to expand...
That's the key for the conversion to EN/upgradable.
And it shows that this camera will have been using 'hacked to English' firmware, unlike the working CCCH camera, which had already had a modified mtd6ro.
So your saved flash partitions are very likely from stock firmware.

developer said:
You also can now add type 1C23 for DS-2DE2103-DE3/W to the enhanced_mtd_hack.txt doc, so this is indeed going to help some folks out there!
Click to expand...
Good suggestion, done.
developer said:
I guess my next bit of fun is to mod the other half-dozen cams I have to make them English-upgradable
Click to expand...
Don't get too carried away with your success!
Be a bit cautious.
Remember, this tweak is purely for R0 series cameras, other models require a different approach.
But anything is possible ...
 
You must log in or register to reply here.
Top Bottom