Hikvision DS-IPC-B12H-I: problems with TCP stream

Sergey Kandaurov

Sergey Kandaurov

n3wb
Dec 18, 2018
5
1
Philippines
I've just bought a cheap "gray market" Hikvision camera DS-IPC-B12H-I. It has V5.5.71 build 180828 firmware and chinese UI (I can live with this).

I've discovered problems with getting corrupted H.264 stream via TCP (fails to play sometimes and ffmpeg shows errors). But what's more worrying is that even web UI fails to load due to corrupted data.

For example, If I try downloading WebComponents.exe - 1 out of 5 times I get it corrupted.
Code: 
$ seq 10 | xargs -I{} sh -c 'wget -q -O - "http://192.168.1.203/codebase/WebComponents.exe" | md5sum'
e517b857d0866f621f1e5b211cba168a  -
e517b857d0866f621f1e5b211cba168a  -
b4ee1a94207d2de02c87a5d748255dfc  -
e517b857d0866f621f1e5b211cba168a  -
e517b857d0866f621f1e5b211cba168a  -
e517b857d0866f621f1e5b211cba168a  -
b0ba5720457cffed3852c11fd65f4877  -
e517b857d0866f621f1e5b211cba168a  -
e517b857d0866f621f1e5b211cba168a  -
e517b857d0866f621f1e5b211cba168a  -

The same happens with some (random) .js files and I have to refresh multiple time with cache disabled to get the Web GUI loaded.

I tried capturing packets and discovered that the camera sends a part of the data 2nd time to the same stream while keeping file size to its correct value. This basically produces corrupt files.

duplicated_data.png


I believe that this might be related to the fact that the camera is connected to a cheap 100mbps PoE switch/injector which causes delays and packets drops. But it's TCP - it's supposed not to allow data corruption.

I'd try upgrading firmware, but I can't any firmware for "5xx5" (whatever this means), but Hikvision web site has version 5.5.60 while my camera is 5.5.71.

Is it always like this with Hikvision or did I just got a specially buggy firmware?
 

Attachments

Sergey Kandaurov said:
I believe that this might be related to the fact that the camera is connected to a cheap 100mbps PoE switch/injector which causes delays and packets drops. But it's TCP - it's supposed not to allow data corruption.
Click to expand...
In which case this would be the simplest empirical change to make.
As an experiment you could see if the same symptoms occur if the PC is directly connected.
The symptoms suggest massive network problems - but from which element in the chain is the question.
 
I tried connecting the camera to another Gigabit switch - same issue, just less frequently (about 1 in 30).
TCP is designed to deliver the correct data (or don't deliver it all). If the camera is duplicating data in the TCP stream - it sounds like a critical bug in camera firmware to me.
 
I think that does suggest a networking issue, if changing the switch improves the problem.
On TCP - yes, a CRC fail will cause a packet retransmit, so yielding good data. Until the connection is reset and reconnects, which can be very fast.
Have you eliminated the cable to the camera?
 
Yes, I tried connecting the camera directly to PC with a different cable - same result. I guess that 1000mbps has less problems compared to 100mbps just because it's faster - less time to transmit a file means smaller chance that it runs in conflict with something, or less data in buffer because it clears faster, etc.

TCP connection should just resent the packed if it's dropped/damaged. Maybe drop the connection. But corrupting the data? If a camera firmware sends corrupted data via TCP - it just can't be trusted for security.
 
Yes, somehow the camera firmware feeds the same data two times to TCP. Or camera's TCP forgets to clear a buffer. In any case - it's camera firmware problem, and with no firmware updates available for the camera it looks frustrating.
 
You must log in or register to reply here.
Top Bottom