dimon27254

На актуальной 4.1 Beta 2 все аналогично. Предположил, что влиять на логику работы dns-proxy может исправление NDM-2990. Но там были правки для статических DNS-серверов, тогда как в моем случае получение идет через DHCP. Если перезагрузить резервное подключение, то полученный DNS-сервер начинает использоваться. При назначении устройству политики доступа в интернет через это подключение - никаких проблем с DNS не наблюдается. @hellonow @sergeyk

@hellonow @Le ecureuil в 4.1 Beta 2 отметки времени стали положительными, но значения продолжают быть нереалистичными: wireguard: Wireguard1: retrying handshake with peer "*" (8) (*) because we stopped hearing back after 2166337568 seconds wireguard: Wireguard1: handshake for peer "*" (8) (*) did not complete after 2368404880 seconds, retrying (try 0)

@eralde @Anna Zhelankina сейчас при переходе в веб-интерфейс ретранслятора из "Списка клиентов" требуется вручную проходить авторизацию, т.к. переход идет по IP-адресу. Было бы удобно, чтобы прямо с этой страницы имелась возможность попасть на ретранслятор по доменному имени без необходимости ввода логина и пароля, как это реализовано на странице "Wi-Fi-система". Если же на ретрансляторе, например, нет SSL-сертификата, тогда переходить по IP без автоматической авторизации. Это, конечно, мелочь, но в таком случае переход займет чуть меньше времени, т.к. не потребуется открывать отдельно страницу "Wi-Fi-система" и там кликать по нужному Кинетику или же вручную авторизовываться на нем при переходе из "Списка устройств".

@eralde по этому поводу были правки? В changelog не увидел упоминаний, но на последних версиях перестало воспроизводиться.

Стоит отметить, что новый веб-интерфейс доступен только на прошивках draft-ветки (канал разработчика): В preview (предварительном) он отсутствует, только что проверил у себя на KN-3610.

@eralde спасибо! В 4.1 Beta 2 состояние чекбокса отображается корректно.

Служба отключается сразу же после ввода команды, но порты, которые были открыты еще во время её работы - остаются. Перезагрузите Кинетик и все записи удалятся.

@eralde для пользовательских статических маршрутов, которые настроены на любой интерфейс, потерялась подпись "любой": Параметры одного из таких маршрутов: В текущем веб-интерфейсе отображение корректное:

По каким-то причинам у вас нет доступа к серверу обновлений, из-за чего и недоступно удаление службы UPnP. Без полного удаления её можно выключить с помощью пары команд в CLI: no service upnp system configuration save

@eralde в продолжение темы о предупреждающих диалогах: Нашел аналогичный недочет и в диалоге подтверждения извлечения USB-устройства:

@eralde в диалоге подтверждения выключения Wi-Fi сети, через которую подключено устройство, управляющее Кинетиком, затерялось описание: Если эту же сеть попытаться выключить из карточки в dashboard, оно выводится корректно: Проверял на 4.1 Beta 1.

@hellonow @Padavan возникла необходимость на KN-3610 отключить 256-QAM для диапазона 2.4 ГГц из-за проблем со стабильностью подключения некоторых старых устройств. В новом веб-интерфейсе произвел отключение. Убедился, что 256-QAM не работает - канальные скорости клиентов снизились до "стандартных" значений, а из startup-config и running-config для WifiMaster0 удалился параметр vht. Перезагружаю Кинетик, и вижу, что 256-QAM снова включился - стал активным флажок в вебе, канальные скорости подросли. В running-config появился vht, тогда как в startup-config его нет. Получается, его автоматически включила система. В чем возможна причина такого поведения? Стандарт сети для 2.4 ГГц выставлен 802.11b/g/n, для 5 ГГц 802.11a/n/ac/ax. Использую KeeneticOS 4.1 Beta 1. Скрытым сообщением прикрепил self-test до и после перезагрузки.

@eralde нашел парочку небольших багов в поп-апе добавления/изменения правила. 1. Выбираю протокол TCP/UDP, вариант номера порта назначения указал как "равен"/ "меньше..."/ "больше..."/ "диапазон": Далее, не вводя номер(а) портов, выбираю другой протокол, в котором не требуется ввод номера порта или же он "зашит". Кнопка сохранения изменений остается неактивна: 2. Иногда вместо стилизованного выпадающего списка с протоколами отображается стандартный браузерный:

В настоящее время не сохраняется выбор версии интерфейса, всегда открывается новый. Можно обращаться к Кинетику по ссылке вида: http://ip_адрес_или_доменное_имя/index2.html Например: http://192.168.1.1/index2.html https://mykeenetic.keenetic.pro/index2.html В таком случае будет сразу открываться старый веб-интерфейс и им можно будет полноценно пользоваться до следующего входа. Затем снова придется переходить по приведенной выше ссылке.

