direct Ethernet connect to DS-2CD2332-I w/CCRR in S/N while bricked

Kenneth Anderson

Kenneth Anderson

n3wb
Jan 14, 2018
29
3
Trying to connect 10-base-100 direct to cameras (2) which got bricked trying to upgrade firmware. I've read that the connection must be through a switch or router, etc. b/c a x-over cable connection won't work. My problem is that I already tried the firmware upload with a direct connection and it appeared to work judging from the STDOUT from the hikvision_tftpd.py utility written by Scott Lamb that I used for the upgrade process. They both had 5.2.x, and I tried to put 5.3.0 in them. Now they won't allow me to http into them, they are stuck looking for tftp only.

I'm wondering if these cams might have gotten bricked b/c I connected them direct instead of via a switch, or if it is b/c wrong version of firmware. I don't have a spare switch, but I do have spare Linux computers which have dual gigabit ethernet ports. I had hoped to get around the switch requirement if needed by bridging the interfaces together of the spare Linux computer(s) but I didn't get that to work on my first try.

Could someone give me a reasonable direction to try next to unbrick these? The cams are now stuck with 192.0.0.64 addresses and not allowing http access into them. The serial numbers show in a tcpdump as DS-2CD2332-I01201505<0x2E>CCRR518288969 and ...9008. I'm not even sure where to get a known good set of digicap.dav's. (USA). If need be, I guess I could retrieve a wifi router two hours drive away that has four cable interfaces. Having no income whatsoever makes that option a little bit costly for me considering I'm not sure it will get me anywhere.

Additionally, I have two other cams I'd like to be able to upgrade. They are DS-2CD3335-I...AACH... and DS-2CD3345-I...AACH..., both version 5.3.3 but different builds. I'm unsure if they they get the same firmware builds as the DS-2CD2xxx or not.

I would appreciate the advice on these challenges of mine!
 
Kenneth Anderson said:
I'm wondering if these cams might have gotten bricked b/c I connected them direct instead of via a switch, or if it is b/c wrong version of firmware.
Click to expand...
Connecting direct will not brick them, but updating CN region cameras with EN/ML firmware will.
But the tftp probe that the cameras do on startup works better when both PC and camera are wired on switch or router ports.

Fortunately, for DS-2CD2x32 cameras there is a brick-fix tool and method that also allows full upgrade to the 5.4.5 EN/ML firmware from here : DOWNLOAD PORTAL
If the Python tool doesn't pick up the probe from the camera you can also get the Hikvision tool from the second link here : Custom Firmware Downgrader 5.3.0 Chinese to 5.2.5 English

And the brickfixV2 tool and 'enhanced mtd hack' for upgrading is here : R0 / DS-2CD2x32 BrickfixV2 brick recovery and full upgrade tool - enhanced.


Kenneth Anderson said:
The cams are now stuck with 192.0.0.64 addresses and not allowing http access into them.
Click to expand...
Here is something you could try if you don't have any switch/router ports you can use via a direct cable connection (straight through is OK, you don't need a cross-over cable) :
With the PC IP address set to 192.0.0.128 try a telnet connection to the camera on 192.0.0.64 - if a response, login with admin/12345
With the tftp server running, and the brickfixV2 tool (try both the EN and CN version) copied as digicap.dav in the same folder, use the shell commands

tftp -g -r digicap.dav -b 1400 192.0.0.128
/bin/upgrade /digicap.dav

Then power cycle the camera, wait 30 secs and log in again with telnet
Delete the brickfix digicap.dav and replace it with the 5.4.5 EN/ML digicap.dav from the download link above.
At the shell prompt use
/dav/fixup.sh
and follow the instructions.
 
alastairstevenson said:
...try a telnet connection...
Click to expand...
Fails like this:
# telnet 192.0.0.64
Trying 192.0.0.64...
telnet: Unable to connect to remote host: No route to host

My settings appear just fine, as shown below:

ifconfig output:
# ifconfig
eno1 Link encap:Ethernet HWaddr 00:26:b9:ef:57:dd
inet addr:192.0.0.128 Bcast:192.0.0.255 Mask:255.255.255.0
....
wlp3s0b1 Link encap:Ethernet HWaddr 5c:ac:4c:29:53:d0
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0

ip route output:
# ip route
default via 192.168.1.1 dev wlp3s0b1 proto static metric 600
169.254.0.0/16 dev wlp3s0b1 scope link metric 1000
192.0.0.0/24 dev eno1 proto kernel scope link src 192.0.0.128
192.168.1.0/24 dev wlp3s0b1 proto kernel scope link src 192.168.1.3 metric 600

