dimon27254

@hellonow в актуальных ветках 4.0 и 4.1 имеется небольшая погрешность в русскоязычном описании вкладки "Монитор трафика". Ранее, до обновления перевода в одной из ранних 4.0, предложение начиналось с "Зарегистрируйте...".

@eralde в окне просмотра настроек устройства не отображается никакая информация, постоянно висит анимация загрузки. В консоли Chrome DevTools выводится следующая ошибка:

@eralde Предлагаю реализовать в веб-конфигураторе возможность установки нестандартного номера порта для управления кинетиком через HTTPS. В CLI это уже доступно начиная с 4.0. Например, позволить пользователю сделать выбор из перечня портов, поддерживаемых службой KeenDNS, по аналогии с протоколом HTTP.

Несмотря на то, что это лишь первая публичная версия, не могу не сообщить о найденных визуальных погрешностях. 1. В десктопной версии меню-гамбургер не сворачивается автоматически после клика по нужному пункту и остается развернутым несмотря на то, что было ранее свернуто. В 3.x если было свернуто, то после клика по пункту автоматически снова сворачивается. 2. Dashboard, плитка "Интернет": подписи оси времени в графике скорости по подключению оформлены другим шрифтом: 3. Подписи кнопок выбора варианта графика в мониторе трафика также оформлены другим шрифтом: 4. Dashboard, плитка "Монитор Wi-Fi": в подписях кнопок также другой шрифт: 5. Для подключения типа GigabitEthernetX/VlanX некорректно отображается наименование: 6. Dashboard, плитка "Приложения": выводится список всех возможных приложений, которые даже недоступны для установки на тот же, например, KN-3010: 7. "Мои сети и Wi-Fi", сегменты сети: чек-бокс ограничения скорости доступен несмотря на то, что шейпер трафика не установлен: 8. Десктопный веб: начальной позицией всех всплывающих окон является центр видимой области. Для маленьких окошек это хорошо, но те, которые вмещают много информации в высоту, также оказываются в центре, и их требуется прокручивать: 9. Десктопный веб, форма входа, "Другие возможности управления": QR-код достаточно мелкий и трудночитаем: 10. Приоритеты подключений, применение политик: не отображается русскоязычное наименование стандартных сегментов: @eralde вы не против, если в будущем я буду добавлять в данный вопрос другие возможные визуальные баги, или лучше создавать новый?

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

@eralde новый веб мне понравился: красивый, минималистичный, и при этом, как я понимаю, станет еще более функциональным по сравнению с 3.x. Спасибо за проделанную работу! Функционал настройки положения плиток на dashboard очень хорош, но, к сожалению, из-за него теперь неудобно просматривать мобильную версию этой страницы. При попытке скроллинга начинают перемещаться все плитки, а сама страница при этом не прокручивается, о чем также упомянул @PriSonerS61: Возможно ли сделать перемещение, например, по двойному тапу по плитке, чтобы случайно её нельзя было перетащить в другое место? Или же, сделать как в десктопной версии, перемещение только при удержании на специальной области каждой плитки?

@hellonow @Infy на версии 4.0.2 FT-переходы в гостевой сети корректно заработали. Спасибо!

Также подтверждаю исправление в 4.0.2. Спасибо!

@hellonow @Infy @Padavan С переходом на 4.0.1 заметил, что в гостевой сети перестали работать FT-переходы. Устройства постоянно пытаются переключиться между узлами Wi-Fi системы, но им это не удается, упорно держатся за одну точку до полной потери от нее сигнала. Весь лог контроллера и ретрансляторов, между которыми идет переход, засыпан сообщениями вида: ndm: Network::Interface::Mtk::WifiMonitor: "WifiMaster0/AccessPoint1": STA(*) FT authentication rejected (status code: 53). При этом, в сегменте "домашняя сеть" все работает корректно.

@Infy @hellonow в 4.0.1 у меня аналогично в незарегистрированных устройствах висит один из KN-3210. Причем, отображается он как устройство, принадлежащее сегменту "Гостевая сеть". В логах контроллера по данному ретранслятору, в отличие от второго, нет записи вида: ndm: Network::NeighbourTable: host "*" is an alias of the extender "*". Похоже, по каким-то причинам система не поняла, что это один и тот же ретранслятор, но имеющий дополнительный MAC-адрес для неосновного сегмента, и поэтому считает его отдельным устройством, которое можно захватить в Wi-Fi-систему.

@eralde @admin в 4.0.1 на KN-1110 мастер заработал, спасибо!

@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-систему, не отображается текст гиперссылки для перехода в веб-конфигуратор. При этом, сама ссылка работает, так как при клике в области, выделенной красным прямоугольником, переход в веб-интерфейс кинетика происходит. Возможно ли эту ссылку перенести на следующую строку? В полной версии веба из-за большей длины столбца проблем нет. Все правильно отображается: