dimon27254

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

Заметил, что веб-интерфейс предупреждает о возможной потере управления кинетиком или прерывании соединения при попытке перезагрузки интернет-соединений, ручном обновлении IP-адреса или изменении настроек Wi-Fi сети, через которую ведется управление. Мной был найден случай, который имеет место быть и предупреждение не выведется. Им является отключение единственного доступного интернет-соединения - если его выключить из веба переключателем или же, если это проводное соединение, программно изменить состояние порта (выключить, сменить скорость/дуплекс, автосогласование), через которое идет это соединение, кинетик без предупреждения выполнит это действие и удаленное управление может быть потеряно. В случае с моделями Buddy, если связь с контроллером идет по кабелю и отключен беспроводной backhaul (или же, если ретранслятор находится на большом удалении и не "слышит" контроллер по воздуху) - неудачное изменение настроек его единственного порта приведет к полной потере управления, в результате чего потребуется сброс Buddy и повторная настройка при отсутствии копии startup-config. @eralde возможно ли добавить предупреждения для такого случая? Естественно, что пользователь, занимающийся настройками, должен осознавать, что он делает и каковы последствия, но всегда есть пусть и небольшая, но все же вероятность случайного нажатия или "тыка" по незнанию, в попытке настроить что-то вообще другое. Здесь бы и помогло дополнительное предупреждение, так как несмотря на то, что введенный режим безопасной настройки легко решает эту проблему, но в актуальных 3.9-4.0 он отключен по-умолчанию, и не факт, что пользователь решит его включить.

В 4.0 Alpha 18 есть улучшение после исправления SYS-810. Заработал переход по PMKID в направлении: 2.4 ГГц ретранслятора -> 5 ГГц контроллера. В обратном: 5 ГГц контроллера -> 2.4 ГГц ретранслятора, а также между сетями 2.4 ГГц контроллера и ретранслятора - не работает.

Имеется Wi-Fi система из KN-3010 в роли контроллера и двух KN-3210 в роли ретрансляторов. Также есть проблемный клиент OnePlus 9R, у которого производитель в OxygenOS 13 сломал переходы по FT - телефон держится за первой точкой доступа, не выполняя переход к другой до полной потери сигнала от первой. В логах это выглядит так: [I] Mar 3 11:07:43 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint0": STA(mac) FT authenticated successfully. [I] Mar 3 11:07:43 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint0": STA(mac) MIC differs in key handshaking. [I] Mar 3 11:07:43 ndm: Core::Syslog: last message repeated 4 times. [I] Mar 3 11:07:44 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint0": STA(mac) had deauthenticated by STA (reason: unspecified). С поддержкой выяснили, что проблема в некорректном формировании поля Mesh Peering Management драйвером клиента - превышается максимальная длина пакета, в результате чего точка отвечает ошибкой: Баг-репорт с дампом эфира, где явно видно, что это проблема драйвера клиента, был отправлен в OnePlus, откуда я получил ответ, что исправление будет "в ближайшем будущем". По предыдущему опыту с OnePlus 6, где также производитель много месяцев обещал исправить сломавшийся переход по FT в спящем режиме, но так этого и не сделал, отправив девайс в EoL, решил создать дополнительную сеть в сегменте (необходимо, чтобы клиент имел полный доступ к сегменту) без FT, где будет работать хотя бы переход по PMK-кэшу, т.к. с этим у OnePlus проблем не замечал. Скопировал все настройки из основной сети сегмента, исключив только связанные с FT параметры, включил её в сегмент и попробовал выполнить переходы. Результат оказался аналогичный - телефон делает попытки перейти на другую ТД, но они завершаются неудачно. Согласно логам точки, к которой клиент собирается перейти, выглядит так, как будто клиент подключился и его сразу же отключился, т.к. его "выкинула" ТД: [I] Mar 3 11:08:55 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint2": STA(mac) had re-associated successfully. [I] Mar 3 11:08:55 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint2": STA(mac) had deauthenticated by AP (reason: STA is leaving or has left BSS). Мной был снят дамп эфира в моменты перехода. Согласно нему, точка, к которой клиент собирается перейти, отвечает ему на reassociation request. Затем идет целая пачка deauth-пакетов от точки, которой клиент покидает: Далее вторая точка по каким-то причинам не начинает хэндшейк с клиентом, и в результате, переход не завершается, телефон остается на первой точке. Чтобы исключить проблему именно с OnePlus 9R, попробовал в этой сети выполнить переход с другими клиентами, их поведение было полностью аналогично. Если же создать новый сегмент, в котором настроить сеть без FT, то телефон начинает корректно выполнять переход по PMK между точками, нигде не "застревая". В логах в этот момент нет никаких отключений: [I] Mar 3 11:13:11 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint3": STA(mac) had re-associated successfully. [I] Mar 3 11:13:11 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint3": STA(mac) set key done in WPA2/WPA2PSK. Снятый дамп эфира показал, что deauth-пакетов от первой точки оказалось намного меньше, а вторая начала хэндшейк, в результате чего переход завершился: В попытках понять причину, начал откатываться на более старые версии KeeneticOS с имеющимися настройками. В уже довольно старой 3.7.4 обнаружил, что переход по PMK-заработал в дополнительной сети сегмента, равно как и не сломался в новом сегменте. Снятые дампы показали, что точка, от которой клиент "уходит", вовсе не шлет deauth, а вторая, к которой клиент переходит, начинает хэндшейк и переход далее успешно завершается. Затем, прямо с 3.7.4 пробовал обновиться до прошивок 3.9-4.0, в дополнительной сети сразу же сломался переход по PMK, а в новом сегменте сохранил свою работу. В поддержке сообщили, что в свежих версиях отправка deauth-пакетов клиенту является работой специального механизма, который подчищает уходящих клиентов, чтобы впоследствии, если они захотят вернуться на эту точку, переход корректно выполнился. Для меня осталось непонятным, почему в дополнительной сети сегмента в актуальных прошивках точка не хочет начинать хэндшейк с клиентом, который к ней собирается перейти. @Padavan подскажите, пожалуйста, с чем может быть связано такое поведение? А также, возможно ли со стороны точки доступа проигнорировать поле Mesh Peering Management в пакете от клиента при совершении FT-перехода? Какие в этом случае могут быть последствия в работе FT для сети и её клиентов? Все снятые дампы эфира, self-test с разных версий KeeneticOS отправлял ранее в поддержку. Ticket ID: 126899824.

@hellonow @Le ecureuil в 4.0 Alpha 15-17 без изменений.

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

@hellonow @Le ecureuil в 4.0 Alpha 16-17 также без изменений.

Скорее всего, это все связано с неполадками в работе системного механизма подсчёта трафика. Будем ожидать комментариев от разработчиков.