iTuneDVR

4-канальный DVR с прошивкой DH_HCVR5x04-S2_Eng_P_V3.200.0004.6.R.20151123
Железка висит в кабельной шахте, без родного корпуса, собранная в небольшую коммуникационную коробку,
чтобы оттуда достать матплату придется изрядно повозиться, поэтому точную модель назвать затруднительно,
еще более затруднительно подключить туда монитор или RS-232.

DVR работал нормально больше года с записью по движению, около месяца назад настроил 24/7 5fps + motion 16fps,
более никаких настроек не менял, пару недель всё нормально писалось. События по движению помимо хранения на
регистраторе дублировались по FTP на NAS. Сегодня заметил, что со вчерашнего дня нет выгрузки на FTP.
Вернее записей становится всё меньше и меньше, за несколько дней нет ни одной записи, потом снова несколько событий.
Событий не может не быть, так как на него подключены 2 камеры смотрящие в подъезд жилого дома, и движение там постоянное.

На FTP это выглядит примерно так:
2016-11-24 - 251 .dav файл по движению
2016-11-25 - 245 файлов
26-28 - ничего нет
2016-11-29 - 23 файла
2016-11-30 - 8 файлов
2016-12-02 - 6 файлов
2016-12-03 - 1 файл
2016-12-04 - 3 файла
То есть железку несколько дней подглючивало, потом она приходила в себя и в итоге загнулась совсем.
Web-интерфейса нет, RTSP-потоки сдохли, в ConfigTool 3.0 обнаруживается, но не отображает версию ПО и серийник.

DVR откликается на ping, открыт 23 порт. Нашел как попасть внутрь.
Снес конфиги (зря, не помогло) вбив в телнет
# rm rf /mnt/mtd/Config/
# rm rf /mnt/mtdbak/Config/
# reboot
После перезагрузки девайс встал на свой дефолтный 192.168.1.108, но ConfigTool'ом больше не обнаруживается. Есть пинг и телнет.

Нашел в сети инструкцию по реанимации Dahua IPC, в которой вычитал, что дефолтный порт 37777 не единственный,
куда подключается ConfigTool, есть еще порт 3800, через который можно попробовать залить .img прошивку.
И отвечает за порт 3800 служба upgraded (/usr/sbin/upgraded). Только на моем устройстве её нет, или я не могу её найти.
К сожалению команды find, locate, whereis, which не поддерживаются. apt-get тоже отказ. Если ничего не придумаю, и тут не
подскажут, придется всё же лезть в шахту и выковыривать.

Кстати, а есть ли где-нибудь список того, какие из nix команд понимают актуальные прошивки Dahua/Hikvision?

Список запущенных процессов:
~ # ps
PID USER TIME COMMAND
1 root 0:02 init
2 root 0:00 [kthreadd]
3 root 0:00 [ksoftirqd/0]
6 root 0:00 [khelper]
7 root 0:00 [kdevtmpfs]
8 root 0:00 [netns]
9 root 0:00 [sync_supers]
10 root 0:00 [bdi-default]
11 root 0:00 [kblockd]
12 root 0:00 [khubd]
13 root 0:00 [rpciod]
15 root 0:00 [khungtaskd]
16 root 0:00 [kswapd0]
17 root 0:00 [fsnotify_mark]
18 root 0:00 [nfsiod]
19 root 0:00 [crypto]
28 root 0:04 [scsi_eh_0]
29 root 0:02 [kworker/u:1]
30 root 0:00 [scsi_eh_1]
32 root 0:00 [ftspi020.0]
33 root 0:00 [kworker/u:3]
36 root 0:00 [mtdblock0]
37 root 0:00 [mtdblock1]
38 root 0:00 [mtdblock2]
39 root 0:00 [mtdblock3]
40 root 0:00 [mtdblock4]
41 root 0:00 [mtdblock5]
42 root 0:00 [mtdblock6]
51 root 0:00 /bin/sh /etc/init.d/rcS
86 root 0:00 /bin/sh /etc/init.d/S99dh
91 root 0:00 [jffs2_gcd_mtd5]
137 root 0:00 [OSA_135_1]
236 root 0:00 [log_thread]
237 root 0:00 [threadmon]
238 root 0:00 [log_notify]
244 root 0:00 [em_callback:0]
245 root 0:04 [em_callback:1]
246 root 0:04 [em_callback:2]
255 root 0:00 [dac thread]
263 root 0:00 [process_lcd0vg]
284 root 0:00 [hdmi_sli10121_p]
290 root 0:17 [dh9901_wd]
297 root 0:00 [vcap_md]
298 root 0:40 [vcap_vg_cb]
303 root 0:00 [scaler_add_tabl]
306 root 0:00 [scaler_callback]
307 root 0:00 [scaler_2ddma_ca]
312 root 0:00 [process_ftdi220]
313 root 0:00 [ftdi220_thread]
320 root 0:00 [mcp100_cb_threa]
321 root 0:00 [mcp100_getjob_t]
324 root 0:01 [favce_cb_thread]
325 root 0:00 [favce_engine0_t]
326 root 0:00 [favc_enc_log]
331 root 0:00 [favce_cb]
334 root 0:00 [favcd_cb]
335 root 0:00 [favcd_prep]
336 root 0:00 [ftmcp300_cb_thr]
337 root 0:00 [ftmcp300_pp_thr]
390 root 0:00 [audio_in]
391 root 0:00 [audio_out]
418 root 0:01 [gm_job_sch]
419 root 0:38 [gm_tick]
420 root 0:00 [gm_group]
425 root 2:01 [vp_slave]
426 root 0:00 [gm_wait_disp0_i]
427 root 0:00 [gm_wait_disp_sc]
428 root 0:00 [gm_wait_dec_bs_]
429 root 0:00 [gm_wait_enc_cap]
430 root 0:00 [gm_wait_enc_bs_]
431 root 0:00 [gm_wait_enc_scl]
432 root 0:00 [gm_wait_au_grab]
433 root 0:00 [gm_wait_au_rend]
434 root 0:00 [gm_vpslv]
435 root 0:00 [datain_callback]
436 root 0:00 [dataout_callbac]
437 root 0:00 [dataout_timeout]
438 root 0:00 [clearwin]
439 root 0:00 [usr_decode]
440 root 0:00 [gm_vpslvNotify]
444 root 0:00 [vp_master_0]
445 root 0:00 [gm_vpmst]
446 root 0:00 [gm_vpmstNotify]
517 root 0:00 net3g
519 root 0:01 telnetd
531 root 0:00 dvrhelper /var/Challenge
534 root 5:11 /var/Challenge buf
554 root 0:00 [gm_notify2nd_0]
555 root 0:00 [gm_notify_1]
556 root 0:00 [gm_notify2nd_1]
563 root 0:00 [gm_notify2nd_2]
567 root 0:00 [gm_notify2nd_4]
571 root 0:00 [gm_notify2nd_6]
575 root 0:00 [gm_notify2nd_8]
579 root 0:00 [gm_notify2nd_10]
580 root 0:00 [gm_notify_11]
581 root 0:00 [gm_notify2nd_11]
594 root 0:00 [gm_notify2nd_12]
617 root 0:00 [gm_notify_18]
618 root 0:00 [gm_notify2nd_18]
622 root 0:00 [gm_notify_20]
623 root 0:00 [gm_notify2nd_20]
626 root 0:00 [gm_notify_22]
627 root 0:00 [gm_notify2nd_22]
630 root 0:00 [gm_notify_24]
631 root 0:00 [gm_notify2nd_24]
643 root 0:00 [gm_notify_25]
644 root 0:00 [gm_notify2nd_25]
726 root 0:00 -sh
802 root 0:00 [kworker/0:0]
805 root 0:00 [kworker/0:1]
806 root 0:00 [kworker/0:2]
807 root 0:00 [kworker/0:3]
809 root 0:00 ps

Компактней будет запустить

чтобы в динамике увидеть активность, залогировав это дело через PuTTY

если ругнется на что-нибудь, то скорректировать ключи. Результат тоже сюда.

Судя по

процессы

живут и здравствуют, но надо убедится.

Что полезно будет:
Сделать kill 531 в данном контексте или по контекту новому и сделать

/var/Challenge

чтобы перезапустить программу и получить полную консоль логов запуска, которую тоже сохранить через PuTTY
Обращать внимание на красные места!!!

Писать или не писать - вот в чём вопрос!!!
Возможно проблема с винтом - соответственно смотрим S.M.A.R.T. и внимательно обращаем внимание на журнал.
Жаль, что ты удалил конфиг, не сохранив ничего оттуда, потому как там много полезного.

