eralde

Интересное предложение, надо подумать. И "редактор" этого сделать более человеческий.

Версия 0.5.87 (2021-05-17): "Другие подключения": добавлен редактор для IPIP/GRE/EoIP интерфейсов 0.5.87 (17 May 2021): "Other connections": Added editor for IPIP/GRE/EoIP interfaces

В 0.5.86, к сожалению, редактор IPIP/GRE/EoIP не работает.

Версия 0.5.86 (2021-05-16): "Другие подключения": добавлен редактор для IPIP/GRE/EoIP интерфейсов 0.5.86 (16 May 2021): "Other connections": Added editor for IPIP/GRE/EoIP interfaces

Версия 0.5.85 (2021-05-12): "Другие подключения": добавлена таблица IPIP/GRE/EoIP интерфейсов (в текущей версии -- без редактора; в отладке очень помог @Ranger) 0.5.85 (12 May 2021): "Other connections": Added EoIP/IP/GRE connections table (@Ranger helped a lot with debugging)

Версия 0.5.84 (2021-05-10): исправлен курсор для элементов textarea (сообщил @AndreBA) добавлены переводы строк из расширения на турецкий язык (помог @yerebakan) "Диагностика": на вкладку с диагностикой DSL-подключения добавлен вывод счетчиков ошибок FEC/CRC/HEC (предложил @yerebakan) в меню добавлена ссылка для перехода на вкладку с диагносткой DSL (только для DSL-устройств) 0.5.84 (10 May 2021): fixed cursor for textarea elements (reported by @AndreBA) added Turkish localization (provided by @yerebakan) "Diagnostics": added FEC/CRC/HEC error counters for DSL connections (suggested by @yerebakan) added menu link to the DSL diagnostics info tab (only for models with built-in DSL modem)

Спасибо, к сожалению, говорить не за что Я проблему так и не смог воспроизвести, хотя специально упражнялся именно с KN-1910. Если возникнет еще раз -- вернемся к этому вопросу.

Версия 0.5.81 (2021-05-03): исправлен стиль легенды на странице "Монитор трафика" (сообщил @AndreBA) исправлен стиль страницы "Анализатор трафика приложений" (сообщил @AndreBA)

Спасибо, похоже, что мы слишком "ужесточили" валидатор.

Я знаю, что так можно сделать, но мы с исходным заказчиком расширения (@T@rkus) не смогли подобрать вариант на основе общего фильтра. Он, конечно, гораздо проще в поддержке. А вот остальные вещи (новые ссылки в меню, фильтры устройств) через Stylus не сделать.

Мне кажется, что это лишнее, потому что все эти пункты есть в боковом меню. Но я подумаю, может быть это не потребует слишком большого количества костылей в дашборде.

Я кратко описал все тут:

Прослойка, которую использует веб-интерфейс для настройки, так называет получающийся мост, если у Кинетика синий порт на отдельном свитче. У интерфейса есть идентификатор вида BridgeX и псевдоним ISP-IPTV. Вы можете в этом убедиться, посмотрев на вкладке "Network" в консоли разработчика браузера на ответы, которые веб-интерфейсу приходят от устройства. В одном из ответов будет "... 'next-name': 'ISP-IPTV'", при этом в запросе такого имени нет.

Версия 0.5.80 (2021-03-28): всплывающая подсказка выпадающего меню с расписаниями стилизовна под темную тему (сообщил @AndreBA)

Версия 0.5.79 (2021-03-21): расширение корректно поддерживает прошивки >= 3.7 (и все следующие версии 3.x) (сообщил @AndreBA) если меню свернуто, клик по пустому пространству под иконками раскрывает меню (такое поведение было в версиях < 3.5, добавлено по просьбе @T@rkus) для Ultra II / Giga III / Extra II / Air добавлена возможность выбора канала автообновлений delta (по просьбе @T@rkus)

При переходе из веб-интерфейса Кинетика в ссылку вставляется текущий язык веб-интерфейса. Этот вариант нам проще поддерживать, чем отдельную настройку в веб-интерфейсе Transmission.

Сейчас попробовал с телефона, работают ссылки вида: <KEENDNS_NAME>/app/transmission/web/index.html?devicetype=computer&lang=ru (десктопный UI) <KEENDNS_NAME>/app/transmission/web/index.mobile.html?lang=ru Вариант с IP тоже должен работать, я думаю.

Передавайте в ссылке аргумент lang: Screen Recording 2021-03-10 at 11.58.55.mov

Запросить только ошибки, к сожалению, нельзя. Параметры в REST API повторяют аргументы команды в CLI: (config)> show log Usage template: log [{max-lines}] [once]

Нужно провести эксперимент. Особенность лога в том, что он продолжает присылать признак "continued" бесконечно, в отличие от других подобных процессов.("show site-survey", "components commit", ...). Отсутствие признака "continued" в ответе на GET-запрос (или на исходных POST-запрос), значит, что процесс в системе завершен (и последующие GET-запросы снова будут возвращать 404). Я не знаю случаев когда устройству плохело бы из-за запросов лога, но я запустить много копий получения лога не пробовал. В случае с логом получение новых событий через GET-запрос после запуска должно работать пока не протухнет сессия авторизации (она протухает через 10 минут отсутствия активности). Гм, похоже, что достаточно отправить POST-запрос к rci/show/log с такими данными: { "once": true, "max-lines": 100 } Этот запрос вернет 100 последних сообщений и при этом фоновый процесс не остается висеть после ответа. Надеюсь, что это подойдет)

GET-запрос не работает потому что это т.н. "background process" и он еще не запущен. См. B.1.2.3 Background processes в Command Reference Guide: Чтобы получить лог необходимо: отправить POST-запрос к rci/show/log с аргументами команды в JSON в качестве данных (без аргументов -- "{}"; другой пример "{"max-lines": 100}"). Этот запрос вернет весь текущий лог. далее отправлять GET-запросы к rci/show/log (будет приходить объект вида {continued: true, <новые сообщения, если они появились с момента последнего опроса>} в момент, когда вы хотите прекратить получение сообщений из лога -- отправить запрос с методом DELETE

Спасибо, за репорт. Поправим.

Спасибо! Проблема в мастере первоначальной настройки. Она будет исправлена в следующих версиях (текущие выпуски 3.6 также содержат эту ошибку). Пока, к сожалению, такая настройка возможна только на странице "DSL".

Насколько я знаю, назначение service-class и этот компонент в прошивке не связаны никак. Т.е. будет работать.