Всем привет !
С наступившим !

Насчет "мани бак", я конечно пошутил, а вот на счет "али как", хотел бы привлечь ваше
внимание, в особенности службы поддержки !

Итак, все началось летом, жена поставила задачу - обеспечить видео наблюдение дома,
дабы контролировать чем няня с ребенком занимается в наше отсутствие. Покупать
готовые системы не хотелось, т.к. они в основном кабельные, сверлить дыры в стенах
свежесделанного ремонта тем более. Вот тут то я подумал про wifi, тем более что супер
качества нам не надо было. Остановился на 933L, видео приемлимое, звук пишет, в онлайне
посмотреть можно, купил 4 штуки. И все бы ничего, пока не настала осень и не появилась
новая прошивка, на тот момент - 1.01b07, сразу меня эта буква "b" засмущала, уж не бета ли ,
и не зря, как оказалось. После влития сего фирмваря в одну из камер, стали с ней происходить
страшные глюки, сейчас расскажу подробнее ...
Как я говорил, в моей конфигурации все камеры работают через wifi на точку доступа "N" стандарта,
на всех камерах адреса статические, качество сигнала приемлимое (хотя, сами понимаете, что может
меняться в панельном муравейнике, где AP есть в каждой квартире), сброс видео происходит на FTP
по детекртору движения и звука, параметры видео приводить не буду, они не важны, почему, поймете позже.
А теперь о страшном глюке - камера стала сбрасывать косячные авишники на ftp (не сразу, минут через
10 работы). Внимательное изучение сих видео фрагментов показало очень интересную особенность, а именно,
если посмотреть в нормальный AVI файл камеры, то в самом начале увидим сигнатуру: RIFF, в битых файлах в начале
эта сигнатура отсутствует, НО, она встречается в середине файла! Теперь внимание, берем 2 таких файла,
назовем их текущий и предыдущий, ищем в предыдущем сигнатуру, отрезаем в файле первую половину до сигнатуры,
берем текущий файл, отрезаем вторую половину (вместе с сигнатурой), а теперь склеиваем предыдущий и текущий
файлы, и что вы думаете ..., правильно, получился нормальный AVI !
Складывается впечатление, что съехала крыша у какого-то кольцевого буфера в камере. Что ж явилось причиной
такой ошибки ща расскажу и покажу

К стати, если есть желающие повторить мои эксперименты, милости просим,
т.к., чем нас больше, тем быстрее ошибку исправят, я встречал на нескольких форумах посты с подобными проблемами,
но с другими моделями камер.

И вот наступили праздники, заняться чем то надо, не пить же неделю, вспомнил про проблему прошивки,
решил копнуть поглубже, как говорил мой школьный физик - давай будем думать. Ранее я говорил,
все камеры работают через wifi, у большинства обладателей сих изделий подключение проводное,
и таких проблем не наблюдается, напрашивается вывод - виноват wifi интерфейс. Но, если хорошо подумать,
то приходим к выводу, что этот самый "кольцевой буфер" обслуживает приложение, которое пишет в сокет (при
трансфере на ftp), и ему фиолетово, как дальше будут передаваться данные, хоть азбукой морзе через
телеграфиста. А теперь давайте подумаем, чем wifi оличается от ethernet, в основном 2-мя вещами,
первое - может перерегистрироватся, если сигнал ниже плинтуса упал,
второе - задержки (сосед решил порнушку посмотреть)
А теперь давайте перенесем эти условия на Eth !
Отключаем в камере wifi, втыкаем медный хвост, пляшем перед камерой, чтоб детектор движения сработал,
смотрим в каталог ftp файлы приходят, все в порядке.

Иммитируем первый случай. Что такое перерегистрация wifi - это фактически down/up интерфейса. Выдергиваем
хвост из камеры, пляшем, втыкаем назад, смотрим в каталог ftp - файлы приходят, все в порядке (за исключением
тех фрагментов, которые камера не скинула по причине отсутствия сети). Ммда, пятой точкой чую что то тут не так,
а именно, в момент обрыва eth не было активных tcp сессий на ftp сервер, так не интересно, но как же их
поймать, файлы то быстро сбрасываются ...,правильно, надо зарезать полосу на ftp data. Благо у меня ftp на линуксе
там полосу нарезать как 2 пальца об асфальт, самое простое решение:

iptables -A INPUT -p tcp -s 192.168.8.61/32 --dport 20 -m limit --limit 50/second --limit-burst 200 -j ACCEPT
iptables -A INPUT -p tcp -s 192.168.8.61/32 --dport 20 -j DROP

192.168.8.61 - адрес камеры. Такая конструкция дает примерно 70-80 Кб/c, это 15-20 секунд продолжительность сессии,
чего вполне достаточно.
Запускаем команды, пляшем перед камерой, смотрим как медленно растер размер файла в ftp каталоге, выдергиваем
хвост из камеры (в момент активной сессии, естественно), считаем 1,2,3,4,5, вышел зайчик погулять,
вставляем хвост в камеру, в ftp видим недокачанный файл с нормальным заголовком, размер которого уже не изменится,
снова заставляем работать детектор движения, дабы пошел новый сброс, и, ОППА !!! А файлы то битые передаются
И так будет до конца жизни камеры, пока ребут ее не настигнет.

