I think there is a chance you'd lose the wireless capability by using the devType code for DS-2CD2532F-ISI'm curious in the hex editor with the model DS-2CD2532-IWS if you can use the devtype as per the steps for model: devtype: 1498 Model: DS-2CD2532F-IS (since this devtype is missing the W-wireless)? Does that matter?
Thank you..I think there is a chance you'd lose the wireless capability by using the devType code for DS-2CD2532F-IS
Which might not be a problem if you don't use it.
But a couple of questions:
Is the existing devType code in mtd6ro_orig FF98? Or does it have a correct value already?
Are you able to run the prtHardInfo command to see the devType code?
Also - we could ask @Calumet what devType code was used, and add it to the table.
If that's a Chinese camera running 'hacked to English firmware (otherwise why would you have to resort to the enhanced MTD hack to update it) I'd have expected it to need the brickfixV2CN version of the fixup firmware.
Was that 'file transfer complete' or 'system upgrade successful' ?It appeared successful..
If I recall correctly, it was successful transferring the file (using brickfixv2EN.dav copied to digicap.dav)... and then after the reboot to active it, I was never able to telnet in. If I set up pings to 220.127.116.11 as I reboot it, I only see about three successful pings.. and then it does not respond anymore and in trying more reboots, it never handshakes with the tftp server and won't take any digicap.dav files. After about 2 or 3 minutes, it has a pingable IP of 192.168.1.64 and only listens on port 8000. I think it remains in that state if powered up. I had 100% success on a bunch of the CCCH serial'd cameras with the brickfixv2EN... luckily. Just this one model is giving me a hard time.If that's a Chinese camera running 'hacked to English firmware (otherwise why would you have to resort to the enhanced MTD hack to update it) I'd have expected it to need the brickfixV2CN version of the fixup firmware.
Was that 'file transfer complete' or 'system upgrade successful' ?
If just the file transfer, try the brickfixV2CN version.
But try it anyway.
Also - if you leave the camera powered up for 10 minutes, does it do an auto-reboot to the 18.104.22.168 IP address?
SADP will show that status without the need to alter the PC IP address to check.
If it only said 'file transfer successful' and did not after that say 'upgrade completed successfully' (or similar wording) then the firmware has been rejected and not applied. Normally that would mean a re-try with other firmware would be the way forward.If I recall correctly, it was successful transferring the file (using brickfixv2EN.dav copied to digicap.dav)
Well done for getting there. Sigh of relief all round ...Ok.. I got it.. FINALLY. I had to find a fw version that would load first .. and I think the one I used was 5.3.0(downgrader?)... and from that, I was able to use "update" from the serial connection for the first upload and from there everything worked.
It would be interesting to see an abridged version of that - to see what the initial problem was.I saved the serial output of all the experimenting I did.. and I'll have to review it.
It does indeed.Serial rox.
Yes, that's correct. It emits a UDP probe packet on a specific port to 22.214.171.124 on which if the Hikvision tftp updater is listening a specific response is sent, and a handshake occurs, following which the tftp transfer is done.I assume that is the normal behaviour that allows for FW to be uploaded.. that it always brings up a 126.96.36.199 IP, and checks 188.8.131.52 for a digicap.dav file?
Pretty well, unless u-boot itself has been compromised.I get the impression you should be able to always recover these, unless there is some sort of physical or electronic damage.