Cameras and Upgrade Questions For Hikvision NVR DS-7608N-E2/8P

D

dallasjava

n3wb
Dec 30, 2014
11
0
I have a Hikvision NVR that I got from aliexpress. I have 2 2CD2032-I cameras connected to it I would like to get 4 more cameras. It looks like the 2032's aren't being sold anymore. I was looking at getting DS-2CD2035-I, but one of the sellers says it will not work with my NVR and firmware version. If I upgrade the firmware, will this camera work? What version should I use? If not, can someone recommend a bullet camera that will work? Here is the
getHardInfo:

Serial NO :0820141111AARR487506319WCVU
V3.0.8 build 140825
KernelVersion: V1.0.0 build 140512
dspSoftVersion: V5.0 build 140816
codecVersion: V5.0 build 080808
hardwareVersion = 0xb000
encodeChans = 0
decodeChans = 8
alarmInNums = 0
alarmOutNums = 0
ataCtrlNums = 2
flashsize = 0x10
ramSize = 0x200
networksNums = 2
language = 1
devType:DS-7608N-E2/8P
bootPartition = 2
randomCode =
 
Interesting that your 7608N has language=1
That suggests it would be pretty safe to update with any of the wide range of revisions of firmware off the Hikvision EU site HIKVISION EUROPE
But, just in case the 3.0.8 firmware has been 'hacked to English', it may be worth checking the language value shown at a slightly deeper level with:
cat /proc/hkvs/bootpara
With your 3.0.8 firmware still having telnet, you can give yourself a safety net to revert back to if you hit any problems with updates.
From an old post:

What I strongly suggest if you think about upgrading is to back up your existing firmware so you have a way back should you wish.
All you need is a copy of mtdblock2 in the as-delivered state. But copy mtdblock0 and 1 also.
The easiest way is if you can add a NAS destination via the GUI. It does not need to be formatted.
Something like this for an NFS mount.
Use 'mount' to find the mount point, then something like:
cd /mnt/tnfs01
umount /dev/mtdblock2
cat /dev/mtdblock2 > mtdblock2_orig
mount /dev/mtdblock2 /home/hik

You could also use TFTP, something like
TFTP -p -l mtdblock2_orig <IP address of TFTP server>

And the same for mtdblock0 & 1, though these don't need unmounted.
Then you can either at a later date 'cat' the mtdblock2_orig' back where it came from, or you can create new firmware using @wzhick really useful tool Hiktools to get a digicap.dav that the web GUI and TFTP recovery is happy with.
Also - make a backup copy of the NVR configuration, and the camera settings, via the maintenance menu, with the filename including the associated firmware version. You can't restore configurations across firmware versions.
That way - you can put the whole thing back exactly how it was before the firmware update if you ever need to do so.
Click to expand...
 
dallasjava said:
Would updating allow that camera to work?
Click to expand...
I think the answer would be yes, but as for which of the many versions of NVR firmware would support it I don't know.
There is a limited range of firmware versions over which CN language cameras will be accepted without 'language mismatch'.
If the proposed camera is set as a CN region, as you move up the firmware versions of the NVR at some point it will be rejected as a 'language mismatch'. I think that started in 3.3.4 though I can't recall for sure.
If the proposed camera is sold as 'English version' it should be OK, if you don't update the camera such that it reverts to its underlying region.
 
Usually a good clue is the letters in the serial number. CCCH implies Chinese.
Then the actual version of firmware as supplied versus the version on the label. If these are different it can be an indication that the seller has installed modified firmware.
 
@dallasjava if you're still interested in bullets, I have four DS-2CD2042WD-I bullet cameras installed outdoors that are working fine. They are the 4MP version of your 2032's.
 
I currently have a HikVision DS-7608NI-I2/8P NVR. The 2042's also worked on my previous DS-7608NI-E2/8P.
 
alastairstevenson said:
But, just in case the 3.0.8 firmware has been 'hacked to English', it may be worth checking the language value shown at a slightly deeper level with:
cat /proc/hkvs/bootpara
Click to expand...
@alastairstevenson Here is the output:

[root@dvrdvs /dev] # cat /proc/hkvs/bootpara
====================== BOOT INFO ====================
magicNumber :0x484b5753
paraChecksum :0xf4d
paraLength :0xf4
encryptVer :0x10000
language :0x2
device_class :0x2a
oemCode :0x1
encodeChans :0x8
decodeChans :0x8
ipcChans :0x0
ivsChans :0x0
picFormat :0x2
macAddr :c0-56-e3-1c-b6-10
prodDate :32:30:31:34:31:31:31:31
prodNo :343837353036333139
devHigh :0x0
cpuFreq :0x1
dspFreq :0x1
zone :0x1
webSupport :0x1
voipSupport :0x0
usbNums :0x2
lcdSupport :0x0
voNums :0x2
vganums :0x2
vtSupport :0x1
videoMaxtrix :0x0
extendedDecoder:0x1
extendedIVS :0x1
extendedAlarmOut:0x0
devType :0xa137
ubootAdrs :0x0
ubootSize :0x0
ubootCheckSum :0x0
tinyKernelAdrs:0x0
tinyKernelSize:0x0
tinyKernelCheckSum:0x0
==========================================================
 
dallasjava said:
language :0x2
Click to expand...
Hmmm... not the same value as shown in getHardInfo.
It seems to me that the installed firmware is masquerading the real language setting of the NVR.
You could take a look directly at the 'Hardware descriptor block'.
Grab a copy of mtdblock0
cat /dev/mtdblock0 > mtdblock0_copy
Get it off the NVR (eg a NAS mount) and with your favourite Hex editor (eg HxD) check out the 256 byte block starting at 0x2E000
The language byte is at 0x2E010 - expected to be 0x02 based on the bootpara values.

This means that the NVR is really a CN region device, masquerading as EN, so firmware updates will be problematic.
 
You must log in or register to reply here.
Top Bottom