dimon27254

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

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

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