tcpdump output, includes the entire telnet attempt:
# tcpdump -i eno1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
22:29:59.471964 ARP, Request who-has 192.0.0.128 (Broadcast) tell 192.0.0.64, length 46
22:29:59.472000 ARP, Reply 192.0.0.128 is-at 00:26:b9:ef:57:dd (oui Unknown), length 28
22:29:59.472230 IP 192.0.0.64.9979 > 192.0.0.128.9978: UDP, length 20
22:29:59.472293 IP 192.0.0.128 > 192.0.0.64: ICMP 192.0.0.128 udp port 9978 unreachable, length 56
22:30:04.478383 ARP, Request who-has 192.0.0.64 tell 192.0.0.128, length 28
22:30:05.478432 ARP, Request who-has 192.0.0.64 tell 192.0.0.128, length 28
22:30:06.478433 ARP, Request who-has 192.0.0.64 tell 192.0.0.128, length 28
22:30:57.191037 ARP, Request who-has 192.0.0.64 tell 192.0.0.128, length 28
22:30:58.190438 ARP, Request who-has 192.0.0.64 tell 192.0.0.128, length 28
22:30:59.190386 ARP, Request who-has 192.0.0.64 tell 192.0.0.128, length 28
22:31:00.190555 ARP, Request who-has 192.0.0.64 tell 192.0.0.128, length 28
22:31:01.198439 ARP, Request who-has 192.0.0.64 tell 192.0.0.128, length 28
22:31:02.194434 ARP, Request who-has 192.0.0.64 tell 192.0.0.128, length 28


Prior to the telnet attempt, I did run hikvision_tftpd.py on the cam once again with my best guess .dav file from your portal link, if that matters. STDOUT from hikvision_tftpd.py appeared to indicate full success.

I'd appreciate your thoughts. Also be aware of my concern about your instructions in the link as to using an MS Windows computer. I only have Linux, so will that change your advice?

Thank you kindly!
 
Last edited:
Kenneth Anderson said:
22:29:59.471964 ARP, Request who-has 192.0.0.128 (Broadcast) tell 192.0.0.64, length 46
22:29:59.472000 ARP, Reply 192.0.0.128 is-at 00:26:b9:ef:57:dd (oui Unknown), length 28
22:29:59.472230 IP 192.0.0.64.9979 > 192.0.0.128.9978: UDP, length 20
22:29:59.472293 IP 192.0.0.128 > 192.0.0.64: ICMP 192.0.0.128 udp port 9978 unreachable, length 56
Click to expand...
That's the normal 'tftp updater probe' at power-on that the camera bootloader performs, though in this case the probe fails as the handshake response does not occur.
A couple of things:

What does nmap 192.0.0.64 yield if anything?

And you should be able to avoid Windows if you use the brickfixV2 firmware (renamed as digicap.dav) and the Python tftp updater look-alike to do a firmware update.
If that applies OK, then after a power cycle the camera should allow telnet on 192.0.0.64 and the /dav/fixup.sh script can be run, given a normal tftp server on 192.0.0.128
 
alastairstevenson said:
What does nmap 192.0.0.64 yield if anything?
Click to expand...
# nmap -p23 192.0.0.64
Starting Nmap 7.01 ( Nmap: the Network Mapper - Free Security Scanner ) at 2018-01-15 09:57 CST
Stats: 0:00:00 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 50.00% done; ETC: 09:57 (0:00:00 remaining)
Nmap scan report for 192.0.0.64
Host is up (0.00021s latency).
PORT STATE SERVICE
23/tcp filtered telnet
MAC Address: C4:2F:90:27:21:78 (Hangzhou Hikvision Digital Technology)

Note that the above yielding was only obtained when nmap was launched ALMOST immediately on cam power up. I'm guessing there is a short window within which I might be able to establish a telnet session. I'll be working on that trick after I post this to you. I've been trying it but so far haven't hit the magic timing if one exists.

When launched just a moment too late or too early the response would always be as follows:

# nmap 192.0.0.64 ( or # nmap -p23 192.0.0.64 )
Starting Nmap 7.01 ( Nmap: the Network Mapper - Free Security Scanner ) at 2018-01-15 09:21 CST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 0.50 seconds

Trying the -Pn yields:

# nmap -Pn 192.0.0.64
Starting Nmap 7.01 ( Nmap: the Network Mapper - Free Security Scanner ) at 2018-01-15 09:26 CST
Nmap done: 1 IP address (0 hosts up) scanned in 0.48 seconds

I'm very grateful for your time and expertise. I'm suspicious of my laptop settings somehow only b/c the IP config of that interface often tends to revert back to 10.x.x.x, what is [evidently] in some config or .d file (but not /etc/network/interfaces) given a few moments of inactivity so I've just been careful to keep traffic going to the cam on that interface and checking after my commands are executed on the cam that the interface address has stayed on 192.0.0.128 during the command execution.
 
Last edited:
Kenneth Anderson said:
Note that the above yielding was only obtained when nmap was launched ALMOST immediately on cam power up.
Click to expand...
I'd say that the camera is running the version of the min-system environment that does not have telnet and which also blocks any attempt to install firmware that is older than the version that was last installed.

My brickfixV2 tool when installed, and activated after the first power cycle, will respond to telnet and will not block any version of firmware.

To run the /dav/fixup.sh script you'll need a normal tftp server, on the assumption that you will need to hex edit mtdblock6 and have it written to the camera. That also implies a hex editor that can provide a Checksum-16 value for a selected byte range.

Many people have updated directly to the 5.4.5 EN/ML firmware with no problems, though Hikvision do advise not to skip intermediate versions. But that's for the usual web GUI update, which is not the same as this method.
 
The step-by-step guide begins be saying "Create a folder on the local drive of your Windows PC". Is that implying that Linux PCs won't work? I only have Linux.
 
You must log in or register to reply here.
Top Bottom