dimon27254

Возможно, переходы не работает из-за проблемы в прошивке 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-серверов:

@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 ГГц с сортировкой по возрастанию/убыванию: