dimon27254

Исправлено в 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-серверов:

@sergeyk В скрытом сообщении от 25 марта записывал видео, как это выглядит. В нем я показал, что устройство выходит в интернет через политику по умолчанию, в которой подключение, затрагиваемое вышеописанной проблемой, является резервным. Устройством с приведенным MAC открыто 4 соединения к хосту с адресом назначения, принадлежащим подсети резервного подключения. В таблице маршрутизации показал, что маршрут к хостам этой подсети идет через интерфейс резервного подключения IPoE, т.е. потребление не может идти через основной PPPoE-интерфейс. Через эти 4 соединения устройство принимает входящий трафик от хоста. Это потребление в мониторе трафика для самого устройства правильно показывается как в скоростном, так и в количественном измерении, но в статистике по подключению оно полностью отсутствует. Если я выключаю ppe hardware в веб-интерфейсе, это потребление появляется в статистике резервного подключения, как только снова включаю - перестает отображаться.

@sergeyk по самому устройству система считает трафик корректно, потребление отражается для устройства в мониторе трафика. Но по каким-то причинам это потребление не отображается для резервного соединения и не считается в статистике принятого/отданного по этому соединению.

@sergeyk меня снова посетила эта проблема. Какое-то время с того сообщения все работало корректно, но с одним из недавних обновлений 4.0 начала проявляться плавающим образом. Иногда подсчет не работает сразу после перезапуска контроллера, иногда отваливается и сам восстанавливается во время работы. Как и ранее, при отключенном ppe hardware учет ведется корректно. Как только включаю, все "ломается".

@Julia Rybakova не могу открыть раздел Tasks, выводится ошибка 500: Что-то сломалось в этом разделе на моем аккаунте, или это известная проблема? Пробовал войти с различных устройств в свой аккаунт, везде аналогичная ситуация. Несколько недель назад все работало корректно. Первый раз ошибку увидел, когда хотел обновить сеть из кинетиков. Нажал на кнопку "Update", далее открылся пустой раздел Tasks, подвис на некоторое время и появилась эта ошибка. Теперь не могу просматривать статус любого действия, выполняемого с кинетиками, за которым следует переход в раздел Tasks - всегда ошибка 500, хотя само действие успешно выполняется, о чем получаю сообщение через бота Keenetic RMM.

В 4.0 Beta 0.3 после исправления SYS-845 корректно заработали переходы по PMKID во всех направлениях и диапазонах в дополнительной сети сегмента. Спасибо!

@eralde в 4.0 Beta 0.3 сломалось отображение информации о каналах сети. Вместо номеров каналов выводится [object Object]: В 4.0 Beta 0.2 отображение корректное:

@eralde в 4.0 Beta 0.3 сортировка по номеру канала заработала корректно. Спасибо!

@eralde подтверждаю исправление в 4.0 Beta 0.3. Спасибо!

@eralde в 4.0 Beta 0.1-0.2 без изменений.

Очень странно, но в 4.0 Beta 0.1 сразу после перехода с Alpha 20 их не было. Сделал повторную перезагрузку, и на момент написания предыдущего сообщения их также не было. Спустя несколько минут появились, а затем примерно через 2 часа пропали. В Alpha 20 даже после нескольких перезагрузок их не замечал.

@sergeyk начиная с 4.0 Alpha 20 сообщения RRM стали выходить только при инициализации контроллера и ретрансляторов, как в 3.9. Были внесены какие-то правки?

@sergeyk в 4.0 Beta 0.1 исправление подтверждаю. Теперь подсчет ведется корректно. Спасибо!

@eralde на актуальных 3.9 и 4.0 в интерфейсе окна "выключение режима безопасной настройки" имеют место быть небольшие визуальные баги: 1. Между строками текста заголовка окна отсутствует интервал, в итоге они накладываются друг на друга. В мобильном вебе это более ярко выражено, но также присутствует и в полноразмерном варианте: 2. В мобильной версии кнопки этого окна расположены без межстрочного интервала (только мобильный веб). 3. Возможно и фича. Окно занимает почти весь экран, тогда как схожие по компоновке окна fail-safe mode используют примерно половину экрана (только мобильный веб). На скриншоте из мобильной версии видны все три пункта: Для сравнения, другое окно fail-safe mode:

@eralde на актуальных 3.9 и 4.0 в мониторе Wi-Fi некорректно выполняется сортировка списка сетей по номеру канала. Похоже, что она ведется исходя из первой цифры номера канала, а не всего числа целиком, т.к. после 1 может оказаться 10, а перед 36 появляется 132. Примеры сканирования диапазонов 2.4 и 5 ГГц с сортировкой по возрастанию/убыванию:

@sergeyk прикрепил.

В 4.0 Alpha 20 есть изменения. В мониторе трафика отображение исправлено, но теперь сломалось в системном мониторе на главной странице для проводных клиентов. Реальное потребление проводного клиента в мониторе трафика: В системном мониторе для подключения, через которое проводное устройство потребляет трафик, ничего не фиксируется: Иногда какая-то часть попадает, но данные не соответствуют реальности: Если отключить аппаратный ускоритель, отображение восстанавливается:

Это возможно в ситуации, когда, например, сгоревший после грозы WAN-порт решили переназначить на LAN. Далее, спустя длительное время, какое-то из проводных устройств, подключенное в один из оставшихся LAN-портов начало сбоить или некорректно себя вести, и чтобы локализовать проблему, порт, куда оно подключено, решили выключить. В разделе "Сетевые разъемы" в общих настройках переназначенные порты никак не помечаются (возможно, так и задумано), цветом выделяется только реальный WAN-порт. В итоге, по собственной невнимательности, пользователь, удаленно пытающийся решить проблему, может выключить не тот порт и потерять управление, так как он не посмотрел реальную разметку портов в системном мониторе на главной странице. В таком случае, предупреждение о том, что он пытается выключить порт, через который кинетик выходит в интернет, дало бы возможность пользователю обратить внимание на свое действие и отменить его "пока не поздно". Если это возможно реализовать хотя бы для самого соединения (не для порта) в виде окна с подтверждением или отменой действия по аналогии с тем же ручным обновлением IP-адреса, это уже было бы очень хорошо. При работе с веб-интерфейсом через компьютер, нужно очень сильно постараться, чтобы случайно выключить. А в мобильном вебе это вполне можно сделать, например, случайно задев её при скроллинге страницы подключения, если пользоваться телефоном правой рукой. Пример возможного случайного выключения: https://disk.yandex.ru/i/0y3RaNmht4jFHQ

Безусловно, это проблема прокладки между стулом и монитором, т.е. пользователя, который может неосознанно сделать удаленно все что угодно, и для подстраховки от таких случаев очень полезен режим безопасной настройки. Как мне кажется, при ручной попытке обновления IP-адреса вероятность потери удаленного управления ниже, чем при полном отключении соединения, но предупреждение о предстоящем обновлении адреса при этом выводится. Или это "защита от дурака" по той причине, что команда находятся на главной странице, и там выше вероятность неосознанного "тыканья" везде где можно, а все настройки, которые пользователь делает уже в конкретных пунктах меню, должны делаться с пониманием возможных последствий?