Padavan

Вот наглядный пример, когда клиент сам стреляет в ногу (подключается как Wifi5, видно отсутствие HE IE):

vasek00 На текущий момент мы знаем о как минимум 5 мобильных устройствах Wifi6 (все на базе Qualcomm), которые скрывают Wifi6 caps (по факту HE IE) при подключении к Wifi6 AP: Xiaomi Mi 11 Lite 5G NE Xiaomi Mi 11T ASUS ROG Phone 5s Asus Zenfone 8 Samsung A73 Все эти устройства ведут себя очень похоже - при подключении к AP они удаляют HE IE из unicast Probe Request и Assoc Request. По факту, согласование caps происходит именно во время Assoc Request/Response. AP не видит в пакете Assoc Request элементов HE IE, поэтому никак не может согласовать с такими клиентами Wifi6, только Wifi5 по VHT IE. При исследовании Xiaomi Mi 11 девайсов было обнаружено, что они действительно при FT переходах могут сохранить HE IE и подключение держится как Wifi6 до первого пере-подключения. Также было обнаружено, что если сменить канал (тест был на 5GHz) и быстро подключиться после смены, клиент почти всегда подключается как Wifi6 (приносит HE IE). Но, если отключиться вручную и переподключиться снова, опять убирает HE IE что приводит к Wifi5. Мы пытались менять разные регионы, убирать вообще COUNTRY IE, толку нет. Понять логику, почему клиент сам себе стреляет в ногу и вырезает Wifi6 пока не удалось. Это немного походит на Intel LAR, когда клиент собирает окружение и принимает решение об усечении стандарта, но прямых доказательств нет. Также форумы 4pda довольно давно обсуждают эту проблему с Xiaomi Mi 11, но никто так и не пришел к пониманию. Проблема одинаковая и имеет место с разными роутерами (не только Кинетиками). Также, люди установившие WW прошивки в Xiaomi утверждают, что если на самом смартфоне в настройках Wireless выбрать регион China (на RU прошивках это недоступно), проблема уходит. Причина точно не в чипсете, так как тот же Samsung S21 FE на 888 абсолютно всегда подключается как Wifi6.

Yes, we can add support such modules, because I2C master from SoC (mt7621/mt7622) is fully functional. Please specify the full name of such modules (for debug).

Вошло пока только 3.08.

4e.Guevara На всех устройствах уже давно такое поведение, а 2.11/2.16 это слишком старые ветки, там только уязвимости и критические исправления. В любом случае вы ничего сами не сделаете. Только ждать следующий релиз 3.07 или 3.08, где будет поправлен ваш кейз.

Речь о следующих сборках прошивки.

4e.Guevara Можно

4e.Guevara При поднятии AP-Client форсируется флаг авто-подключения, который разрешает исполнять site-survey, чтобы искать корневую AP. Видимо у вас она не доступна и клиент делает попытки найти кандидата и перебирает каналы. Это нужно ради гарантированной работы MWS (backhaul STA). В качестве оптимизации могу предложить форсировать это только для backhaul STA, для WISP не делать. Но в любом случае, если на WifiMaster канал задан как Авто, клиент всегда будет исполнять site-survey, чтобы искать корневую AP.

Serghey Для RU региона доступна только одна сплошная полоса 160MHz (36..64). Выбор любого другого канала (кроме 165) переключит AP в режим 80M+80M (при условии что в настройках задано 160). Адаптеры Intel 9260/AX200/AX201 не поддерживают 80M+80M, только сплошной спектр 160M, поэтому AP с ними будет работать только на 80MHz

Serghey enterfaza 802.11 - связь двусторонняя, никакой синхронизации между TX линками двух пиров нет и быть не должно. Т.е. передающий пир может выбирать любой линк, в зависимости от состояния среды и ответов от RX пира (ACK, Block ACK). Но не больше, чем было согласовано при подключении (или динамически по VHT operating mode). Насчет сильного свала (в 88Mbps) - я проверю, возможно действительно есть проблема смены полосы налету, без перезапуска драйвера. Также проверю эффективность работы Apcli 4ss 80MHz vs 2ss 160MHz, когда на AP задан 20/40/80/160MHz.