Возможно в в шахту слазить придется и заменить блок питания и убедиться на 200% что питание у тебя там стабилизированное, т.к. HDD к этому критичен на регистратре!!! Да и в большей степени осмотреть поверхностно плату надо и сделать фотку.

К подобным ситуациям надо быть готовым, раз регистратор где-то там, но он дёшев, а в данном случае доставляет беЗпокойства.
Конечно, не поступать как с перчатками, а ставить проверенный комплект, а это на рабочий стол на изучение и поднятие и главное выводы из всего этого!!!

Дошли руки поковырять пациента.
Интересно, что теперь 23 порт закрыт, открыты 80, 443, 554, 5000, 37777, что выглядит как живой DVR на дефолтных настройках.
Прогресс. Он даже отображает логин скрин на вебморде, только страница загружается очень долго. Тем не менее дальше не пускает.
Login failed! говорит для admin:admin

Попытка обновления через ConfigTool (раз уж 37777 оклемался) ни к чему не приводит - Failed to start upgrading.

В Putty top отвечает:

Mem: 432436K used, 82132K free, 0K shrd, 3140K buff, 22840K cached
CPU: 0.0% usr 12.5% sys 12.5% nic 0.0% idle 75.0% io 0.0% irq 0.0% sirq
Load average: 32.61 31.44 30.85 1/198 842
 PID PPID USER STAT RSS %MEM CPU %CPU COMMAND
842 825 root R N 280 0.0 0 25.0 top
529 526 root S 89.8M 17.8 0 0.0 /var/Challenge buf
526 86 root S 716 0.1 0 0.0 dvrhelper /var/Challenge
517 86 root S 700 0.1 0 0.0 net3g
825 816 root S N 368 0.0 0 0.0 -sh
86 51 root S 312 0.0 0 0.0 /bin/sh /etc/init.d/S99dh
816 1 root S N 300 0.0 0 0.0 telnetd
51 1 root S 296 0.0 0 0.0 /bin/sh /etc/init.d/rcS
1 0 root S 260 0.0 0 0.0 init
425 2 root DW 0 0.0 0 0.0 [vp_slave]
298 2 root DW 0 0.0 0 0.0 [vcap_vg_cb]
419 2 root SW< 0 0.0 0 0.0 [gm_tick]
290 2 root SW 0 0.0 0 0.0 [dh9901_wd]
28 2 root SW 0 0.0 0 0.0 [scsi_eh_0]
246 2 root SW< 0 0.0 0 0.0 [em_callback:2]
245 2 root SW< 0 0.0 0 0.0 [em_callback:1]
324 2 root DW 0 0.0 0 0.0 [favce_cb_thread]
418 2 root SW< 0 0.0 0 0.0 [gm_job_sch]
33 2 root SW 0 0.0 0 0.0 [kworker/u:3]
313 2 root DW< 0 0.0 0 0.0 [ftdi220_thread]

------------------------------------

~ # netstat -putan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:9989 0.0.0.0:* LISTEN 529/Challenge
tcp 0 0 127.0.0.1:9990 0.0.0.0:* LISTEN 529/Challenge
tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN 529/Challenge
tcp 0 0 0.0.0.0:554 0.0.0.0:* LISTEN 529/Challenge
tcp 74 0 127.0.0.1:45780 127.0.0.1:5000 ESTABLISHED 816/telnetd
tcp 0 0 192.168.1.108:34753 8.8.8.8:53 TIME_WAIT -
tcp 0 0 127.0.0.1:5000 127.0.0.1:45780 ESTABLISHED 816/telnetd
tcp 0 0 :::80 :::* LISTEN 529/Challenge
tcp 3 0 :::37777 :::* LISTEN 529/Challenge
tcp 0 0 :::23 :::* LISTEN 816/telnetd
tcp 0 0 :::443 :::* LISTEN 529/Challenge
tcp 1 0 ::ffff:192.168.1.108:80 ::ffff:192.168.1.51:49337 CLOSE_WAIT 816/telnetd
tcp 1 0 ::ffff:192.168.1.108:80 ::ffff:192.168.1.51:49338 CLOSE_WAIT 816/telnetd
tcp 0 440 ::ffff:192.168.1.108:23 ::ffff:192.168.1.51:49398 ESTABLISHED 816/telnetd
tcp 1 0 ::ffff:192.168.1.108:80 ::ffff:192.168.1.51:49339 CLOSE_WAIT 816/telnetd
tcp 1 0 ::ffff:192.168.1.108:80 ::ffff:192.168.1.51:49340 CLOSE_WAIT 816/telnetd
udp 0 0 0.0.0.0:36682 0.0.0.0:* 529/Challenge
udp 0 0 0.0.0.0:44387 0.0.0.0:* 529/Challenge
udp 0 0 0.0.0.0:3702 0.0.0.0:* 529/Challenge
udp 0 0 0.0.0.0:123 0.0.0.0:* 529/Challenge
udp 0 0 0.0.0.0:37778 0.0.0.0:* 529/Challenge
udp 0 0 0.0.0.0:37810 0.0.0.0:* 529/Challenge
udp 0 0 192.168.1.108:37810 0.0.0.0:* 529/Challenge
udp 0 0 239.255.255.251:37810 0.0.0.0:* 529/Challenge
udp 0 0 0.0.0.0:5050 0.0.0.0:* 529/Challenge
~ #

