10 заметок с тегом

openwrt

«Умный» дом

Добавляем камеру в Domoticz

Во-первых, почему Domoticz? Мне он показался намного более простым по сравнению с Majordomo и другими системами. Во-вторых, этот пакет присутствует в репозитории на роутере (с установленным OpenWrt). С одной стороны ставить такую программу я предпочел бы на сервер, с другой — именно роутер является точкой, соединяющей все сетевые устройства в квартире. Поэтому пусть пока будет так.
Так как камера у меня — «чистый» китаец, то просто так добавить ее в систему не получится. По крайней мере, мне это не удалось. Пришлось идти обходным путем.
Строка подключения к камере выглядит примерно так:

rtsp://192.168.1.12:554/user=admin&password=&channel=1&stream=0.sdp?real_stream

Открыв этот адрес, например, через плеер VLC, можно увидеть основной поток камеры. В принципе, строку можно чуть-чуть сократить, убрав всё после sdp. В любом случае, Domoticz такое не понимает. Поэтому нам понадобится пакет под названием motion. У меня он уже установлен и отправляет мне в Telegram фото событий. Камера у меня пока что одна, но в будущем планируется еще несколько, поэтому все настройки, отличающиеся от настроек по умолчанию, я вынес в отдельный файл, который подключил в motion.conf. Там нам понадобятся несколько параметров, перечисленных ниже.

netcam_url rtsp://192.168.1.12:554/user=admin&password=&channel=1&stream=1.sdp?real_stream
netcam_keepalive on
width 704
height 576
stream_port 8091
on_event_start /root/motion/actions/on_event_start
on_event_end /root/motion/actions/on_event_end

Первая строка — подключение к самой камере на вторичный поток. Вторая — поддержка подключения, можно пропустить. Третья и четвертая — размеры кадра вторичного потока, у меня они такие. Можно выбрать, конечно, и основной, но это повлечет за собой увеличение трафика в сети и времени подключения. Самая «интересная» строка — следующая. Она указывает motion через какой порт выводить картинку. И последние две строки — пути к скриптам, которые будут выполняться при возникновении и завершении события. У скриптов должны быть установлены права на выполнение.
Запускаем motion и первым делом проверяем наличие потока, просто открыв ссылку в браузере. Например, motion у нас будет установлен на компьютер с адресом 192.168.1.10. Тогда в браузере набираем:

http://192.168.1.10:8091/

Вы должны увидеть видеопоток с камеры. Если его нет — придется разбираться что не так. Чаще всего просто не открыт указанный порт на компьютере. Если картинка есть — идем дальше.
Открываем Domoticz и пробуем добавить камеру.

Нужное меню в Domoticz Добавляем камеру в Domoticz
Добавляем камеру в Domoticz

Протокол оставляем HTTP, в качестве IP-адреса указываем адрес компьютера, куда установили motion. Порт указываем тот же самый, что и в файле настроек motion. Имя пользователя и пароль заполняем в том случае, если для просмотра камеры нужна авторизация. Ну и в ImageURL забиваем полный путь к потоку, тот же самый, который вбивали в браузере при проверке потока камеры. Нажимаем «Тест соединения» и надеемся, что картинка появится. Обычно на это нужно до 10 секунд. Если картинки нет, значит что-то пошло не так и придется всё проверять. В моем случае картинка нормально появляется когда я работаю в домашней сети. Если я запускаю Domoticz с рабочего компьютера, то она не показывается.
Нажимаем кнопку «Add», чтобы добавить камеру в список. И тут тоже есть нюанс. В строке с камерой тоже есть предварительный просмотр, но в моем случае он не работает. Также не работают кнопки «Сделать снимок» и «Stream video». Но это не важно, камера работает.
Не зря же мы это все делали? Пусть теперь камера работает датчиком движения — нечего ей просто так висеть на потолке. Например, включает освещение в коридоре, когда обнаружит движение.
В качестве выключателя с удаленным доступом у меня стоит простой Sonoff Basic, подключенный к моей сети через WiFi. Идем в настройки Domoticz, выбираем «Оборудование». В выпадающем списке ищем пункт «Dummy (Does nothing, use for virtual switches only)», называем его как-нибудь и нажимаем кнопку добавить. Теперь в списке чуть выше нажимаем кнопку «Создать виртуальные датчики», вводим название выключателя (придумываем сами) и указываем тип «Переключатель». Жмем «ОК». Всё, мы создали виртуальное устройство, которое будет управлять освещением в коридоре. Остается теперь соединить между собой камеру и выключатель.
Вспоминаем, что у нас есть два скрипта от motion, которые выполняются при возникновении и завершении события, в данном случае — в коридоре. Добавляем в каждый из скриптов по одной строке. В  /root/motion/actions/on_event_start добавляем