Уже исправлено в 3.7 Beta 1.0. Для решения проблемы пока будет достаточно отнести на клиента на бОльшее расстояние, слишком высокий уровень у EAP фреймов во время подключения. PS. Проблема не касается других устройств Keenetic.

vasek00 Проблему HT с 1SS воспроизвел, принято к исправлению.

vasek00 По первому дампу я не нашел отличий в assoc response по HT IE, поэтому и предложил проверить, повлияло ли исправление VHT Operation IE. Второй дамп гляну на досуге, может по assoc request что-то и выяснится. Проверил все старые 2SS клиенты 11n что есть под рукой, проблем с 1SS не увидел.

r13 Исправление PAF в функции BssTableInitByBand уже вошло в 3.7 Alpha 16

KorDen Исправление Basic MCS Map в VHT Operation IE уже вошло в 3.7 Alpha 16

vasek00 Исправление Basic MCS Map в VHT Operation IE уже вошло в 3.7 Alpha 16, есть смысл проверить вашего клиента. Есть вероятность, что BCM драйвер все же парсил этот элемент.

Драйвер 7615 в функции BssTableInitByBand пытается аллокировать большой сплошной блок в атомарном контексте, под нагрузкой может случиться подобный page allocation failure. Эта функция требует доработки, чтобы избежать аллокации в атомарном контексте больше 1 страницы памяти. Принято к доработке.

Скурил информацию по Intel LAR/DRS, действительно, все карты сходятся. Как-то упустил это из виду, учитывая что разработка ведется (и 99.9% времени) под Linux, с Windows приходится сталкиваться только при вынужденной проверке различных кейсов. Я видимо случайным образом не застал эту проблему, так как некоторое время с AX200 жил на ядре 5.2, сейчас рабочее 5.10.

Это все танцы с бубном, для запуска AX ничего кроме стандарта выбирать не требуется. Galaxy S10/S20/S21, iPhone SE 2020, iPhone 11/12 - AX работает из коробки. Были у меня подобные танцы с бубном под Win10 и AX200, он через раз коннектился в 11AC. Например, выводишь ноут из сна, коннектится в 11AC, хоть тресни. Я заснифал эфир, клиент тупо не заполняет HE элементы ни в probe request, ни в assoc request. Так что это причуды либо драйвера под Win10, либой самой Win10. При этом под Ubuntu/Manjaro AX200 всегда работает в 11AX.

После захвата просто отметьте эти фреймы (Ctrl + M в Wireshark) и экспортируйте их в отдельный файл. Там нет приватных данных, можно выложить pcapng файлы сюда. Или мне в личку.

vasek00 Если есть возможность, захватите 802.11 фреймы при подключении вашего Broadcom 802.11abgn клиента к KN-1010 и KN-1011, мне для анализа вполне достаточно только фреймов probe request probe response assoc request assoc response

Это тоже нормально (на 7615/7613/7915), текущий TX rate считывается из MCU, поэтому примерно 1.5..2 секунды сразу после подключения будет "пустой" рейт.

Да, похоже с HT IE там тоже регрессия, это пофиксим. - Временные свалы не проблема, такие rate таблицы, главное что возвращается обратно.

KorDen VHT Operation только сегодня поправил, там действительно была регрессия. Но оно не влияет на 11n клиентов, они просто не читают эти IE. Проверю заодно HT элементы. vasek00 Проверьте, 1SS загорается сразу же после подключения (автосогласование) или сваливается в 1SS через некоторое время?

ОК, я проверю. - Проверил, действительно некорректно заполняется MCS Map в VHT Operation, это поправим, спасибо за замечание.