Александр Рыжов

Здесь кое-что. Может допустить указание right = %domain.com наряду с right = domain.com ?

Значит, клиент пользуется такими DNS-серверами и/или игнорирует время жизни DNS-записи. ~$ dig +nocmd +noall +answer gpoint.keenetic.pro gpoint.keenetic.pro. 60 IN A 46.125.185.53 Как видите, DNS-запись имеет TTL 60 секунд. УМВР.

LLDP же! Некоторые NAS'ы и роутеры имеют соответствующую службу, чтобы красиво отображаться в карте сети Windows. По мне так баловство.

«Встройте неработающую в 2018-м году фичу и дайте пользователю уже решать использовать ее или нет. И не будет никаких споров.» Конечно-конечно:)

Код прошивки ≠ код URL фильтрации.

У Яндекс нет сервиса динамического DNS, а есть API для управления доменными записями в рамках pdd.yandex.ru. И то, есть он, покуда всех владельцев доменов не перевели принудительно на Яндекс.Коннект.

«Хорошо» — это как? По расписанию?

…пары нестандартных «матриц». UVC-камеры там работали отлично. Всё, что там могло смущать, это V4L v1 в силу древности ядра.

Т Тогда можно сразу закончить на том, что у Яндекса нет DynDNS. С теми, кто «без всяких заморочек» с роутером живёт, домены Яндексу делегируют крайне редко.

Добрый. В окне обновления прошивки можно выбрать конфликтующие компоненты. При нажатии на кнопку "Обновление устройства" процесс будет завершаться с ошибкой, пока не разрешишь конфликт компонентов самостоятельно. На приложенном скриншоте видны одновременно выбранные конфликтующие компоненты CIFS/SAMBA.

Вчера проверял, на GIII прошивка доступна. Обновляйтесь.

Дальнейшее обсуждение предлагаю вести в профильной теме.

IMHO, это спор о вкусах, где трудно угодить всем и каждому.

Исходники коммерческие проекты никогда не отдают, это их хлеб. А добавлять в прошивку скомпилированного на стороне кота в мешке вряд ли целесообразно. Самостоятельно с разработчиками исходников не надо связываться. Вероятность добавления компонента зависит отнюдь не только от этого. Просто подождите, насколько эта тема найдёт отклик у авторов NDMS и других пользователей.

Тему перенёс в «Развитие», поправил название топика. Исходники перечисленных компонентов закрытые. С нуля никто проводить реверс-инжениринг и переписывать клиентов не станет.

Настройка есть, но не выведена в веб-интерфейс. interface Home peer-isolation system configuration save

Именно событием относительно устойчиво получалось желаемое на DHCP-сервере.

Если @Vyacheslav Anisimov не против, могу перенести тему в Развитие NDMS. IMHO, это частный случай подписки на события прошивки. На все случаи жизни hook-скриптов не напасёшься.

Это в т.ч. продолжение темы с автоматизацией без использования opkg. Раньше я показывал только как посылать от роутера в сторону сервиса автоматизации информацию о полученном IP-адресе, но хотелось бы реагировать и на другие события, например, подключение клиента по Wi-Fi, переподключением носителей и/или рестарте сервисов. Формат JSON упомянул лишь потому, что чаще других встречаю его в работе сервисов автоматизации. Таких сервисов довольно много, с помощью них можно будет получать по JSON информацию от роутера, фильтровать и ответным JSON-запросом роутером управлять. Вот, скажем, Google Docs, позволяют публиковать встроенные в книги скрипты App Script как веб-приложения, разборка JSON-параметров от роутера будет в нём одной строчкой. Раз уж в прошивке есть некоторая шина событий, на которые могут подписываться компоненты, вероятно можно вывести эти события в виде POST-запросов. Если это неприемлемо сложно для реализации, то может будет некая утилита, на манер ndmq, для подписки на выбранные события и передачи их в виде параметров в shell-скрипт? На картинке для привлечения внимания роутер записывает в Google-таблицы очередной IP на WAN интерфейсе, скрипты таблицы дёргают определённую ячейку, по изменению которой сервис автоматизации вызывает реконнект WAN при необходимости. Всё в пределах заводского интерфейса, без использования на роутере opkg.

Сверхскоростных и безопасных VPN'ов существует больше, чем тем на здешнем форуме. За всеми не угонишься. Придётся подыскать другой тип VPN.

@stitchix, если речь про мобильное приложение, то я перенесу тему в соответствующую ветку.

Просто как вариант: Чтобы не трогать плату и корпус роутера, я делал аналогичную штуку с помощью начинки из старой USB-клавиатуры, платка из неё довольно миниатюрна. На кинетике она будет определяться как HID-устройство, а события отлавливаться с помощью triggerhappy. Модули USB HID в кинетиковской прошивке есть.

Прошивка имеет замечтательный REST API, позволяющий опрашивать роутер на предмет текущего состояния и выполнять необходимые настройки/действия. Прошу добавить возможность подписки на события прошивки, т.е. отправку JSON-сообщений на указанный URL при наступлении (в идеале выбранных) событий. Фича позволит: стать роутеру генератором событий для сервисов автоматизации вроде IFTTT в рамках заводского функционала без использования хук-скриптов opkg, для самописных скриптов автоматизации избежать timeout-driven решений "периодический опрос - действие" в пользу event-driven решений "событие - действие". Понимаю, что указанная возможность будет нужна довольно малому числу пользователей, но надеюсь, что её реализация не будет трудоёмкой.

Отличный вопрос:)) Разумеется, никуда он не девается, если вы его не отключали принудительно на нужном сегменте. Работает с прежней пролетарской яростью.