/usr/bin/curl -s "http://api_username:api_password@domoticz_server:domoticz_port/json.htm?
type=command&param=switchlight&idx=your_ID&switchcmd=On"

а в  /root/motion/actions/on_event_end такую строку:

/usr/bin/curl -s "http://api_username:api_password@domoticz_server:domoticz_port/json.htm?
type=command&param=switchlight&idx=your_ID&switchcmd=Off"

Теперь разберем, что это за бред.
curl — программа, позволяющая выполнить те или иные действия по указанному адресу, используя только командную строку.
api_username и api_password — имя пользователя и пароль, которые вы установили для доступа к Domoticz. Если не устанавливали, то эту часть «api_username:api_password@» можно не вводить.
domoticz_server и domoticz_port — IP-адрес и порт компьютера, где у вас установлен Domoticz. В качестве порта нужно указать стандартный 8080, если, конечно, вы не делали перенаправления портов.
idx=your_ID — в качестве your_ID нужно указать значение выключателя из колонки Idx таблицы устройств. У меня это значение равно «1».

Таблица устройств
Таблица устройств

Ну и последний параметр switchcmd может принимать значения On или Off, в зависимости от того, хотите ли вы включить освещение или выключить соответственно. Подозреваю, что можно также указать «1» и «0» соответственно, но, если честно, лень проверять :-)
Должен также отметить, что в Sonoff установлена не стандартная прошивка с привязкой к китайскому облаку (и возможностью потерять доступ к своему выключателю из-за рвения Роскомнадзора заблокировать всех и вся), а Tasmota. Возможностей у нее немного, но лично мне хватит с избытком. Не будет же выключатель вещать радио, когда мне скучно? :-)
Теперь почему мы используем такой сложный способ включения/выключения? Просто при таком способе состояние выключателя будет корректно отображаться в Domoticz в случае возникновения или завершения движения в коридоре.

Прямой доступ к сети по IPv6

Два дня искал как получить прямой доступ к компьютерам в сети через IPv6. Ни один способ не подходил, сколько не пробовал в самых разных вариациях. Самое забавное, что месяц-два назад я как-то этот доступ настраивал. Потом роутер пришлось сбрасывать до заводских настроек, а в памяти этот момент не отложился.
В итоге, все оказалось очень просто (надеюсь, ничего не забыл)...
Открываем веб-морду OpenWrt, входим под своими логином и паролем. Затем идем на вкладку Network — Interfaces и в поле «IPv6 ULA-Prefix» вводим префикс подсети. Например, такой: 2002:1234:5678:1234::/64. Компьютеры в локалке, конечно же, должны иметь адреса из этого же диапазона. Следом стоит дать разрешение в брэндмауэре. Для этого открываем Firewall — General settings и для пунктов Input, Output и Forward в самом верху ставим «Ассept».
Применяем сделанные изменения, перезагрузка не требуется.

Разница между udpxy и igmproxy в OpenWrt

Случайно обнаружил разницу при использовании udpxy или igmpproxy. Я бы сказал, что для меня она была весьма существенной. По какой-то причине я не находил в интернете подобного сравнения этих двух пакетов.
Для начала хочу отметить, что мой тарифный план у провайдера включает в себя 70 бесплатных каналов IPTV. Все остальные — за отдельную плату. Всего же их чуть менее 200 штук.

  1. При использовании igmpproxy нет необходимости переделывать плейлист, адреса в нем остаются в исходном виде, то есть udp://@239.255.1.1:1234. В случае с udpxy этот же адрес в плейлисте нужно привести к виду http://192.168.1.1:4022/udp/239.255.1.1:1234, где 192.168.1.1 — адрес роутера, а 4022 — порт, на котором случает udpxy. Все остальные параметры, думаю, понятны.
  2. А вот здесь начинается самое интересное. Igmpproxy позволяет мне просматривать только 70 каналов, которые входят в мой тарифный план, в то время как udpxy позволяет просматривать весь список — почти 200 каналов.

Последний пункт пересиливает мою лень по редактированию плейлиста — во второй половине списка есть каналы, которые мне хотелось бы смотреть.
Остается только дополнить список логотипами каналов, чтобы можно было визуально их идентифицировать, а не вчитываться в каждое название, и загрузить его в телевизор. Если бы еще придумать как просматривать эти каналы как обычные, антенные, без запуска каких-то дополнительных приложений на телевизоре — было бы просто замечательно.

Проект LEDE

Проект LEDE появился на замену популярной прошивки для роутеров OpenWrt. В последней, из-за внутренних проблем, обновления и новые пакеты стали появляться все реже. LEDE взялся устранить все проблемы, существующие в нынешней прошивке OpenWrt и периодически выпускать новые релизы.
На сам проект я наткнулся достаточно недавно, два или три месяца назад. Почитал первую страницу сайта, заинтересовался, но, так как дел было невпроворот, отложил на будущее. Вчера, перебирая закладки браузера, наткнулся на него и решил все-таки посмотреть более внимательно.
LEDE является ответвлением OpenWrt и полностью с ним совместим. Вы можете устанавливать те же самые пакеты, что и в OpenWrt. Более того, даже сам сайт проекта LEDE выглядит точно так же, как и у OpenWrt. Связано это с тем, что сейчас идет интеграция старого сайта в новый.

Стартовая страница сайта LEDE
Стартовая страница сайта LEDE

На сайте также можно найти информацию о том, что в течение этого года планируется полное слияние обеих проектов.
Первое, что я сделал — посмотрел текущую стабильную версию прошивки. Как ни странно, но разработчики «перешагнули» через 16 версию и создали сразу 17-ю. Последняя стабильная прошивка для моего роутера оказалась 17.01.4. Ее я и скачал. Дальше все, как обычно, просто. Заходим на страницу System — Backup / Flash Firmware роутера, указываем на файл с новой прошивкой в разделе Flash new firmware image, оставив галочку Keep settings отмеченной, чтобы не терять сделанные настройки, и запускаем процесс обновления.
Сразу хочу сказать, что тема оформления Bootstrap мне почему-то никогда не нравилась, я постоянно выбирал старую OpenWrt. Хотя к самому фреймворку я отношусь более, чем положительно. Но старая тема после перепрошивки не заработала, поэтому следующим моим шагом был поиск темы, отличной от Bootstrap. На мое удивление в списке доступных увидел тему Material. Ее и установил. Тема оказалась удобной, красивой, но чуть недоработанной и, на мой взгляд, чуть громоздкой — роутер чуть медленней переключался между страницами.

Страница входа в систему
Страница входа в систему
Страница статуса системы
Страница статуса системы
Скрипты, выполняемые при загрузке
Скрипты, выполняемые при загрузке

Памятуя о качестве перевода с английского на русский язык в предыдущей прошивке, я не торопился переключаться на русский язык, меня вполне устраивал и английский. Позже я все-таки решил установить языковой пакет. Оказалось, что устанавливать их нужно не один, как раньше, а как минимум два — для «стандартных» страниц и для настроек firewall. При этом при установке этих пакетов я получил ошибку «uci: Parse error (too many arguments) at line 123, byte 34», но решил не обращать на нее внимание, потому что пакеты установились без ошибок.
Одновременно просматривая сайт проекта наткнулся на интересный «фокус», который заключается в том, что после авторизации на роутере по SSH, в консоли выводится количество установленных пакетов и количество доступных для обновления. Это освобождает от необходимости вручную проверять наличие обновлений, так почему бы этим не вспользоваться? Для этого нужно записать всего несколько строчек в файл ~/.profile

#!/bin/sh
opkgInstalled="$(opkg list-installed 2> /dev/null | wc -l)" #silencing error output
opkgUpgradable="$(opkg list-upgradable 2> /dev/null | wc -l)" #silencing error output
echo "$opkgInstalled packages are installed." && echo "$opkgUpgradable packages can be upgraded." && echo

И, как говорится, раз уж «пошла такая пьянка», то почему бы не сделать похожий скрипт, который устанавливал бы все обновления сразу? Мне никогда не нравился вариант сначала получить список доступных для обновления пакетов, затем копировать их имена в команду обновления. На сайт проекта также есть решение этого вопроса, но мне оно не понравилось. Более того, оно просто некорректно работает. Поэтому предлагаю свой вариант:

#!/bin/sh
/bin/opkg update
/bin/opkg upgrade $(opkg list-upgradable | awk '{print $1}')

Но я отвлекся. Еще одним новшеством, которое мне понравилось в данной прошивке — визуализация уровня сигнала WiFi

Уровень сигнала WiFi
Уровень сигнала WiFi

В какой-то момент изучения прошивки я сделал ошибку, пришлось сбрасывать настройки на заводские и заново перенастраивать роутер. И тут выявилось, что в этой прошивке таки заработал туннель от Henet. После внесения настроек я смог извне протестировать свой роутер на доступность по IPv6 и получил положительный результат.

Результаты тестирования IPv6
Результаты тестирования IPv6

На данном этапе мне эта прошивка нравится намного больше, чем версия 15.05.1 от OpenWrt. Возможно, что в процессе дальнейшей эксплуатации вылезут какие-то недочеты, ошибки, но будем надеяться, что их будут более-менее быстро исправлять.

Небольшой апгрейд

Очередная зарплата ведет к очередным обновлениям

На днях попробовал перенести Transmission и сервер DLNA с роутера на домашний сервер, чтобы немного разгрузить первый. Итогом неожиданно стала сильно возросшая нагрузка на сервер, причем в первых строчках «потребителей» стабильно висели motion и Transmission. Нагрузка была такой, что другие программы периодически не отвечали на запросы, что, в свою очередь, вызвало шквал предупреждений в мой почтовый ящик. Конечно, это меня не устроило, поэтому торрент-клиент был на время отключен. Вызвал небольшое недоумение тот момент, что на роутере Transmission работал, не вызывая такой большой нагрузки на и без того слабый процессор. Лучше был оптимизирован что ли под OpenWrt? Аналогично, судя по отзывам, motion при статичном кадре (то есть когда нет движения) «сжирает» 5-10% процессорного времени. У меня же он поглощал в среднем около 40% на сервере.

Тут должен сделать небольшое отступление. Парой месяцев ранее собирал компьютер для профилактория «Сибиряк», чтобы они могли просматривать камеры видеонаблюдения на ресепшене. Компьютер получился достаточно слабенький, но, если воткнуть в него видеокарту, вполне тянул 8 внутренних камер. Так как видеокарт на складе у меня тогда не было, пришлось воткнуть свою личную. Она у меня все равно просто так лежала. Поставил, настроил, все хорошо. Неделю назад попросили подключить второй монитор на этот компьютер и вывести на него камеры, снимающие вокруг здания. Не вопрос! Заказал второй монитор и видеокарту — свою же нужно «отбить» :-)

Возвращаемся на текущий день. После недолгих раздумий, был куплен новый процессор и кабель HDMI. Процессор был установлен в сервер, что дало достаточно большой прирост мощности, судя по выводу команды top. Также установил туда новую видеокарту, которую приобрел для «Сибиряка». Был вариант установить в профилакторий новую карту, а оттуда забрать свою, но, после сравнительных тестов, оказалось, что установленная мной ранее видюха немного мощней, чем та, которую я приобрел на днях. HDMI кабелем соединил видеорегистратор и телевизор. Были некоторые опасения, что телевизор не увидит картинку с таким нестандартным разрешением, но все обошлось — он просто изменил разрешение на что-то среднее по качеству. В итоге, я теперь могу просматривать камеры на телевизоре в хорошем качестве. Плюс несколько «разгрузил» сервер — теперь нагрузка на процессор стала менее 50%. Правда появился какой-то дребезг от вентилятора, но непонятно от какого — пока снимаешь боковую стенку, он прекращается.

DLNA в локальной сети

Меня не покидала мысль, что телевизор поддерживает DLNA, несмотря на то, что на официальном сайте это не указано. Зато было указано на нескольких других. Попытка не пытка...
Есть у меня переделанный роутер D-Link DIR-825 с установленной OpenWrt. Внутрь встроен жесткий диск, на котором располагается собственно система и множество других программ. В частности, клиент Transmission. Это очень удобно — с любого устройства можно поставить торрент на закачку. Плюс к этому он все равно работает круглые сутки, пусть скачивает :-)

Прочитав днем про настройку DLNA на OpenWrt, подключился к роутеру и  установил пакет luci-i18n-minidlna-en, который потянул за собой собственно сервер DLNA и другие необходимые пакеты. Настройка была минимальной: задал каталоги где искать видео- и аудиофайлы, куда писать логи и каталог с кэшем. Ну и, конечно, запустил его. Поначалу нагрузка на роутер сильно возросла: сервер «сожрал» почти 60% процессорного времени и почти половину оперативной памяти. Из всех других пакетов, которые я ставил, ни один столько не забирал себе. Понадеявшись на то, что это только на время поиска файлов, отключился, чтобы вечером заняться этим вопросом уже дома.

Мои надежды оправдались — после завершения поиска нагрузка стала почти нулевой. Но меня уже больше интересовало как телевизор отреагирует (и отреагирует ли вообще?) на наличие DLNA сервера в локальной сети. Но сомнения оказались напрасны — все оказалось намного проще. Телевизор не только обнаружил сервер в сети, но и сразу отобразил его в списках доступных источников. Немного напрягло только то, что приходится «продираться» через кучу каталогов, чтобы найти нужное видео, но тут уже ничего не поделаешь, видимо.
В конечном результате я достиг того, чего хотел — теперь нет необходимости копировать скачанный торрент на флэшку, подключать её к телевизору и только тогда начинать смотреть фильм. Сейчас можно просто открыть роутер на телевизоре, выбрать нужный фильм и начать просмотр. С учетом того, что я не поленился подключить ТВ кабелем к роутеру, «лагов» пока что не наблюдается, скорость приличная. Но тут еще буду экспериментировать.
Днем ранее, кстати, также удалось вывести содержимое экрана смартфона на телевизор, включив на первом режим беспроводного дисплея. Смартфон тут же просканировал и нашел телевизор. Оставалось только подтвердить сопряжение устройств на самом ТВ.

Получаем доступ к rutracker для всей сети

Кабель провайдера у меня дома воткнут в роутер D-Link, который я еще много лет назад прошил на OpenWrt. От DD-Wrt в свое время пришлось отказаться в силу того, что эта прошивка сильно нагружала и без того слабенький процессор роутера.
Когда началась волна блокировок торрентов, установил в браузер расширение, позволяющее мне без проблем попадать на сайт rutracker. Поставил и забыл, как говорится. А недавно обнаружил, что торренты, которые качаются с этого сервера, перестали загружаться. Висят по много дней с нулевой активностью. В журнале видно, что трекер недоступен. Подумал, что нужно это исправить. Вспомнил одну читанную мной когда-то статью и понеслась.
Для начала устанавливаем на роутер Tinyproxy. Этот пакет позволит нам перенаправлять запросы к сайту через «левый» прокси. Этот прокси позволяет также использовать VPN, но они в России уже, к сожалению, запрещены. Все настройки я оставил без изменений, откорректировал только путь к журналу работы. Затем добавил в секцию «Upstream Proxies» новый пункт:

Policy: Via proxy
Target host: rutracker.org
Via proxy: proxy.antizapret.prostovpn.org:3128

Сохраняем, применяем, перезапускаем на всякий случай Tinyproxy. Кстати, потом оказалось, что после внесения новых серверов, его лучше всего именно перезапускать, иначе правило не будет работать. Открываем браузер, вбиваем в адресную строку rutracker.org и видим «картинку» сайта. Все открывается, все работает. Пробуем другие заблокированные трекеры — все хорошо.
Прелесть данного решения в том, что правила работают для всей домашней сети, а не только для тех браузеров, в которых установлено очередное дополнение. Еще одним «плюсом» является тот факт, что перенаправление действует только для тех сайтов, которые указаны в списке настроек. Для всех других трафик идет напрямую.

Настройка VPN на OpenWrt

Доступ в домашнюю сеть

На фоне запретов на VPN и анонимайзеров, взбрело в голову прокинуть туннель в свою домашнюю сеть. Так сказать, пока это не стало противоправным действием :-) Все делал вот по этой статье. С первого раза ничего не заработало. После небольшого расследования оказалось, что клиентский сертификат неверно сгенерировался и получился файл нулевого размера. Пришлось переделывать все заново. После этого я смог подключиться к домашней сети, но у меня не было доступа ни к одному компьютеру в ней. Для доступа к ней пришлось выполнить еще одно действие из этой же статьи, из англоязычной ее части:

# uci add_list openvpn.myvpn.push='route 192.168.1.0 255.255.255.0'

Так как подсеть у меня такая же, то не пришлось править адрес и маску. После перезапуска OpnVPN на роутере все заработало: доступ в сеть есть, к компьютерам — тоже. Все работает, отлично!
Но, как обычно, показалось этого мало. Настроил OpenVPN и на смартфоне. Применение такого доступа нашлось сразу же: быстрый просмотр записей с камеры. VLC, конечно, на такой скорости плохо кэширует (надеюсь, это лечится), но снимки, которые создает motion из записанного видеофайла просмотреть можно. Уже, как говорится, хлеб.
Затем, ради интереса, заглянул на собранную метеостанцию, посмотрел как там дела обстоят. Затем зашел на роутер, проглядел папку с торрентами.
Из «минусов» подключения по VPN вижу только то, что работать приходится не с именами машин, а с их IP-адресами. Но это уже мелочи.

«Сибиряк» снова доступен

Так сказать, в продолжение темы Восстановление DIR-300.
Перепрошитый на OpenWrt роутер, в итоге, ушел на «Сибиряк». После обеда съездил туда, посмотрел что и как. Так как из оборудования там имелись только видеорегистратор и DIR-300 (почему-то сильно любимый Павлом — человеком, который занимается видеонаблюдением на заводе), то решил для начала поменять роутер на свой.
Из-за своей невнимательности пришлось немного помучиться — пытался подключиться не к тому роутеру. Долго не мог понять почему не один пароль не подходит. Потом разобрался, вбил чуть раньше снятые с работающего роутера настройки и подключил его к сети.
Тестирование показало, что теперь все камеры можно просматривать одновременно, а не по одной как раньше. Плюс подключение к видеорегистратору происходит быстро и «безболезненно», с первого раза, а не с десятого. Чуть позже камеры снова начали тормозить, но это я уже списал на то, что просматривал их на телефоне, где 3G, так сказать, не резиновый.
Ушел на пост охраны, переподключил камеры в программе, оставил свой телефон на всякий случай и поехал домой. Дома попытался просмотреть камеры «Сибиряка» — все работает отлично. Да, есть небольшие «тормоза», но вполне допустимые, на мой взгляд, и комфортному наблюдению не мешают. Точно такие же «тормоза» есть и при просмотре камер на заводе.
Завтра, если получится, перепрошью забранный с «Сибиряка» роутер и... можно забрать его себе, так как в профилакторий я установил свой личный.

Восстановление DIR-300

Преамбула.
Вчера у генерального директора «отвалилось» видеонаблюдение за «Сибиряком». Поднялся, проверил — не видит программа видеорегистратор и все тут. На форуме нашел программу для Adnroid, установил себе на телефон. Через несколько минут смог подключиться к «Сибиряку» и смотреть видео с камер. Было принято решение поискать замену установленной на ноутбуке директора программе. Вернул сам ноутбук и пошел к себе копать интернет. По итогу все найденные программы либо не могли подключиться к регистратору, либо подключались, но раза с 10-го так и жутко тормозили. Чтобы найти причину, скопировал себе на флэшку эти программы и протестировал дома (канал шире, компьютер мощнее да и просто другой провайдер). Результат радости не принес — подключение также раза с 10, все тормозит. Сделал вывод, что проблемы на стороне «Сибиряка».
Продукцию фирмы D-Link знают, думаю, все — она славится нестабильностью своей работы, но это, в большинстве случаев, решается заменой прошивки на OpenWrt или DD-Wrt. Или еще какую-нибудь, но не от фирмы-разработчика устройства. На «Сибиряке» стоит именно D-Link DIR-300. В целом, аппарат неплохой, но... см выше.

Амбула.
Нашел у себя дома два устройства: DIR-300 и DAP-1360. Последний туда явно не годится, а вот в каком состоянии «трехсотый» — я уже не помнил. Взял с собой на работу, подключил и сразу вспомнил в чем с ним проблема: неудачная прошивка привела его в состояние «кирпича», подключиться к нему можно только в режиме Emergency room. Ну что делать, будет восстанавливать. Скачав с интернета несколько разных прошивок (фирменных и openwrt), попытался ему их скормить. Роутер отчаянно сопротивлялся: то говорил, что прошивка некорректна, то вроде бы «проглатывал» ее, но при этом просто гас индикатор подключения к порту и на этом все заканчивалось. Приходилось снова перезагружать его в Emergency room и пытаться скормить ему очередной образ. После полутора часов поисков, экспериментов и борьбы с упрямым роутером удалось найти фирменную прошивку, с которой он согласился принять. Но загрузка прошла только до 49%, после чего все Chrome потерял связь с роутером. Через некоторое время удалось отправить ему весь образ, на что роутер ответил предупреждением, что процесс прошивки начался и ни в коем случае нельзя выключать роутер. Хорошо, хорошо, уговорил.
После перезагрузки ожили индикаторы сети и WiFi. Слава богу! Итак, доступ к стандартному интерфейсу мы получили. Но я же упрямый, меня он не устраивает, я хочу OpenWrt! «Скормил» ему нужный образ и приготовился к ожиданию конца перепрошивки. Процесс завершился удачно, на роутер встала нужная мне прошивка. Дело осталось за малым: настроить ее под свои нужды. Но это уже такие мелочи... :-)