А вот еще фокус, не будем вообще трогать хвост камеры, рассмотрим второе отличие wifi от eth - задержка.
Ребутим камеру. Считаем что полоса у нас уже нарезается (2 команды выше), пляшем перед камерой,
смотрим в фтп каталог, трансфер начался, а теперь - ловкость рук, даем такую команду:

iptables -I INPUT -p tcp -s 192.168.8.61/32 --dport 20 -j DROP;sleep 5; iptables -D INPUT 1

Т.е., фактически создаем 5-ти секундный таймаут. А результат такой же как в первом случае - крышу снесло.
А можно еще вот так, результат будет тот же, но за более короткое время:

iptables -I INPUT -p tcp -s 192.168.8.61/32 --dport 20 -j REJECT;sleep 1; iptables -D INPUT 1


Ухх, устал писать, а вы, наверное читать, так что к перейдем выводам,
а они такие - в глюках камеры интерфейсы не виноваты, виноват тот программный модуль,
у которого при обрыве активной TCP сессии (принудительной или по таймауту - не имеет значения)
в момент передачи файла сносит крышу.
И последнее, свежий фирмварь - 1.02b05 страдает точно такой же болезнью,
а вот самый первый - 1.00b14, как я не мучал, ведет себя стабильно, к стати,
отличия в процедуре сброса файлов явно произошли, т.к. в 1.00b14 камера не регулировала скорость передачи,
насколько канал позволяет, настолько и разгоняла, а вот начиная с 1.01b07, скорость не превышает 1Мбайт/c,
для wifi это даже хорошо.

По моему все разжевал, даже ламер поймет, неговоря о девелоперах фирмваря.

Так что, поддержка, исправим косяк, али как ? А то ведь мани бак

0_o Не ожидал увидеть на форуме D-Link сообщение, написанное на уровне статьи для Habrahabr'а! Хоть и ничем не могу помочь, но большущее Вам спасибо, прочитал на одном дыхании!

Ух ты, спасибо, надеюсь, поддержка тоже ее прочитает, а главное, разомнет филейные части фирмвареписателям

Конечно будем надеяться, но все же вероятность невелика. Если Вы на приличном уровне разбираетесь в Linux (а по лихому использованию iptables видно, что разбираетесь), то попробуйте разобраться как можно разобрать прошивку, найти сделанные между этими релизами прошивок изменения, откатить нужный файл на старую версию и заново собрать прошивку. Да, это очень непросто, да очень долго нужно разбираться с форматом прошивки (binwalk рулит!), но зато Ваша камера будет заточена только под Вас и будет иметь нужный Вам функционал. Я вот сейчас с DCS-2210 разбираюсь, весело там всё. Хотя всё это больше только "на поиграться", т.к. если камера нужна здесь и сейчас или же катастрофически не хватает свободного времени - такой способ не подойдёт...

binwalk ... спасибо за совет, изучу на досуге.
Вот тут http://tsd.dlink.com.tw нашел GPL Source Code, правда, только под первую прошивку,
но там ничего интересного, все что длинк сам сделал, в том числе и обработка видео все в бинарниках.

Вот я и говорю, что самому надо распаковывать. Из исходников Вам потребуется только алгоритм сборки и утилиты, используемые для сборки.

Вот не хочется обижать никого..., но не могу промолчать...
933L модель появилась недавно ...я наверное один из первых кто её тестил... совсем нормальная цена(за СЫРом погнался) +новшества(даже не тестил..эти wifi умножители)..
Одно могу сказать, ну перестал я их закупать на обьекты( штук 5 купил вначале) ну СЫРоВАТА модель.
Снова закупаю 942L и жду...как и Вы...
Хочу отметить постик...гут одно слово.

