dimon27254

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

@eralde попробовал на KN-1110 с 4.0.0. Установил компонент easyconfig, затем сбросил на заводские. Действительно, происходит редирект на wizard/initial-setup.

В 4.0.0 исправлено. Спасибо!

Подтверждаю исправление в 4.0.0. Спасибо!

@eralde отлично, ждём-с

@eralde по поводу того бага ещё могу добавить, что проявляется он, как мне показалось, при закрытии окна в момент кратковременного подвисания отображаемых данных, когда они не обновляются чуть дольше, чем обычно. По поводу нового веб-интерфейса хотел бы уточнить. Это будет визуально измененный текущий, или полностью новый и переписанный с нуля? Можно вас попросить показать для затравочки скриншотик хотя бы одной какой-нибудь вкладки, чтобы иметь представление, что нас ждёт? Или ещё пока что рановато?

@eralde если закрыть pop-up окно метрик сигнала сотовой сети, иногда повторно его открыть не удается - кнопка перестает быть активной, хотя окно закрыто. Кратковременно лечится перезагрузкой страницы или повторным входом в раздел Mobile из меню. Проявляется в полноразмерном и мобильном вебе плавающим образом. Причем, необязательно окно закрывать крестиком, достаточно клика вне его области. Видеодемонстрация бага в полноразмерном вебе (Яндекс Диск) Видеодемонстрация бага в мобильном вебе (Яндекс Диск)

@sergeyk в течение недели на 4.0 Beta 3 наблюдал за работой подсчета трафика на резервном соединении. Никаких сбоев не заметил. Спасибо!

@vst сообщения от ping-check при удачных/неудачных попытках проверки соединения также были переработаны? В 3.9 и ниже были такие: PingCheck::Profile: interface * connection check failed. PingCheck::Profile: interface * connection recovered. Вместо них теперь выходят: Network::Interface::Base: "*": "ping-check" changed "ipv4" layer state "running" to "pending". Network::Interface::Base: "*": "ping-check" changed "ipv4" layer state "pending" to "running". Как мне кажется, старые были более понятны.

При использовании Wi-Fi системы на проводных портах как контроллера, так и ретрансляторов, включается протокол STP, предназначенный для предотвращения образования петель. В вашем случае при включении компьютера система обнаруживает, что на проводном порту появилось устройство, и запускает механизм проверки этого порта, не возникнет ли из-за него петля. В этот момент на некоторое время полностью блокируется прохождение всего трафика, в результате чего ретрансляторы теряют связь с контроллером, а так как связи нет, отключаются и все подключенные к ним устройства. Чтобы такой ситуации не происходило, необходимо на контроллере для порта, в который подключен компьютер, с использованием командной строки отключить протокол STP, тогда проверка этого порта не будет выполняться и устройства перестанут отключаться в моменты включения/выключения компьютера. Ранее у меня была абсолютно аналогичная ситуация, все беспроводные устройства отваливались при любом включении/выключении проводных. Решил её с использованием следующей статьи: https://help.keenetic.com/hc/ru/articles/4405876929682-Отключение-поддержки-STP-на-порту-коммутатора-роутера

Нет ли проводных устройств в сети, которые в это время могут включаться/выключаться или перезагружаться?

Продолжил эксперименты и обнаружил, что WG-туннели падают при попытке выключения вообще любого интерфейса, а затем восстанавливаются при его включении. @vst в одной из недавних смежных тем по падению Wireguard вы упоминали тикет NDM-2773. Судя по всему, он относится также и к моему случаю. Есть шанс в ближайших бетах ожидать исправление?