------------------------------------

/var/Challenge долго выводил много букв, после чего вылетел. Весь вывод с Putty выложил на http://pastebin.com/swrmHpBJ, чтобы тут простыню не вешать. Красные строчки отдельно ниже. Буду теперь искать что бы почитать, чтобы понимать, что там происходит.


23:41:35|trace CThread name:DevPtz m_internal:0x1a1efe0
../src/Video.c ERROR (func = Gmcap_GetCapMode line =>48): Open vcap.cfg Failed!

../src/Config.c INFO (func = Init_ChannelMap line =>575): Map[AUDIO_SOURCE_NORMAL][0]=0
../src/Video.c ERROR (func = Gmcap_GetCapMode line =>48): Open vcap.cfg Failed!

../src/NotifyProcess.c INFO (func = Gm_NotifyProcess line =>195): chn:3 GM_NOTIFY_TAMPER_ALARM res: 0xd
../src/Enccommon.c ERROR (func = AVencGetStream line =>546): Error return value -4
(последняя строка повторяется многократно в разных частях вывода)

23:41:54|trace CConfigManager::getConfig 'HddMount', but default config is not set yet!
DHFS: now,you are using V7 fs....
DHFS: DHFS Version $Rev: 227666 $, Built in Nov 23 2015 12:15:33
DHFS: g_disk_num = 1
DHFS: DISK:1, capa:488397168
../src/Enccommon.c ERROR (func = AVencGetStream line =>546): Error return value -4
23:41:55|[libInfra] debug ThreadBody Enter name = Encode, id = 944, prior = N64,stack = 0x62214d44
../src/Enccommon.c ERROR (func = AVencGetStream line =>546): Error return value -4

Возможно проблема с винтом

А он разве не должен был постучаться мне в почту и сообщить о проблеме?
Уведомления точно были настроены. Если проблема винта может молча вывести систему из строя это не есть хорошо.

Блок питания

Тут проще, он живет дома, хороший 20A блок, и с ним всё ок, а в шахту уходят уже 12V и ethernet

К подобным ситуациям надо быть готовым, раз регистратор где-то там, но он дёшев, а в данном случае доставляет беЗпокойства.
Конечно, не поступать как с перчатками, а ставить проверенный комплект, а это на рабочий стол на изучение и поднятие и главное выводы из всего этого!!!

Матплата регистратора осталась с какого-то объекта, так что я сильно переживать не стану, если она помрёт.
Тут уже любопытство и интерес поковырять удаленно, за то время пока я искал что и как делать DVR уже можно было демонтировать.
Проверенный комплект это в моем случае Hik, за несколько лет у меня было ровно 0 проблем с разнообразным зоопарком их DVR'ов, а с Dahua как-то сразу не сложилось и продолжает напрягать, но это уже отдельная тема

skyf1 писал(а):А он разве не должен был постучаться мне в почту и сообщить о проблеме?
Уведомления точно были настроены. Если проблема винта может молча вывести систему из строя это не есть хорошо.

Всё зависит он настроек. Смотрим S.M.A.R.T. на регистраторе и логи, чтобы исключить...

skyf1 писал(а):Тут проще, он живет дома, хороший 20A блок, и с ним всё ок, а в шахту уходят уже 12V и ethernet