Поддержка, вот вам еще дополнительная информация (если вы, конечно заглядываете в форум).
Разобрал фирмварь (спасибо evilslon за binwalk), плюс проанализировал GPL. На 95% уверен, что ошибка в
модуле ftpputvideo (часть busybox), судя по комментам в сорцах GPL, одни из последних исправлений вносил
программер julie (а может и а может и программистка привет ему/ей передайте что-ли.
А не уверен на 5% потому как на практике проверить не могу пока, надо busybox из более поздней
версии фирмваря вставить в последнюю. Отсюда вопрос, кто знает как корректно обратно фирмаврь образ собрать ?

Получил его так:

# binwalk dcs933l_v100_b14.bin
DECIMAL HEX DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0x9DBEC62, created: Wed Jan 23 10:40:42 2013, image size: 128448 bytes, Data Address: 0x80200000, Entry Point: 0x80200000, data CRC: 0x334BA6BE, OS: Linux, CPU: MIPS, image type: Standalone Program, compression type: none, image name: "SPI Flash Image"
99312 0x183F0 U-Boot boot loader reference
125639 0x1EAC7 LZMA compressed data, properties: 0x40, dictionary size: 65536 bytes, uncompressed size: 64 bytes
125663 0x1EADF LZMA compressed data, properties: 0x40, dictionary size: 65536 bytes, uncompressed size: 128 bytes
125687 0x1EAF7 LZMA compressed data, properties: 0x41, dictionary size: 65536 bytes, uncompressed size: 128 bytes
327680 0x50000 uImage header, header size: 64 bytes, header CRC: 0xC4713770, created: Wed Jan 23 10:40:37 2013, image size: 6356808 bytes, Data Address: 0x80000000, Entry Point: 0x8037E000, data CRC: 0x4ED2D8B7, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
327744 0x50040 LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 8927701 bytes

# dd if=./dcs933l_v100_b14.bin iflag=skip_bytes skip=327744 of=./f1
#lzcat f1 > f2
#binwalk f2

DECIMAL HEX DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
3211340 0x31004C Linux kernel version "2.6.21 (andy@ipcam-linux.alphanetworks.com) (gcc version 3.4.2)etworks.com) (gcc version 3.4.2) #1319 Wed Jan 23 14:40:30 CST "
3355636 0x3333F4 Copyright string: " (c) 2011 Alpha Networks Inc.***** free audio buffer error 1 "
3620355 0x373E03 LZMA compressed data, properties: 0x40, dictionary size: 65536 bytes, uncompressed size: 64 bytes
3620379 0x373E1B LZMA compressed data, properties: 0x40, dictionary size: 65536 bytes, uncompressed size: 128 bytes
3620403 0x373E33 LZMA compressed data, properties: 0x41, dictionary size: 65536 bytes, uncompressed size: 128 bytes
3796992 0x39F000 LZMA compressed data, properties: 0x5D, dictionary size: 1048576 bytes, uncompressed size: 16344576 bytes

# dd if=./f2 iflag=skip_bytes skip=3796992 of=./f3
# lzcat f3 > f3.cpio
# cpio -idmv --no-absolute-filenames < f3.cpio
И получилась структура каталогов romfs. Теперь, допустим, я что-то меняю,

# find . |cpio -ov |lzma -9 - >/tmp/f3_new.cpio
А дальше что ?

А ничего... Вы первый, кто раскуривает эту камеру, так что надейтесь лишь на собственные силы в вопросе сборки прошивки. Рад бы помочь Вам, да нечем. Смотрите как бинарники в исходниках прошивки воедино собираются (плюс там ещё CRC вроде считается, если мне не изменяет память). Со своей стороны могу лишь пожелать Вам удачи!

Может чтобы дело продвинулось целесообразнее на буржуйском форуме пообщаться?

Вроде пошел процесс, изучаю GPL пока, запутано там все, но разобраться можно если все получится подробно отпишу как образ собрать.
Много вкусностей там, среди прочих - есть штатная возможность скидывать клипы на CIFS без 10-ти секундного ограничения продолжительности,
надо только в NVRAM параметры прописать, я б еще mydlink нафиг выкинул, мне он не нужен, только ресурсы камеры жрет.

Конечно опишите всё, что делали, и, главное, как делали, поскольку такой информации в Сети нету, а уж те, кому хочется "допилить" камеру под свои нужды, всегда найдутся. К сожалению с D-Link всегда так - спасение утопающих дело рук самих утопающих. Ладно хоть "железо" на более-менее приемлемом уровне делают, и за то спасибо...

Есть законы рынка (учитывайте сегментацию)...коммерция во всём виновата...:
Не делать...ну скажем так "идеальный продукт"...., что бы народ постоянно покупал чё нить новое...(здесь вспоминаются шасси у игрушечных китайских машинок, на которых колёсики держатся, которые намеренно делаются тонкими, чтобы через пару недель они сламались..и народ покупал следующий товар.... )

Вот знаете, не хотел я это писать здесь, но всё-таки напишу, тем более, что как раз про коммерцию. Есть неподалёку от моего дома один такой большой-пребольшой оптово-розничный торговый центр, ходить туда я не очень люблю, но иногда приходится. И стояли в том ТЦ множество камер D-Link (что-то типа 2103 или 2130), их было очень много, почти на каждом шагу. Стояли-стояли... И вот, пришлось мне в очередной раз побывать в том ТЦ буквально пару дней назад. И что я вижу? D-Link'и пропали, а на их местах стоят камеры от Axis, и причём все на тех же DWL-P200, на которых стояли старые камеры. Вот вам и законы рынка - бизнес проголосовал рублём. Я уверен, что допилили бы D-Link'овцы прошивки до приличных состояний, такого бы не случилось...

нас забанят...а ты не говори правду
(...тебя посодют..а ты не воруй....хахахаха - кто помнит этот фильм..)
Кстати по поводу центра...если я прална понял это были камеры из системы видеонаблюдения торгового центра?
Если так, то есть одна мыслишка, что эти центры просто централизовано перешли на крутой софт -видеонаблюдение + безопасность( догадываюсь какой но не буду писать), а в этом софте как раз камеры от axis хорошо себя проявили(а также являются партнёром этого бренда)...вот так..