@Le ecureuil @sergeyk в свежих 4.0 (я проверял в 4.0 Beta 3, аналогично было и на Beta 2) нашел баг, при котором нарушается работа всех имеющихся на кинетике Wireguard интерфейсов. Для его проявления достаточно программно (через веб или cli) выключить любой из Ethernet-портов. Помимо сообщений о выключении порта в лог также выводится, что кинетик по каким-то причинам "забывает" всех своих пиров, после чего интерфейсы переходят в режим ожидания: wireguard: Wireguard0: peer "*" (*) (*.*.*.*:*) destroyed Network::Interface::Base: "Wireguard0": "wireguard" changed "link" layer state "running" to "pending". wireguard: Wireguard1: peer "*" (*) (*.*.*.*:*) destroyed Network::Interface::Base: "Wireguard1": "wireguard" changed "link" layer state "running" to "pending". Начиная с этого момента удаленные клиенты не могут подключиться к WG-интерфейсам кинетика. Клиентами делаются безуспешные попытки установить хэндшейк, а в кинетике сыпятся пачками записи вида: wireguard: Wireguard0: invalid handshake initiation from *.*.*.*:* wireguard: Wireguard1: invalid handshake initiation from *.*.*.*:* Попытки перезапуска туннеля со стороны клиентов ни к чему не приводят. Починить сломанные интерфейсы удается только со стороны кинетика - или через выкл/вкл каждого (например, в веб-интерфейсе), или же нужно перевести ранее отключенный Ethernet-порт в любое отличное от "выкл" состояние (например, установить автосогласование, дуплекс, скорость). В логе появляются записи о пересоздании пиров: wireguard: Wireguard0: peer "*" (*) created wireguard: Wireguard1: peer "*" (*) created Далее клиенты успешно выполняют хейндшейк и туннели поднимаются: wireguard: Wireguard0: receiving handshake initiation from peer "*" (*) (*.*.*.*:*) wireguard: Wireguard0: sending handshake response to peer "*" (*) (*.*.*.*:*) wireguard: Wireguard1: receiving handshake initiation from peer "*" (*) (*.*.*.*:*) wireguard: Wireguard1: sending handshake response to peer "*" (*) (*.*.*.*:*) Network::Interface::Base: "Wireguard0": "wireguard" changed "link" layer state "pending" to "running". Network::Interface::Base: "Wireguard1": "wireguard" changed "link" layer state "pending" to "running". Таким образом, имеется зависимость Wireguard-соединений от установленного режима работы Ethernet-порта. При этом, экспериментальным путем выяснил, что изменение режима порта в пределах "невыключенного" состояния, т.е. изменение только скорости, дуплекса или автосогласования без полного выключения порта, к проявлению вышеописанной ситуации не приводят. Посмотрите, пожалуйста, в чем может быть причина такого бага.

@eralde в мобильном вебе заметил еще несколько незначительных погрешностей. 4.0 Beta 3 и более ранние версии. 1. Монитор Wi-Fi: некорректно отображается подробная легенда загруженности каналов. Цветовые блоки промежуточных значений смещены и уходят за границу видимой области: Для сравнения, в полноразмерной версии отображение верное: 2. Список клиентов (в 4.0 Beta 2 и более ранних - список устройств): для кинетика, который работает в режиме ретранслятора и не захвачен в mesh-систему, не отображается текст гиперссылки для перехода в веб-конфигуратор. При этом, сама ссылка работает, так как при клике в области, выделенной красным прямоугольником, переход в веб-интерфейс кинетика происходит. Возможно ли эту ссылку перенести на следующую строку? В полной версии веба из-за большей длины столбца проблем нет. Все правильно отображается:

Возможно, переходы не работает из-за проблемы в прошивке OnePlus 8 Pro. Попробуйте отключить в настройках сети кинетика роуминг 802.11r (FT) и еще раз проверить:

Без изменений в 4.0 Beta 3.

@hellonow недавно провайдер заблокировал 443 порт для доступа извне. Чтобы не потерять удаленный прямой доступ к KN-3010 через доменное имя в KeenDNS, используя 4.0 Beta 2 переназначил порт HTTPS с 443 на 8443. Из интернета все корректно заработало, но если попытаться войти с тем же доменным именем и портом из локальной сети, то веб-интерфейс отвечает ошибкой 403: Попробовал на разных браузерах и устройствах, везде аналогичная ситуация. При этом, находясь в локальной сети, можно войти по адресу https://*.keenetic.link, т.е. со стандартным портом 443, хоть из интернета доступ есть только по 8443. Все это наблюдается, когда на устройствах, подключенных к кинетику, доменное имя резолвится в IP 78.47.125.180. Это баг или фича?

@eralde в 4.0 Beta 2 исправлено все, кроме: Посмотрел, как это выглядит в английской версии. Там наименование политики короче, и оно полностью вмещается: В русской же версии наименование дефолтной политики длиннее. Есть ли возможность немного увеличить ширину столбца со списком политик, чтобы это наименование гарантированно помещалось?

Исправлено в 4.0 Beta 2. @eralde Спасибо!