Нужно стабилизированное питание для винта.
Есть смысл замерить контрольные параметры на оригинале и ...

skyf1 писал(а):Матплата регистратора осталась с какого-то объекта, так что я сильно переживать не стану, если она помрёт.
Тут уже любопытство и интерес поковырять удаленно, за то время пока я искал что и как делать DVR уже можно было демонтировать.
Проверенный комплект это в моем случае Hik, за несколько лет у меня было ровно 0 проблем с разнообразным зоопарком их DVR'ов, а с Dahua как-то сразу не сложилось и продолжает напрягать, но это уже отдельная тема

Мне кажется тут так сложилась ситуация.
Тут либо питание, либо винт, либо брак на плате, или ...
В любом случае необходимо осмотреть плату визуально, чтобы не оказалось, что там что-то инородное!

skyf1 писал(а):Интересно, что теперь 23 порт закрыт, открыты 80, 443, 554, 5000, 37777, что выглядит как живой DVR на дефолтных настройках.

Очень странно!!!
А почему телнет теперь на 5000 порту слушается? Что за прошивка-то стоит?
В PuTTY-то как и откуда заходил? Или это консольные логи?

skyf1 писал(а):~ # netstat -putan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:9989 0.0.0.0:* LISTEN 529/Challenge
tcp 0 0 127.0.0.1:9990 0.0.0.0:* LISTEN 529/Challenge
tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN 529/Challenge
tcp 0 0 0.0.0.0:554 0.0.0.0:* LISTEN 529/Challenge
tcp 74 0 127.0.0.1:45780 127.0.0.1:5000 ESTABLISHED 816/telnetd
tcp 0 0 192.168.1.108:34753 8.8.8.8:53 TIME_WAIT -
tcp 0 0 127.0.0.1:5000 127.0.0.1:45780 ESTABLISHED 816/telnetd
tcp 0 0 :::80 :::* LISTEN 529/Challenge
tcp 3 0 :::37777 :::* LISTEN 529/Challenge
tcp 0 0 :::23 :::* LISTEN 816/telnetd
tcp 0 0 :::443 :::* LISTEN 529/Challenge
tcp 1 0 ::ffff:192.168.1.108:80 ::ffff:192.168.1.51:49337 CLOSE_WAIT 816/telnetd
tcp 1 0 ::ffff:192.168.1.108:80 ::ffff:192.168.1.51:49338 CLOSE_WAIT 816/telnetd
tcp 0 440 ::ffff:192.168.1.108:23 ::ffff:192.168.1.51:49398 ESTABLISHED 816/telnetd
tcp 1 0 ::ffff:192.168.1.108:80 ::ffff:192.168.1.51:49339 CLOSE_WAIT 816/telnetd
tcp 1 0 ::ffff:192.168.1.108:80 ::ffff:192.168.1.51:49340 CLOSE_WAIT 816/telnetd
udp 0 0 0.0.0.0:36682 0.0.0.0:* 529/Challenge
udp 0 0 0.0.0.0:44387 0.0.0.0:* 529/Challenge
udp 0 0 0.0.0.0:3702 0.0.0.0:* 529/Challenge
udp 0 0 0.0.0.0:123 0.0.0.0:* 529/Challenge
udp 0 0 0.0.0.0:37778 0.0.0.0:* 529/Challenge
udp 0 0 0.0.0.0:37810 0.0.0.0:* 529/Challenge
udp 0 0 192.168.1.108:37810 0.0.0.0:* 529/Challenge
udp 0 0 239.255.255.251:37810 0.0.0.0:* 529/Challenge
udp 0 0 0.0.0.0:5050 0.0.0.0:* 529/Challenge
~ #

Обычно только 23 порт и то, в некоторых прошивках он уже прикрыт.
А раз тут еще, что-то, то значит может быть внешний фактор! Или.....

Спасибо за ответ.

Смотрим S.M.A.R.T. на регистраторе и логи, чтобы исключить...

логи остались или ушли, когда я выполнил
# rm rf /mnt/mtd/Config/
# rm rf /mnt/mtdbak/Config/
где они лежат?

в прочем не важно, потому что я каким-то образом заблокировал admin аккаунт.
ConfigTool говорит Login Failed. Account has been locked.
Доэкспериментировался, но фигня, бывает.

В любом случае необходимо осмотреть плату визуально

да, придется доставать, на днях, надеюсь, найду время, отпишусь

Что за прошивка-то стоит?

Файл прошивки DH_HCVR5x04-S2_Eng_P_V3.200.0004.6.R.20151123.bin (13 128 763 bytes)
Оно нормально работало достаточно долго, а после изменений (настроил 24/7 5fps + motion 16fps, была только запись по движению) начал глючить и загнулся. Потому я и грохнул конфигу.

Обычно только 23 порт и то, в некоторых прошивках он уже прикрыт.

Иногда, когда оживает веб, я пинаю его http ://<ip-address>/cgi-bin/configManager.cgi?action=setConfig&Telnet.Enable=true
Иногда он жив сам по себе, при этом остальные порты лежат. Теперь пинать не смогу, так как admin lockout.

А раз тут еще, что-то, то значит может быть внешний фактор

Например?

skyf1 писал(а):логи остались или ушли, когда я выполнил
# rm rf /mnt/mtd/Config/
# rm rf /mnt/mtdbak/Config/
где они лежат?

Так после удаления всё равно надо смотреть логи текущие и смотреть текущий СМАРТ

skyf1 писал(а):в прочем не важно, потому что я каким-то образом заблокировал admin аккаунт.
ConfigTool говорит Login Failed. Account has been locked.
Доэкспериментировался, но фигня, бывает.

Как правило 3 раза неправильно вошел и ... на 30 минут или до перезагрузки
Залоченный аккаунт можно разлочить через пароль локально на регистарторе.

skyf1 писал(а):Оно нормально работало достаточно долго, а после изменений (настроил 24/7 5fps + motion 16fps, была только запись по движению) начал глючить и загнулся. Потому я и грохнул конфигу.

Ну так сразу-то не должен загнуться.

skyf1 писал(а):Иногда он жив сам по себе, при этом остальные порты лежат. Теперь пинать не смогу, так как admin lockout.

Должен быть доступен всегда, а по питанию регистратор передернуть и должен будет доступен. Другие аккаунты есть?

Обычно достаточно одного 23-го порта слушаемого, а у тебя еще 5000? Откуда? Кто включает?

Дошли руки, залез в щит.
Питание замерил, потерь на линии нет, на DVR приходит столько же сколько на выходах БП 12.10В
Демонтировал, плату промыл спиртом и щеткой, хотя она и так была достаточно чистой.
Состояние не изменилось, WEB-морда работает, но так медленно, что ловит таймауты.
Т.е. я могу медленно залогиниться и зайти, а перейти на закладку настроек уже не получается.

Интересно, что ConfigTool'ом я его вижу, но Дахуа - умницы, когда открываешь Login, попадаешь
в настройки видео, а там фрейм с видеопотоком запускается автоматически, а так как железка тупит,
в результате таймаут вместо картинки, и на дальнейшие манипуляции - Device is offline.
Решил обойти тупняки, и попробовал Upgrade через Batch Mode, безрезультатно, не успевает начать процедуру,
отваливается. Интересно, что через Batch mode я могу сделать Batch modify IP, и оно работает, т.е.
проблема в том, что DVR работает, но реагирует с сильной задержкой, в результате чего таймауты и обрыв сессии.

Может попробовать порт 3800 служба upgraded, или это только на IPC или на новых прошивках? Не смог тут найти такую службу.

В общем рег на столе, сейчас буду пробовать подключить напрямую по HDMI и делать USB upgrade, если результатов не будет,
принесу USB to RS-232.

смотреть текущий СМАРТ

Его будет видно, когда подключусь по HDMI, отпишусь. Есть метод как его опросить удаленно?

Обычно достаточно одного 23-го порта слушаемого, а у тебя еще 5000? Откуда? Кто включает?

Как посмотреть кто запустил ту или иную службу?

Перепробовал многое из того, что нашел по форумам, а проблемой оказался и без того загибающийся винт,
который я добил включив запись 24/7.
До последнего не верил, что винт может так накренить систему, при этом ни разу не сообщив об ошибке.
Ни зуммеров, ни уведомлений, только полуживая железка, отзывающаяся по telnet, периодически пускающая по WEB,
но жутко тормозящая. Достаточно было скинуть шлейф HDD, а не 2 ночи искать как получить доступ и решить проблему удаленно.
Зато теперь я знаю как это делается! iTuneDVR, спасибо за экскурсию в софтовое нутро Dahua! Было очень интересно!