Проблема с загрузкой по WiFi 5 ГГц в ROS 7.1.1

У меня такая же проблема на ROS 7.1.1 (также и на 7.2rc3). CCR1036-12G-4S с точками доступа RBwAPG-5HacT2HnD через capsman в режиме локальной переадресации. UM5 запущен на роутере и занимается EAP-PEAP для беспроводных клиентов. Практически нет никаких других сетей вокруг, так как это находится в крепком швейцарском бункере в подвале. Проверяю 2G-соединение — ведёт ли оно себя так же...

Когда запускаю тест bufferbloat (например), загрузка работает идеально, но отправка постоянно убивает соединение (не всегда, но чаще всего). Иногда такое же происходит и во время сессий в Teams, но там реже. С тестом bufferbloat эту проблему воспроизвести проще и надёжнее.

Я сделал netinstall 7.1.1 на всех устройствах, вручную настроил роутер с нуля. Честно, уже не знаю, что делать...

Открывая терминал, вижу “большие” корректировки времени, которых раньше не было:
feb/01/2022 13:38:44 system,critical,info ntp change time Feb/01/2022 13:38:09 => Feb/01/2022 13:38:44  
feb/01/2022 14:29:15 system,critical,info ntp change time Feb/01/2022 14:28:39 => Feb/01/2022 14:29:15  
feb/01/2022 14:51:38 system,critical,info ntp change time Feb/01/2022 14:51:01 => Feb/01/2022 14:51:38

Прикладываю supout и конфиг (обрезаны чувствительные данные). Есть идеи, в чём может быть проблема? Всё началось с версии 6.49 (или около того) и продолжается до сих пор…

supout.7z (510 KB)  
config.rsc (806 KB)

Понизил все устройства wAP ac до долгосрочной версии 6.48.6, оставив CCR1036 на 7.1.1 (для UM5 EAP-PEAP). Похоже, работает гораздо лучше — Bufferbloat больше не убивает соединение (по крайней мере, за 10 попыток, которые я сделал). Был только один короткий ребут в Teams. Скорость по скачиванию упала примерно на 20%, а по отдаче выросла на 20%. Хотя, честно говоря, это не так уж и важно... Главное, что соединение стало намного стабильнее. Всё ещё не идеально, но уже гораздо лучше.

Спасибо за эту тему. Могу тоже подтвердить, что версия 7.1.* очень плохо работает со старым WAP AC. Скорость загрузки нормальная, пока не начнёшь большой объём передачи данных вверх, тогда обмен данными в обе стороны просто зависает. Откат AP на версию 6.49.2 решает проблему.

Это короткое замечание сильно недооценено! У меня было много проблем в большом многоэтажном здании с использованием множества cap ac и hap ac (6.48.x), управляемых capsman (6.48.x) с каналами 40 МГц, такие как: скорость беспроводной связи падала до <10 Мбит на некоторых устройствах после большого трафика или нескольких дней работы, скорости ниже 100 Мбит даже при чистом канале, около 5 cap ac постоянно блокировали беспроводных клиентов на мосту (принимали клиентов, но трафик не шел). Я по 2-3 раза проверял настройки на проблемных устройствах — все было правильно настроено: VLAN, мощность передачи, ACL и так далее. Я установил на половину из них прошивку 6.45.6, включая все проблемные точки доступа, и все неприятности исчезли. Уже месяц не перезагружаю проблемные AP, скорость скачивания всегда около 200 Мбит/с, загрузки 100-200 Мбит (speedtest, диапазон 5 ГГц, каналы 40 МГц, клиенты с нормальным железом и двухканальным Wi-Fi). Теперь могу даже сравнивать их с Ubiquiti/OpenWRT по скорости и надежности.

Все устройства с проблемами основаны на ARM: cap ac и hap ac2, прошиты долгосрочной прошивкой, как только она стала доступна, при этом генерируют большой трафик из-за плохо написанного софта (500 ГБ до 2 ТБ скачано / 200-300 ГБ выгружено в месяц). Также один MIPSBE, после проверки. Точно не знаю, с какой версии долгосрочной эти устройства стали настоящей головной болью, так как я постепенно увеличивал количество точек доступа, и иногда проблемы были из-за неправильных настроек при развертывании. Одно можно сказать точно — с версии 6.47 я прекратил развертывания, конфигурации были перепроверены, экспериментировал с настройками, найденными на форумах mikrotik, например, отключал аппаратное разгрузку интерфейсов на мостах, включал и отключал адаптивный шум на беспроводных интерфейсах, но проблемы всё равно появлялись. Тестировал всего одно устройство с 6.45.9 и одно с 6.45.6 — они показали лучшую скорость и стабильно работали 3 дня. После того, как я прочитал ваш комментарий в предыдущей теме о вашем положительном опыте с 6.45.6, последовал вашему совету, сделал даунгрейд до 6.45.6 на половине устройств, настроил несколько беспроводных параметров: усиление антенны, установку в помещении на беспроводных интерфейсах (эти настройки сохраняются даже при подключении к capsman?!), и проблемы исчезли (по крайней мере уже месяц никаких сбоев). Теперь могу сказать — спасибо!

Ошибка (2) понятна: 2 Предыдущая аутентификация больше не действительна. Клиент подключился, но не авторизован. https://aboutcher.co.uk/2012/07/linux-wifi-deauthenticated-reason-codes/ Устройство всё ещё подключено, но аутентификация потеряна. (?) Вопрос в том, откуда пришёл запрос на деаутентификацию? «Получена деаутентификация». Самоинициированная? Защита управления? Таймаут при повторной аутентификации (расстояние — динамическое?)? Но ошибки аутентификации нет. Нет попытки повторной аутентификации? Клиент не в курсе деаутентификации?

Становится всё сложнее найти «хорошие» версии ROS. Для hAP Lite последняя стабильная — 6.47.9. Для hAP ac Lite, wAP ac, hAP ac2, кажется, нормально работает с более высокими версиями. ARM-устройства начали нормально работать только после 6.44. Ищу «самую высокую версию ROS, которая ещё работает» (мы уже проектируем под «самое важное и наименее мощное устройство»).