Комментарии 153
Обычно прошивка либо устанавливается вендором на заводе, либо приезжает через online сервис обновления.
Вот, например, апдейт для камер на hi3518: http://camera-updater.videocomfort.ru/agent/hi3518/prod/firmware/v1.0.1-155-gfe91e4a_hi3518_prod-b22307/firmware_v1.0.1-155-gfe91e4a_hi3518_prod-b22307.bin — (апдейты идут без uboot)
Вот, например, полный образ http://camera-updater.videocomfort.ru/agent/r2/prod/digicap_v0.9.8-89-gcf0ead1_hi3518_prod-b8641.dav для Hikvision VC1W
Не совсем. Камеры все же отличаются по железу (разные сенсоры, разные wifi модули, разные GPIO, разные DDR).
Поэтому, просто так установить не получится — необходимо, что бы прошивка знала специфику оборудования, и что бы в ней были необходимые дрова сенсора и wifi модуля.
Конечно очень хочется сделать одну прошивку, которая будет работать под всеми 3518, 3516 и 3519, но пока, судя по всему, нет даже способа программно определить разные сенсоры. Т.е. прежде чем заливать прошивку, надо точно знать, какой там сенсор.
Это как если бы надо было точно знать, какой линукс скачивать под распаянный на материнке жесткий диск, учитывая, что нет програмного способа его сдетектировать.
Грустно.
Ну мы выкручиваемся так: код модели камеры зашита в разделе env, а в самой rootfs есть реестр поддерживаемых моделей и описание оборудования которое соотвествует этой модели.
А kernel+rootfs и application универсален для всего семейства чипов.
А так да, никакого плаг & плэй (
Я не оставляю надежду на то, что общением через i2c получится хотя бы косвенными способами угадать сенсор.
Иногда можно, но не всегда поможет.
Даже один и тот же сенсор может быть подключен по разному схемотехнически в разных камерах. А от этого зависят настройки режима захвата видео…
Кроме этого узнать к каким GPIO подключены светодиоды/кнопки/IRLed/IRCut — вообще не возможно впринципе...
Единственное — wifi чип можно опознать по USB vid/pid, и то если он подключен по USB, а не по SDIO.
Кроме этого узнать к каким GPIO подключены светодиоды/кнопки/IRLed/IRCut — вообще не возможно впринципе...
На самом деле GPIO возможно определить простым перебором, приходилось несколько раз такое проворачивать, когда вендор не давал даташит на плату.
У hisi 351x порядка 100 GPIO выводов.
Мы для поиска задействованных GPIO разработали специальную утилиту, которая умеет
а) выводить какие GPIO переведены в режим OUT, при запуске на стоковой прошивке, это сужает круг поиска выходов, к которым подключены светодиоды и IRCut
б) выводить состояния всех входов GPIO подключенных к процессору.
Во времена, когда не было поддержки вендоров — это очень помогало.
В традиционных решениях 'прошивка вендора + облачный плагин', которые не могут работать на дешевом железе, видео внутри камеры передается по протоколу RTSP — а это огромный оверхед: копирование и передача данных через socket, лишние syscall-ы.
Мы в этом месте используем механизм shared memory — видео не копируется и не пересылается через socket между компонентами ПО камеры, тем самым оптимально и бережно используя скромные аппаратные возможности камеры.
Т.е. RTSP вы убрали совсем и камеру иначе как с вашим сервисом использовать не получится?
…
> В традиционных решениях 'прошивка вендора + облачный плагин', которые не могут
> работать на дешевом железе, видео внутри камеры передается по протоколу RTSP — а это
> огромный оверхед
какие например? Очень интересно, как можно сделать _огромный_ оверхед на проксировании RTSP внутри камеры. У нас сделать огромный не получилось, наш агент для облака работает на камерах от $8 с шифрованием, проксированием и очень несложным процессом адаптации вендорской прошивки. По крайней мере он сильно проще, чем портирование целой прошивки под очередную комбинацию сенсор+чип+всё остальное.
>Наиболее уязвимый момент — перезапись раздела с ядром Linux и корневой файловой системой.
Угу. Поэтому её вообще часто не трогают никак. У вас прикольно получилось.
какие например? Очень интересно, как можно сделать огромный оверхед на проксировании RTSP внутри камеры. У нас сделать огромный не получилось, наш агент для облака работает на камерах от $8 с шифрованием, проксированием и очень несложным процессом адаптации вендорской прошивки. По крайней мере он сильно проще, чем портирование целой прошивки под очередную комбинацию сенсор+чип+всё остальное.
Ваш комментарий противоречит вашей же статье: https://habr.com/company/erlyvideo/blog/334912/,
в которой вы пишете, что работаете с железом напрямую, получая из железа кадры, и что сделали прошивку на Rust.
По существу: вендоров — огромное количество, адаптироваться под прошивку каждого с учетом осбенностей каждой модели — это очень ресурсоемкий процесс. Чипсетов намного меньше.
Про оверхед — когда всего 38МБ ОЗУ — любые лишнее буфера, которые требуются для "проксирования" — это существенный оверхед. Когда у процессора всего 400MHZ каждый syscall с копированием данных, да это существенный оверхед.
Угу. Поэтому её вообще часто не трогают никак. У вас прикольно получилось.
Т.е. rootfs на обновляют вообще? Как так — в ней находятся системные компоненты, типа dropbear, wpa_supplicant, busybox и т.д.
Что делать, когда в намертво прошитой версии wpa_supplicant или dropbear обнаружится уязвимость?
По нашему опыту поставить агента на 400 Мгц камеру с проксированием через TLS — не проблема. Ни с памятью, ни с процессором.
> Что делать, когда в намертво прошитой версии wpa_supplicant или dropbear обнаружится уязвимость?
по мнению длинного ряда производителей — забить длинный китайский болт на это и выпустить новую камеру, у которой телнет с беспарольным рутовым логином.
Ну тут такое. Такая конфигурация действительно работает (у нас тоже в варианте с наш плагин+прошивка вендора).
Но, если, например битрейт потока большой, и паралелльно захватывается и пишется на флешку другой поток, то проца и памяти уже может не хватить — и тут как раз вспоминаем про оверхед на RTSP.
Кроме этого в схеме без RTSP высвобождаются дополнительные ресурсы процессора, но более продвинутые аудио и видео аналитики, на которые с RTSP не хватало ресурсов.
Вот только что перепроверил нашего агента на Hiwatch DS-I114:
Mem: 62076K used, 3092K free, 0K shrd, 5372K buff, 38344K cached
CPU: 10.3% usr 10.9% sys 0.0% nic 75.9% idle 0.0% io 0.0% irq 2.7% sirq
Load average: 11.81 8.36 3.98 1/149 736
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
327 1 admin S < 234m367.3 0 16.9 /home/davinci
728 323 admin S 1736 2.6 0 4.4 /home/peeklio -c /devinfo/peeklio_
603 2 admin SW 0 0.0 0 0.7 [RTW_CMD_THREAD]
39 2 admin DW 0 0.0 0 0.5 [kworker/u:1]
16 2 admin SWN 0 0.0 0 0.4 [ksmd]
порядка 4%
# cat /proc/cpuinfo
Processor : ARM926EJ-S rev 5 (v5l)
BogoMIPS : 218.72
Features : swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 5
Hardware : r2
Revision : 0000
Serial : 0000000000000000
64 MB памяти.
Основное потребление, которое может быть — сетевой буфер для компенсации колебания скорости сети.
Основное CPU time из за RTSP, думаю уходит на davinci, когда он пишет в сокет (write существенно прожерливее, чем read) — а davinci кушает 16% CPU.
R2 кстати не самая бюджетная платформа. У нее 3518С + 128 MB ОЗУ на внешнем DDR, что, кстати, заметно увеличивает стоимость.
Вот самый треш на 3518E, которые используются на бюджетных ezviz-ах и hiwatch — у них 64 MB ОЗУ, из которых 26 отдано под видеоядро.
На них davinci выедает практически всю память...
А под Hiwatch DS-I220 имеется решение? Камера практически идентична Hikvision DS-2CD2042WD-I, модули взаимозаменяемы.
На такой модели мы не пробовали. Но думаю никаких принципиальных проблем с ней быть не должно.
Да я вообще сильно удивился, когда узнал что эта камера без поддержки ivideon. Столько раз они служили донорами запчастей для более дорогих 2042… честно считал их идентичными, но в ivideon считают не так. Было бы замечательно запилить поддержку для этих камер, ведь по характеристикам они идентичны 2042, за исключением модуля ivideon.
Не могу дать точный ответит за коллег из ivideon, о причинах отсутствия поддержки.
Могу лишь предположить, что проблема в том, что с завода i220 идут с новой прошивкой, например 5.5.5, а ivideon еще не успел портировать плагин под эту прошивку…
А downgrade на более раннюю прошивку с плагином, которая бы заработала — заблокирован.
А сколько у нее RAM? Насколько мне известно, для hikvision камер с 64MB ОЗУ интеграция способом 'прошивка вендора + плагин' практически не возможна, из за причин перечисленных в статье...
dmesg
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.10.73+ (zhangjianzhong@Cpl-Frt-BSP) (gcc ?? 4.8.2 20130902 (prerelease) (crosstool-NG - Ambarella Linaro Multilib GCC [CortexA9 & ARMv6k] 2013.09) ) #12 PREEMPT Thu Jul 20 11:10:40 CST 2017
[ 0.000000] CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), cr=10c53c7d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine: Ambarella S2L (Flattened Device Tree), model: Ambarella S2LM Kiwi Board
[ 0.000000] dev type:0x0
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] Ambarella: AHB = 0xe0000000[0xe0000000],0x01000000 0
[ 0.000000] Ambarella: APB = 0xe8000000[0xe8000000],0x01000000 0
[ 0.000000] Ambarella: PPM = 0x00000000[0xdfe00000],0x00200000 9
[ 0.000000] Ambarella: AXI = 0xf0000000[0xf0000000],0x00030000 0
[ 0.000000] Ambarella: DRAMC = 0xdffe0000[0xef000000],0x00020000 0
[ 0.000000] Ambarella: DBGBUS = 0xec000000[0xec000000],0x00200000 0
[ 0.000000] Ambarella: DBGFMEM = 0xee000000[0xee000000],0x01000000 0
[ 0.000000] Ambarella: IAVMEM = 0x07000000[ ],0x09000000
[ 0.000000] On node 0 totalpages: 28160
[ 0.000000] free_area_init_node: node 0, pgdat 807d48f8, node_mem_map 80805000
[ 0.000000] Normal zone: 220 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 28160 pages, LIFO batch:7
[ 0.000000] CPU: All CPU(s) started in SVC mode.
[ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 27940
[ 0.000000] Kernel command line: console=ttyS0 KRN_PRT=pri
[ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Memory: 110MB = 110MB total
[ 0.000000] Memory: 103364k/103364k available, 9276k reserved, 0K highmem
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] vmalloc : 0x87000000 - 0xff000000 (1920 MB)
[ 0.000000] lowmem : 0x80000000 - 0x86e00000 ( 110 MB)
[ 0.000000] modules : 0x7f000000 - 0x80000000 ( 16 MB)
[ 0.000000] .text : 0x80008000 - 0x80502750 (5098 kB)
[ 0.000000] .init : 0x80503000 - 0x80793bd4 (2627 kB)
[ 0.000000] .data : 0x80794000 - 0x807dc690 ( 290 kB)
[ 0.000000] .bss : 0x807dc690 - 0x808002b0 ( 144 kB)
[ 0.000000] NR_IRQS:240
[ 0.000000] sched_clock: 32 bits at 54MHz, resolution 18ns, wraps every 79536msПодозреваю что У DS-I220 меньше 110 mb, но что либо утверждать не могу, попробую поискать прошивку по-свежее, может тогда она отчитается.
Судя по логу — это вообще R6, на базе чипа ambarella.
R6 это название программно-аппаратнатной платформы камер Hikvision на чипах Ambarela S2LM.
Про i220 увы, подсказать не могу — не доводилось сталкиваться.
DS-2CD2042WD-I — Hikvision R6 серия камер.
Все разбирается по прошивкам и собирается ;)
Цель-то по итогу какая, что туда внедрить какой свой модуль?
Слабо, там и ли нет, но на R2 таких работает spacecam и не жужжит, также надавно мне flusonic делал прошивку под подобную камеру с их агентом.
Они добавляют своего пользователя с хитрым паролем и он получает доступ к видео.
Раньше было проще, т.к. пароль в базе был в открытом виде и ivideon его юзал на R0 серии.
В свое время было сделано с костылями для новых R0 и R2 их клиенты.
Не знаю, что там предлагают в ivideon по этому поводу, но
если захотят и не будут ленится то сделают, но крови попьют, а раз ты привыкший то… ;)
Все технические нюансы можно решить. ;)
Хотя есть же их софтовое сервер-приложение которое подключает любые камеры и транслирует, ну не мне объяснять…
В любом случае надо будет решить вопрос с лицензиями, а официально цена вопроса для обычных пользователей — волосатая…
Но, как и говорил, при определенных условиях и отсечение лишнего вполне возможно поднять встроенный сервис на R2 серии, но…
Тема не вчерашняя…
Если не решен вопрос с лицензиями, то все остальное беЗполезно.
Почему не устраивает вариант iVideon Server?
Да, понимаю, что удобней будет сразу, и без лишних проблем и завязок, но я не встречал адекватных вариантов, хотя обращались многие по поводу изготовления или готовой прошивке, но у всех желание отбивала цена за лицензию ivideon.
В любом случае нюансов много, и получится так, что сделать можно, но прошивка старая и,… а на новой или специальной надо кое-что допиливать до полноценного.
Как написано выше, если есть много свободного времени, непреодолимое желание оптимизировать свои затраты и пристроить имеющуюся технику, то все возможно.
Сторонние инструменты не рекламирую, чтобы не породить вопросов, а как ими пользоваться. Своими пользуюсь сам и не задаю никаких вопросов. ;)
ZigFisher ведет работу над похожим открытым решением на базе openwrt!
zftlab.org/pages/2018020900.html
github.com/ZigFisher/chaos_calmer
github.com/ZigFisher/Glutinium
Группа общая по модификации прошивок: t.me/joinchat/FhtyHxDpQsv8HlRliQDgqw
Группа по разработке прошивки на базе openwrt: t.me/joinchat/FhtyHwrU0fwfQlAkvoeVJA
Пытаемся привести китайские ядра из sdk от разных чипов разных ревизий (hi3516c, hi3518e, hi3520d) к какому-то одному и вынести в конфиг то, что разработчики захардкордили через #define. А то собирать слишком много и долго) Инициализация библиотек сенсоров, конфиг драйвера ethernet, но пока с переменным успехом… Работа идет, но не хватает скилов, а еще больше времени!
Если кто-то хочет попробовать собрать и запустить, то подготовил сборку прошивки и ядер в докере: github.com/chertov/camopenwrt_docker
Очень буду рад если кто-то присоединится, поможет, проявит интерес)
На данный момент смогли запустить открытую прошивку, получили изображение в виде jpg, сжатые фреймы в h264, тестовый поток rtsp. Фактически просто причесали китайскую демку. Сейчас все это прилично глючит и факт успешного запуска на произвольной камере зависит от погоды на луне) Если интересно, то в группах могут подсказать конкретные бюджетные модели плат чип+сенсор+провода или целиком камер.
Исходники на базе китайской демки тут github.com/ZigFisher/Glutinium/tree/master/hisi-sample/src
А еще мы собрали gstreamer последней версии с поддержкой webRTC! Попробуем построить p2p стриминг видео на его базе сразу в браузер или на мобилки.
Авторы статьи молодцы, качественное решение в сфере видеонаблюдения давно необходимо!!! Это как раз одна из причин появления открытого проекта! Железо в камерах еще ничего, но софт просто ужасен… естественно очень бы хотелось посмотреть на Ваш вариант модификации кода загрузчика и ядра, код uboot и ядер вроде же под GPL, китайцы его поставляют в составе sdk.
Также в свободное время пилю небольшой сервис для проброса ethernet, uart, spi (для перепрошивки флеш памяти камеры) и gpio (управление питанием камеры) на машины разработчиков или в контейнеры CI через облако. А то (лично мне) с железом не очень-то и удобно работать, тем более когда камер много…
Хотелось бы дать возможность сообществу шарить свои камеры разработчикам и системе тестирования и т.д!
не надо так. Берите младшие 5 бит, у SPS номер 7, а не 67.
Класс! Спасибо за ссылки на чатики сообщества.
Идея сделать универсальное ядро под hisi — огонь, но не представляю как его дружить с модулями отвечающими за видеозахват. Они в SDK идут без исходников, и ооооочень большая вероятность, что они просто не заведутся на свежем ядре.
Показать наши патчи ядра и uboot — не проблема (хотя они на самом деле минимальны — не думаю, что от них будет какая то польза )
Проект с удаленым доступом к железу — интересная история, мы тоже ± работаем над похожей задачей. Будет интересно посмотреть, что у вас получается.
На свежем ядре можно собрать универсальную прошивку, но толку от неё будет мало, т.к. действительно, имеющиеся только в бинарном виде драйвера для видео работать не будут.
Олег молодец!
Надеюсь разработчиков не обидели ;)
И на момент старта разработки целесообразно работать только с 1-ним вендором, что бы сосредоточить усилия команды на разработке логики работы с облаком.Дальше не читал потому что мои 2-ва глаза выпали.
Приложения сейчас называются "Умный дом ростелеком" и "Видеонаблюдение ростелеком". ссылки поправим — спасибо!
Мы это — Рестрим, дочка Ростелекома.
Нет. Судя по описанию у нее чипсет Grainmedia 8135S, мы пока его не поддерживаем.
Можете что-то подсказать? А если у вас получится и эту камеру перепрошить — обязательно сообщите, деньги заплатим :-)
Имеется ввиду, что можно взять hikvision 3518 вместо аксиса и получить рабочее решение под определенные задачи.
Но есть сильное подозрение, что на GM (grainmedia) может и не получится сделать приличного решения под какую-либо задачу.
Было и на GM и на чем-то ещё. Посмотрю, чего есть.
Хороший у вас робот — мне понравился :)
На ali есть широкий выбор недорогих и маленьких PTZ камер ± похожих по дизайну (например такая)[https://ru.aliexpress.com/item/Lintratek-HD-1080-P/32841830056.html]. Но по картинкам и спекам затрудняюсь сказать про то, на каком они чипсете, и насколько хороши.
Ну в данном случае перепрошить — означает разработать прошивку для этого чипсета. В это входит как портирование видеоприложения (наиболее сложная задача), так и подготовка системы сборки ядра/рутфс.
У нас вот пока таких планов нет — лично я не видел ни одной камеры на GM, которую было бы не стыдно предложить клиентам…
Если на GM появятся более менее приличные по потребительским свойствам камеры — то с удовольствием посмотрим на них более серьезно.
Там у меня в ссылках была подборка различной инфо, в том числе о SDK и RTSP демоне на GitHub
Да, работаем. У нас есть поддержка динамика (Push-To-Talk) функционал. Есть поддержка PTZ (тут важна модель камеры, т.к. аппаратно механизм управления моторами сильно отличается от камеры к камере).
Датчик звука так же есть, это по сути "аудио-аналитика" — модуль в приложении, который мониторит уровень звука на микрофоне, и при превышении порога отправляет событие в облако.
Мы пользуемся облачным сервисом видеонаблюдения TRASSIR Cloud: cloud.trassir.com
С ним работaют камеры от 2990р. www.citilink.ru/catalog/photo_and_video/video_observation/cctv_cams/1030858
olegator99 будет ли ваша прошивка с этими камерами работать?
Кстати, и для камер HiWatch у них вроде тоже есть облачная прошивка: www.dssl.ru/support/tech/support_ip/cloud.php
Спасибо за ссылку.
Если я правильно понял, то что бы работать с ivideon нужна отдельная железка для запуска ivideon сервера
И итоговое решение будет стоит 1451р + (стоимость железки для запуска ivideon сервера)...
Да, подойдёт Неттоп.
Судя по яндекс маркету минимальная цена на неттоп — 5т.р. итого возвращаемся к решению за 5т.р.+ :)
нафиг даже с серым IP все легко и просто решается и такие прокладки как говнодеон и его клон от рт нафиг не нужны. Лет 10 как своё все работает успешно:
любой говнороутер с прошивкой опенврт, любой опсососвский модем, пара аккумуляторов, бп и говнокамера любая. И всё отлично пашет. За доллар в месяц любой говнохостинг, на котором openSSH развернут. И всё.
У нас два дома рядом, без забора.
В одном — я, моя жена и ребенок.
В другом — мои родители, сестра, её муж и дети.
У нас общая локальная сеть. У нас общая система видео наблюдения.
НАстроен сервер на Linux + ZM. Проложены IP камеры.
Я слежу за этим хозяйством.
Завтра я уехал/умер.
Что будет?
Пол года, может год система проживет в лучшем случае без вмешательства. Дальше — гикнется один из винчестеров на сервере, или обновление уронит систему, или сервер отключат и не смогут включить.
И что делать?
Админа нанимать?
А с облачными камерами — работают и работают. В локалку их воткнул, по инструкции настроил и ОК. Если что-то сломалось — пишешь в саппорт. Решаешь проблему. Сломалась камера — выкидываешь, и ставишь новую вместо неё. Любой справится.
Могли бы вы объяснить как можно получить образ Linux свой кастомный (под определённое железо). Как получить 3.5 МБ размер? Есть какие-нибудь туториалы?
1) Из конфига ядра убрано определённое количество фич в сравнении с конфигом от вендора, которые мы не используем, и которые не влияют на работоспособность.
2) Все shared libraries (и всё что можно безболезненно) мы стрипаем. Это также рекомендует linuxfromscratch:
www.linuxfromscratch.org/lfs/view/stable/chapter05/stripping.html
3) В само ядро мы включаем rootfs: урезанный busybox (дефолтная поставка тоже занимает место). Сама rootfs ужимается с lzma и подключается как initramfs, как написал Олег в статье.
Сорян, а зачем каждый раз покупать новые камеры на выборы? Что мешает использовать камеры с прошлых выборов или например с егэ? Отсутсвие отката?
Тут такое — на самом деле во многих избирательных участках оставались старые ПАК (ноуты с вебкамерами, еще с выборов 2012 года). Они уже морально и физически устарели — сыпались по просту. Все же 6 лет прошло. В основном их меняли.
P.S. Ну вообще я за технику отвечаю, вопросы про закупки и прочее с этим связанное — это не ко мне.
camera.rt.ru — на нем сейчас практически полный спектр моделей Hikvision
smarthome.rt.ru — тут сейчас только Hikvision vc1w, который достаточно дорогой и на запуске сервиса использовался вариант прошивка Hikvision + наш плагин, а сейчас мы их переводим на нашу прошивку.
В скором времени +9 моделей начиная от бюджетных моделей на 3518E, с 64MB ОЗУ
Ребята написали удачный миниатюрный плагин, при помощи которого интегрируют к себе на сервис камеры различных производителей железа (в том числе «отвёрточных») и по-этому процесс интеграции быстр, лёгок, а так-же может быть протестирован практически на любом железе путём записи плагина в RW раздел, в котором сохраняются настройки камеры. Прайсы этой компании я обсуждать не буду, но бесплатный тариф на просмотр видео с камеры, стоящей далеко и за NAT-ом, крайне радует меня и друзей-гиков. Родное встроенное китайское облако выключено и забыто как страшный сон.
Еще забыл выше упомянуть, что помимо экспериментов с OpenWrt потихоньку развивается тема и «моддинга» прошивок для XM, JVT, Topsee и прочих производителей видеокамер бюджетного сегмента.
Я-же говорю всего-лишь как это сделано технически (про плагин).
Ссылки на прошивки под популярные типы плат XM я привёл выше.
Покупайте плату на Алиэкспесс, заливайте прошивку — и в облака ;)
Сильно язвить Вам, думаю, не стоит, так как скорее всего Вы даже не читали какие эксперименты проводятся и какие цели преследуются в этих тестовых сборках прошивок, а вот показать или рассказать присутствующим на Хабре о своих, как я понимаю более перспективных и взрослых разработках связанных с Webrtc, дело достойное не мальчика, но мужа…
Вариантов облачных наблюдений сейчас уже мешочек разных на самом деле. Просто ipeye своим маленьким демоном гармонично вписался в подборку нашего проекта, а основная суть моего рассказа была в том, что его можно запустить даже не меняя родную прошивку на камере, вот и всё. Если есть возможность сменить прошивку — естественно, все эти разработки становятся ненужны автоматически.
Процессор HI3518EV200, сенсор Aptina AR0130, а внутри — не Linux
System startup
U-Boot 2010.06 (Mar 28 2016 — 09:55:50)
Check Flash Memory Controller v100… Found
SPI Nor(cs 0) ID: 0xc2 0x20 0x17
Block:64KB Chip:8MB Name:«MX25L6406E»
SPI Nor total size: 8MB
SPI Nand ID Table Version 1.4
MMC:
EMMC/MMC/SD controller initialization.
Card did not respond to voltage select!
No EMMC/MMC/SD device found!
*** Warning — bad CRC, using default environment
In: serial
Out: serial
Err: serial
*No SD card found!
No mmc storage device found!
Hit any key to stop autoboot: 0
8192 KiB hi_fmc at 0:0 is now current device
## Starting application at 0x80008000…
********hello HuaweiLite OS ARM926********
version: HuaweiLite OS KernelV100R002C00B013
open-version: HuaweiLite OS 1.1.1RC
build data: Mar 11 2016 09:45:30
**********************************
losAppInit
porc fs init…
Mount procfs finished.
random init…
uart init…
shell init…
HuaweiLite OS # <= та-дам!
OMG! А с wifi то у нее как? (сходу не нашлось ничего про него в исходниках)
Это простейшая бюджетная плата JVT-S130.
Это я к тому, что потенциально надо быть готовым к таким вот фортелям фортуны.
Хотя вам тут и карты в руки как раз — накатить вашу OS можно попробовать.
Вряд ли что-то новое изобрели вот так совсем с нуля пренебрегнув все опытом, что есть. Все равно на камне hisilicon известном, ведь так?
Вот была тему а Dahua, когда появились камеры да другом процессоре отличном от Ti или Hisilicon, при это прошивка примерно выглядит также, так же разбирается, но ни инструментов ни что-то подсобрать кода, пропатчить бинарь или вклинить вот так кроме как скрипты в шеле хоть не тронули.
«Просто» пересобрали готовый проект под другой процессор, не распространенный ;)
Потому свой проект и затеял ТС, чтобы не быть так скажем в рамках известного железа не быть ничем и никем связанным.
То, что для v200 не подходит (ни загрузчик, ни ядро).
Пока с таким железом не сталкивались. И SDK под него тоже пока нет.
Какой то мега дешман. На видеоядро 10-16М по минимуму уйдет. 16м на линукс, инитрамфс и все аппы — выглядит слабореалистично.
А портироваться под хуавейос — что то сомнительное мероприятие.
Уж лучше на GM или Fullhan посмотреть, у них хотя бы по 64М и полноценный линукс
Из GrainMedia знаю и имею только GM8136S, с Fullhan дела не имел.
Я с ними детально тоже не разбирался. Видел несколько дешевых китайских плат на GM8136 — общее впечатление от качества (и картинки и сборки) было удручающим. Посмотрел на GM8136 SDK — в принципе более менее адекватное.
А на Fullhan видел Ezviz C2 Mini O, вполне себе неплохая модель. Но мы решили, что из за одной модели портироваться под Fullhan не целесообразно.
Кстати, что удивительно — AR0130 весьма неплохой сенсор. На мой вкус заметно лучше ov9712 распространенного в ultra low сегменте.
Лог ядра с оригинальной прошивкой.
...
<6>[ 2.198596] Fixed MDIO Bus: probed
<6>[ 2.317521] r2_mii: probed
<6>[ 2.430600] PHY r2_mii:03 found : id is : 0x1cc816
<6>[ 2.436090] rtl8201f_set_EEE: set eee capability successfully
...
<6>[ 4.431208] PHY: r2_mii:03 - Link is Up - 100/Full
<6>[ 4.431452] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
...
При загрузке ядра, собранного для hi3516a получается:
...
Fixed MDIO Bus: probed
himii: probed
...
PHY: himii:03 - Link is Up - 100/Full
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Но сеть не работает.
По хорошему желательно весь трафик по MDIIO задампить и повторить, если дело только в phy. Но возможно какая-то ключевая инициализация проходит еще в u-boot или u-boot SPL части например включение для MAC RGMII/RMII режима. BTW почему-то по опыту не редко натыкаюсь на ошибки в u-boot инициализации MAC контроллеров или передачи параметров в ядро даже у уважаемого мной motorola AKA freescale AKA NXP.
Так флеш памяти не хватит постоянно держать два ядра.
А в момент записи ядра на флешку необходимо, что бы уже было записано второе, гарантированно не поврежденное ядро
[uboot][env][old kernel+rootfs][old app][config] ->
[uboot][env][old kernel+rootfs][new kernel+rootfs][config] ->
[uboot][env][new app][new kernel+rootfs][config]
В этой схеме избыточности нет и экономится ресурс флешки. Кроме того ничего не мешает (кроме необходимости модификации uboot, которая итак есть) разделам [kernel+rootfs] и иметь [app] разные размеры.
А в смысле при каждом обновлении менять разделы местами — да, так можно. Но в самой прошивке прийдется обрабатывать два разных режима. Чуть менее детерминированно получается. Ну и по размеру в этой схеме есть требование: kernel не должен быть больше app (у нас в общем требование такое же по большому счету)
А еще, есть ли у нее внутри Ethernet PHY, чтобы превратить ее в проводную?
простите, а с чего начать?
вот у неё порты открыты, как попасть в шелл? что читать в целом?
nmap 10.254.3.84
Starting Nmap 7.80 ( https://nmap.org ) at 2023-03-26 09:19 MSK
Nmap scan report for 10.254.3.84
Host is up (0.00079s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
80/tcp open http
554/tcp open rtsp
8000/tcp open http-alt
8899/tcp open ospf-lite
MAC Address: 00:12:33:22:CC:EE (JRC Tokki)
Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds
Олежки с нами нет, но мы о нем помним!
Начать нас оценки своего опыта и от полного понимания поставленных перед собой задач, а не хотелок.
Зачем нужен шел или это проверка на ИБ, аудит возможных векторов атак и т.п.?
Или нужно туда внедрить свой процесс, чтобы на борту что-то дополнительно делал?
Если идти с открытых портов 80, 554, для камер и оборудования XM, если это оно судя по по 8899 порту, то это задача на проникновение с попыткой эксплуатации разных уязвимостей. С шелом там возможно почти никак, иначе бы за такой большой период, более 10 лет, уже бы было море примеров, но их нет.
Если идти со стороны прошивки, то это ее пересбор или танцы с загрузчиком.
С загрузчиком, нужно принудительно внести нужные переменные, чтобы получить лог старта и работу консоли и зная что стоит за хэшем в консоли можно получить шел или попытаться загрузиться в single режиме.
С пересборкой, в стартовых скриптах нужно добавить запуск правильных процессов, которые бы не убивались и в зависимости: телнет или ssh(dropbear), на сколько место хватит, сделать свои правки со своим хешем. Заливать изменения разными способами можно.
Есть еще утилиты открывающие телнет, но они разных версий и работают не со всеми прошивками, потому нет гарантий, что откроется.
- Исправлены ли уязвимости WPA2,
- шифруется ли и каким-образом трафик до серверов видеокомфорта,
- в каким виде видео хранится на серверах видеокомфорта,
- каким образом доставляется с серверов до мобильного приложения видеокомфорта,
- сотрудничает ли видеокомфорт с правоохранительными органами/ФСБ.
Ну и да сами знаете нужно иметь титановые яйца чтобы доверять какую-либо персональную/личную информацию ростелекому, а точнее их дочке.
Как мы научились подключать китайские камеры за 1000р к облаку. Без регистраторов и SMS (и сэкономили миллионы долларов)