dimon27254

@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 перестают выходить. Включаю назад - снова появляются.

В 4.0 Alpha 12 отдача также не отображается.

Обновил KN-3210 на 4.0 Alpha 12. При обращении к веб-интерфейсу в логе выходит полотно сообщений вида: [C] Mar 8 08:33:29 ndm: Thread: "Queue::DMMYIGYYSBCIFVSJ::http/rci": lock precedence violation: CLOCK (105) after SCHEDULE (208). [C] Mar 8 08:33:29 ndm: Thread: "Queue::DMMYIGYYSBCIFVSJ::http/rci" (536) backtrace: [C] Mar 8 08:33:29 ndm: Thread: Core::Server::OnNdssHostname_(Event::NdssHostname const&)+0x120 [C] Mar 8 08:33:29 ndm: Thread: Core::System::Clock::GetTime() const+0x54 [C] Mar 8 08:33:29 ndm: Thread: Core::Schedule::Object_::GetTime_(unsigned int&, unsigned int&, unsigned int&, unsigned int&) const+0x128 [C] Mar 8 08:33:29 ndm: Thread: Core::Schedule::Object_::AttachTo(Xml::Node&) const+0x370 [C] Mar 8 08:33:29 ndm: Thread: Core::Schedule::Manager::AttachScheduleTo(CString const&, Xml::Node&) const+0xd4 [C] Mar 8 08:33:29 ndm: Thread: libndmCoreObject()+0x5b54 [C] Mar 8 08:33:29 ndm: Thread: Core::Configurator::Execute(Command::Base const*, Command::Request const&, Command::Response&)+0x534 [C] Mar 8 08:33:29 ndm: Thread: Core::Configurator::Serve(Command::Request const&, Command::Response&)+0x320 [C] Mar 8 08:33:29 ndm: Thread: Core::Scgi::Auth::Run()+0x1c40 [C] Mar 8 08:33:29 ndm: Thread: Core::Scgi::Auth::Run()+0x2bdc [C] Mar 8 08:33:29 ndm: Thread: Core::Scgi::Auth::Run()+0x1fec [C] Mar 8 08:33:29 ndm: Thread: Core::Scgi::Auth::Run()+0x2bdc [C] Mar 8 08:33:29 ndm: Thread: Core::Scgi::Auth::Run()+0x1fec [C] Mar 8 08:33:29 ndm: Thread: Core::Scgi::Auth::Run()+0x2bdc [C] Mar 8 08:33:29 ndm: Thread: Core::Scgi::Tools::JsonPost(Core::Configurator&, Core::Scgi::Request const&, Json::Document const&, Core::Scgi::Trace&, Json::Document&, bool*)+0x100 [C] Mar 8 08:33:29 ndm: Thread: Core::Scgi::ThreadPool::Task_::ProcessJsonRequest_(Core::Configurator&, Core::Scgi::Request const&, Core::Scgi::Trace&, Array<char>&, Io::OStream&)+0x174 [C] Mar 8 08:33:29 ndm: Thread: Core::Scgi::ThreadPool::Task_::Run()+0x4ec [C] Mar 8 08:33:29 ndm: Thread: Task::Thread::Run_()+0x3bc [C] Mar 8 08:33:29 ndm: Thread: Task::Thread::Run()+0x38 [C] Mar 8 08:33:29 ndm: Thread: Thread::StartRoutine_(void*)+0x3fc [C] Mar 8 08:33:29 ndm: Thread: start()+0xcc [C] Mar 8 08:33:29 ndm: Thread: __clone()+0x6c Вылазит как при обращении по IP, так и по доменному имени. В 3.9.4, как и 4.0 Alpha 10, таких сообщений не замечал. На контроллере KN-3010 с 4.0 Alpha 12 по этому поводу в логе тишина.

@hellonow отдача в будущих версиях также будет исправлена, или задачу создали только по входящему трафику?

@hellonow в 4.0 Alpha 10, как и в более ранних, отключение аппаратного ускорителя исправляет подсчет трафика.

@Le ecureuil в 4.0 Alpha 8 все аналогично.

В 4.0 Alpha 8 поведение сохраняется. Я заметил, что для проявления достаточно установленной 4.0 на экстендерах, контроллер в этот момент может быть и на 3.9, сообщения все равно будут сыпаться. Посмотрел по логам, на контроллере сообщения появляются с периодичностью ровно в 2 минуты. Очень похоже на работу какого-то фонового сканирования эфира, но не понятно, почему оно срабатывает только при установленной на ретрансляторах 4.0. Снял и прикрепил self-test до и после включения debug-режима. Контроллер на 3.9.3, ретрансляторы на 4.0 Alpha 8.

В 4.0 Alpha 6 все аналогично при работающем ppe hardware.