dimon27254

@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 также без изменений.

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

Установил анализатор трафика. Получил в нем аналогичный результат - при отключенном аппаратном ускорителе для устройства учет ведется в любом сегменте. Если включаю ускоритель - в любом сегменте устройство или вообще не отображается на вкладке анализатора, или же считаются килобайты трафика, что далеко от реального потребления. Возможно, есть зависимость от подключения к интернету или конкретных настроек, я проверил на PPPoE-подключении.

@PASPARTU если выключить аппаратный ускоритель, трафик начинает считаться? Проверил сейчас у себя на KN-3010 с последней 4.0 Alpha 15: как в домашней сети, так и в гостевой, а также других сегментах, подсчет ведется только при отключенном аппаратном ускорителе. Если же он включен, то трафик уходит в "незарегистрированные устройства". Ранее проверял только для домашней сети, о чем также писал на форуме:

@eralde в актуальных 3.9 и 4.0 нашел баг, проявляющийся при настройке WISP-подключения. Выполняю поиск сетей, из списка выбираю сеть со смешанной защитой WPA1/WPA2. В поле "Защита сети" скопировался этот вид защиты ("wpa1/wpa2"), а поле ввода пароля недоступно. Вручную выбираю защиту WPA2-PSK из списка и поле ввода появляется. При выборе сети с типом защиты WPA2/WPA3 такой проблемы нет, автоматически выбирается WPA3-PSK и поле ввода пароля доступно.

@hellonow в 4.0 Alpha 15 без изменений.

@hellonow нашел еще один баг, связанный с отображением трафика. Устройство подключено по Wi-Fi к ретранслятору, который соединен кабелем с контроллером. Устройство потребляет трафик из резервного интерфейса IPoE. Это потребление не отображается в системном мониторе и не учитывается, но есть в мониторе трафика для устройства. Как только отключаю аппаратный ускоритель, все нормализуется - в системном мониторе и мониторе трафика отображаются корректные данные. Если включаю назад, в системном мониторе отображение снова пропадает.

@vasek00 могу предположить, что эти сообщения связаны с новым механизмом определения состояния интерфейсов: У меня стоит 4.0 Alpha 14. Замечал их в логе, но не обращал внимание. Они появляются даже при изменении состояния Ethernet портов. Например, если отключить и заново вставить в порт Ethernet-кабель от компьютера: [I] Mar 25 18:09:11 ndm: Network::Interface::Switch: "GigabitEthernet0/0": switch link down at port 1. [I] Mar 25 18:09:11 ndm: Network::Interface::Base: "GigabitEthernet0/0": "ethernet" changed "link" layer state "running" to "pending". [I] Mar 25 18:09:14 ndm: Network::Interface::Switch: "GigabitEthernet0/0": switch link up at port 1 (1000FD/AN). [I] Mar 25 18:09:14 ndm: Network::Interface::Base: "GigabitEthernet0/0": "ethernet" changed "link" layer state "pending" to "running".

@hellonow В 4.0 Alpha 14 при включенном аппаратном ускорителе также некорректно отображается трафик устройств.

В 4.0 Alpha 14 аналогично.

@sergeyk разъясните, пожалуйста, как работает эта фича. Она позволяет по воздуху пробросить vlan'ы и работать с ними как в проводной среде, или же как-то иначе? Можно ли передавать одновременно access и trunk трафик? Например, если я хочу подключить один кинетик к другому по воздуху без использования mesh-системы. Пусть первый работает с access vlan 1 и trunk vlan 2, т.е. как основной роутер, а второй как клиент, который к нему подключается. Пара примеров использования: Vlan 1 пустить в access режиме на 1 порт Ethernet, а vlan 2 на порт 2 также в access. Например, к устройствам, которые находятся в разных сегментах, нет возможности подвести кабель от первого кинетика. А по воздуху можно было бы передать весь этот трафик и распределить на втором кинетике по портам. При использовании mesh-системы это лишь частично реализуемо - через беспроводной backhaul уже передаются все vlan'ы, но все проводные порты второго кинетика будут зеркальны первому и без возможности настройки, т.е. на каждом будет access vlan 1 и trunk vlan 2. Любая ручная попытка изменения через cli приведет к сбросу при первой же команде от контроллера, т.е. первого кинетика. Vlan 1 как интернет-подключение к первому, а vlan 2 включен в bridge сегмента второго кинетика, чтобы на первом его использовать в качестве интернет-подключения. Нестандартный вариант, но успешно мной используемый в проводном варианте. То есть, пусть первый кинетик имеет основное подключение PPPoE, а резервным является подключение ко второму. Второй же имеет основным UsbQmi, а резервным подключение первого. Также еще настроены политики доступа, чтобы один кинетик имел доступ только к основному подключению другого. Если у первого упадет его основное соединение, то он переключится на основное соединение второго. Аналогично и со стороны второго кинетика: если упало его основное подключение, то переключится на основное первого. Если же у обоих упали основные подключения, то, естественно, интернета не окажется ни у одного. В проводном варианте vlan'ы для портов настраиваются через switchport, а затем управляются как отдельные интерфейсы вида GigabitEthernet0/Vlan2. Но как это делается в случае использования беспроводного варианта? Как я понимаю, со стороны первого будет интерфейс AccessPoint, а со стороны второго WifiStation. Но как управлять vlan'ами, которые будут в этих интерфейсах передаваться? Например, добавить или удалить. А также, можно ли будет с каждой стороны иметь доступ к каждому vlan как отдельному интерфейсу по аналогии с проводным? Какие для этого используются команды в cli?

@hellonow в 4.0 Alpha 13 сообщения стали выходить в двойном количестве каждые 2 минуты: [I] Mar 11 07:47:18 kernel: RRM: perform scan notified channel: 9 [I] Mar 11 07:47:18 kernel: RRM: perform scan notified channel: 9 [I] Mar 11 07:47:18 kernel: RRM: perform scan notified channel: 13 [I] Mar 11 07:47:18 kernel: RRM: perform scan notified channel: 13 [I] Mar 11 07:49:19 kernel: RRM: perform scan notified channel: 9 [I] Mar 11 07:49:19 kernel: RRM: perform scan notified channel: 9 [I] Mar 11 07:49:19 kernel: RRM: perform scan notified channel: 13 [I] Mar 11 07:49:19 kernel: RRM: perform scan notified channel: 13

@hellonow в 4.0 Alpha 13 после исправления отдачи теперь и исходящий трафик зарегистрированных устройств уходит в незарегистрированные. Как и в прошлых версиях, при отключении аппаратного ускорителя все восстанавливается. Записал видео с этим поведением. На форуме отображается некорректно, пришлось загрузить на Яндекс.Диск.

Обновился на 4.0 Alpha 13. Отдача теперь корректно отображается на главной странице и ведется её подсчет в статистике. Спасибо!

Подтверждаю исправление в 4.0 Alpha 13. Спасибо!

В 4.0 Alpha 12 все аналогично. Если отключить в веб-интерфейсе флажок "Управление BSS-окружением 802.11k/v" во всех сегментах - новые сообщения RRM перестают выходить. Включаю назад - снова появляются.