@eralde @Anna Zhelankina в мобильной версии диалог подтверждения выглядит не совсем красиво: Хотелось бы, чтобы текст предупреждения полностью отображался без необходимости его раскрытия.

Без изменений в 4.1 Beta 0.1.

@eralde после нескольких повторных переключений чекбокса, в новом вебе состояние нормализовалось. В текущем же все-таки залипло активированное.

@eralde Возникла необходимость на KN-3610 выключить 256-QAM в 2.4 ГГц. Перешел на страницу "Мои сети и Wi-Fi", открыл поп-ап настроек Wi-Fi 2.4 ГГц. Деактивировал чекбокс и сохранил настройки. Повторно захожу в поп-ап и вижу, что чекбокс также остался активным, хотя из конфигурации для интерфейса WifiMaster0 удалился параметр vht. Проявляется как в новом, так и в текущем веб-интерфейсе. Проверял на версии 4.1 Beta 0.

В 4.1 Beta 0 обратил внимание, что dns-proxy Кинетика не использует DNS-серверы резервного подключения, пока оно не является основным по приоритету. С одной стороны, DNS-запросы не "утекают" на резервный интерфейс. С другой, если возникает необходимость "завернуть" одно из устройств на резервное подключение с помощью политики доступа, то оно не может разрешить ни один из доменов, т.к. "резервный" DNS игнорируется Кинетиком. Были ли какие-то изменения на этот счет в логике работы dns-proxy на последних сборках 4.1? При откате на стабильную 4.0.7 с имеющейся конфигурацией, проблема перестает воспроизводиться - начинают использоваться одновременно DNS-серверы как основного, так и резервного подключения. Устройство, "завернутое" политикой в резервное, не испытывает проблем с DNS.

@eralde @Anna Zhelankina при использовании выпадающих меню имеют место быть ситуации, когда визуально сложно различить, где еще меню, а где уже элемент на самой странице. Например, настройка кнопок и светодиодов на странице "Параметры системы", где в одном блоке несколько таких меню. В светлой теме, в целом, ситуацию спасает небольшое затенение вокруг: В темной теме это затенение менее заметно, особенно при невысокой яркости экрана: Предлагаю немного изменить цвет фона в выпадающих меню, чтобы они не сливалось с фоном страницы. Или же, как вариант, сделать более заметным их выделение. По большей части это относится к мобильному вебу, где ширина выпадающего меню всегда фиксирована, в отличие от десктопного.

@eralde в 4.1 Beta 0 подправлено. Спасибо! После этой подписи лишний интервал пропал, но я его нашел в парочке других мест:

Воспроизвести можно разными способами. Например, выбрать в веб-интерфейсе компонент для добавления/удаления, запустить обновление KeeneticOS, а затем в процессе отключить интернет-кабель. Обновление прервется. После этого, если открыть поп-ап, то там будет отмечен ранее выбранный компонент, но нижняя панель для установки обновления будет отсутствовать. Другой вариант воспроизведения через CLI - ввести команду для установки отсутствующего или удаления имеющегося компонента (components install ... / components remove ... ), а затем открыть поп-ап. Будет аналогичная ситуация. Этот вариант я записал на видео. Новый веб - https://disk.yandex.ru/d/8FoUQMJl1rTraw Текущий веб - https://disk.yandex.ru/d/sP-YHbDb4uIYuA Отметил чекбокс ip6 через веб-интерфейс, панель появилась. Отменил операцию, этот же компонент отметил через CLI. Перешёл в поп-ап - панель отображается только в текущем вебе. Далее, чтобы отменить изменения, удалил ранее отмеченный неустановленный компонент через CLI, он перестал отображаться. Так как изменений никаких в итоге не осталось - панель не отобразилась нигде.

Понаблюдал несколько дней в 4.1 Alpha 19, никаких проблем с подсчетом трафика устройства более не заметил. Спасибо!

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

@eralde @Anna Zhelankina 1. При использовании десктопной версии, в таблице клиентов отображается системный скроллбар, который выделяется на фоне всех элементов: 2. В текстовом поле фильтрации слева чего-то не хватает. Похоже, там затерялась пиктограмма: 3. В мобильной версии используются стилизованные скроллбары, но белого цвета, как и почему-то границы ячеек таблицы: В светлой теме скроллбары сливаются с фоном страницы. 4. В мобильной версии размер кнопок выбора вариантов отображения таблицы неодинаков, из-за чего они несимметричны относительно центра видимой области. Также кнопкам выбора варианта сортировки немного маловато места - выходят за границу видимой области, а подписи внутри выровнены немного не по центру.