Alex Sh.

Спасибо, посмотрим!

Пропала возможность удаления клиентов в целом. Теперь как в вебе - можно разрегистрировать зарегистрированный клиент соответствующим переключателем, а удалить нельзя. Это было сделано для более лучшего офлайн-режима.

Наш тестировщик тоже замечал этот баг, будем разбираться.

Завожу, должно быть.

Подтверждаю баг: переводы есть, дело не в них. Завел задачу.

Судя по логам, последний раз подобное событие приходило от вашего контроллера 15 апреля. Если авария у оператора, о которой вы говорите, произошла позже, то проблема не на бекэнде, а в контроллере или на сети. Т.е либо контроллер не отправил сообщение о переходе на резервный канал, либо сообщение по резервному каналу не дошло до сервера. Без этого сообщения и второе, о переходе обратно на основной канал, не будет отображено. Я сейчас проверил у себя на 3.6.3, сообщения о смене WAN приходят, функция работает. Попробуйте тоже проверить, если есть возможность.

Т.е стабильно воспроизводится каждое переключение?

Я уточнил, 23.04 проводились работы на серверах, в процессе могли возникнуть такие вот артефакты. К сожалению. А еще к сожалению, откатить обратно или скрыть этот терабайт не получится.

У вас версия KeeneticOS не 3.7.5? На ней нашли был баг с опопвещениями.

При удаленном подключении к роутеру с отключенной службой статус подключенных устройств не должен отображаться. Но я у себя это тоже воспроизвожу, так что надо разбираться ) А при локальном подключении статус показывается корректно независимо от службы.

Да, воспроизвожу у себя то же самое. Сейчас заведу задачу. Благодарю вас.

А вот это поправлено?

@T@rkus Похоже на баг авторефреша экрана. Будем смотреть )

@enterfaza Когда клиент без иконки - он со стандартной шестиугольной иконкой "Generic". Цвет этой иконки не отличается от остальных и зависит от статуса клиента. А задача про синюю иконку заведена, да.

@T@rkus На бете и на релизе+веб сейчас действует две независимые системы уведомлений, поэтому и такое поведение. Это переходный процесс, к следующему релизу все придет в норму.

@T@rkus, действительно, на бете отслеживание отключено до следующего релиза. Это связано с изменением в логике работы с подключенными устройствами. Вы можете включить отслеживание в вебе, и после этого уведомления должны начать приходить. @enterfaza Трекинг, слетевшие иконки смотрим. Про активный фильтр завду сейчас задачу, посмотрим чуть позже.

@enterfaza Нет, цвет иконки отображает статус устройства, а не происхождение иконки. Синяя иконка - это баг. Значит, статус устройства неизвестен. Я попросил iOS-разработчиков посмотреть, что там со статусом не так.

Сейчас сделано так: Если пользователь вручную задает иконку подключенному устройству, эта иконка сохраняется и больше не меняется (включая иконку Generic). Нейросеть может присвоить иконку только устройствам без иконки, заданной пользователем (неважно, зарег. или незарег. устр-во). Иконки нейросети не сохраняются и обновляются каждый час. Если настройки нейросети изменились, или в процессе обучения сеть изменила мнение, иконка может поменяться или быть удалена с устройства. Не самый оптимальный вариант, поскольку, как мы видим, вызывает вопросы у пользователей. Мы еще подумаем, как оп

@T@rkus @drugold Спасибо за репорт. Есть подозрение, что баг уже исправлен в Dev-сборке. Проверим!

Это может происходить на устройстве, которому пользователь вручную не присвоил иконку. Нейросеть в процессе обучения может передумать. Что касается частоты срабатываний, число распознанных устройств сейчас действительно может уменьшиться. Мы столкнулись с тем, что пользователи мало устанавливают иконки вручную, и из-за этого нейросети не на чем учиться. Сейчас выставлен довольно высокий порог точности для нейросети. По мере того, как она будет учиться, этот порог будут переходить все больше девайсов.

Да, нужно сказать, версия вышла неудачной. Дождитесь следующей лучше.

Причина этого поведения стала понятна - событие приходит в демон до того, как тот успевает подключиться к серверу, и отбрасывается. В прошивке будет реализовано накопление событий. Тут понятней не стало - проблема может быть как на стороне сервера, так и роутера. Но можно исключить роутер, добавив фильтрацию дубликатов сообщений. Это также будет сделано в рамках первой задачи. По срокам, правда, ничего не могу сказать.

Да, как я написал в соседней теме, ip hotspot собирается из heighbor + associations контроллера + associations Wi-Fi-системы. Суть проблемы остается той же, просто неверный статус приходит из ассоциаций контроллера. ну и это мне так и остаётся не понятным Не всегда воспроизводится же, нужно подгадать таймауты. Проблема будет решена в будущем, вероятно только не быстро.

@T@rkus Прошивка с дебагом в итоге не понадобилась - разобрались, проанализировав селф-тесты и воспроизведя у себя. Описанная вами ситуация происходит из-за того же, что и в теме @enterfaza. События генерятся одной подсистемой - neighbor, а текущий статус клиента берется из драйвера Wi-Fi - ip hotspot, который в свою очередь строится на neighbor + associations локальный и экстендеров, из которых последние два имеют больший приоритет. Иногда из-за разных таймаутов в подсистеме neighbour и драйвере Wi-Fi-клиент остаётся в списке при ухода из зоны охвата Wi-Fi. Быстро исправить эту пробл

@enterfaza Только сегодня получил комментарии от системных разработчиков. Они проанализировали ваш селф-тест и воспроизвели ситуацию: "Телефон подключен к экстендеру.Клиент перестаёт передавать данные.Контроллер это замечает и генерит событие, которое приходит в виде push'а. Однако в драйвере wi-fi на экстендере есть свой список клиентов (show associations), который периодически подмешивается в show ip hotspot контроллера. Получается так, что из-за разных таймаутов в подсистеме neighbour и драйвере wi-fi клиент остаётся в списке при ухода из зоны охвата wi-fi. <...> Обсудили с команд