@vst на актуальных версиях 4.0 в логе при изменении состояния интерфейсов фигурируют записи вида: Network::Interface::Base: "GigabitEthernet0/0": "ethernet" changed "link" layer state "running" to "pending". Network::Interface::Base: "GigabitEthernet0/0": "ethernet" changed "link" layer state "pending" to "running". Network::Interface::Base: "WifiMaster0/AccessPoint1": "schedule" changed "conf" layer state "running" to "pending". Network::Interface::Base: "Bridge1": "ethernet" changed "link" layer state "running" to "pending". Network::Interface::Base: "WifiMaster0/AccessPoint1": "schedule" changed "conf" layer state "pending" to "running". Network::Interface::Base: "WifiMaster0/AccessPoint1": "ethernet" changed "link" layer state "pending" to "running". Network::Interface::Base: "Bridge1": "ethernet" changed "link" layer state "pending" to "running". Network::Interface::Base: "Wireguard1": "wireguard" changed "link" layer state "running" to "pending". Network::Interface::Base: "Wireguard1": "wireguard" changed "link" layer state "pending" to "running". Начиная с 4.0 они теперь будут всегда в логе? Debug-режим у меня отключен.

@sergeyk примерно с 11-12 часов по МСК домен периодически резолвится то в фактический IP, то в старый.

@sergeyk в 4.0 Beta 0.3 обнаружил непонятное поведение KeenDNS в режиме прямого доступа на KN-3010. Основным является PPPoE-подключение с динамическим белым IP-адресом. После подключения IP-адрес, полученный от провайдера, успешно обновляется для домена в KeenDNS и удаленный прямой доступ корректно работает, но по каким-то причинам спустя некоторое время этот же домен начинает резолвиться не на актуальный IP, а на один из старых, который был ранее. Соответственно, становится невозможным доступ к кинетику и службам, работающих на нем. Перезагрузка подключения или кинетика исправляет проблему на некоторое время. За последние несколько дней такое поведение замечаю уже третий раз. При этом, вывод команды "show ndns" или "show ndss" показывает реальный фактический IP, но из интернета (пробовал на нескольких провайдерах с различными dns-серверами, а также через VPN) резолвинг все равно идет на старый адрес. Если через dns.google сделать запрос, также выводится старый адрес. Чтобы в таком случае попасть удаленно в веб-интерфейс кинетика, использую доменное имя *.keenetic.io, работающее всегда через облако, или же из мобильного приложения получаю внешний IP, указываю его в endpoint Wireguard-подключения вместо KeenDNS домена и вхожу по локальному адресу. Прикрепляю self-test в моменты проблемы. Сейчас у доменного имени сохраняется старый IP, кинетик не перезагружаю. Посмотрите, пожалуйста, в чем может быть проблема.

@eralde на 3.9 и 4.0 увидел еще парочку мелочей в мобильном вебе, в разделе "системные файлы" общих настроек системы. 1. Инвертированы иконки начального состояния спойлеров. В полноразмерном вебе корректно отображается, что спойлеры свернуты: В мобильной же версии иконки показывают, будто все спойлеры развернуты: Разворачиваю любой из спойлеров. Иконка меняется на противоположную. В полноразмерной версии проблем нет. Развернутый и свернутый спойлеры отображаются верно: В мобильном вебе получается все наоборот: 2. Файл firmware. Если модель кинетика не вмещается в одну строку, то версия KeeneticOS некорректно выравнивается по левому краю: В случае, если модель умещается в одну строку, проблем нет:

@Vladimir Alferyev сейчас проверил, раздел Tasks заработал. Ошибка больше не выводится. Спасибо!

@eralde в вебе нашел несколько незначительных визуальных багов: Полноразмерный веб, 4.0 Beta 0.3 - в строках "Подключение" большой интервал между элементами: Для сравнения, на другом кинетике с 3.9.8: Дополнительно, не вмещается полностью наименование стандартной политики по умолчанию, это видно на обоих скриншотах. Мобильный веб, актуальные 3.9 и 4.0 - немного не вмещается кнопка "Загрузить из файла" для Wireguard-подключений: Мобильный веб, актуальные 3.9 и 4.0 - обрезается поле ввода IP-адресов для пользователей VPN-сервера. Проверял для SSTP-сервера, возможно, имеет место и при настройке других VPN-серверов: