Padavan

ma5671a на Lantiq чипсете, скорее всего будет работать только с версии 4.02.C.3, так как эти модули без питания в слоте не показывают свое наличие через пин module absent (mod-def0). Начиная с 4.02.C.3, питание на слот подается безусловно, ранее подавалось только после детекта модуля в слоте по пину.

Потому что в этой модели модуля в DDMI прописан инвертированный сигнал RX_LOS. Вопросы к прямым рукам производителя. Выложите selftest хотя бы мне в личку на форуме, я добавлю ваш модуль в quirk таблицу.

Krais GPON SFP модули это отдельная ниша, они практически все не соответствуют стандарту: - линк среды у GPON модулей отвязан от PCS линка - PCS линк GPON модуль поднимает только после загрузки встроенной OS (45c в среднем) после подачи питания - в DDMI часто некорректная информация - некоторые модули (Lantiq чипсет) вообще не имеют EEPROM и его эмулируют только после загрузки встроенной OS. Хотя по стандарту DDMI информация должна появиться через 300мс после установки модуля. Также эти модули не замыкают на землю пин Mod-Def0 (module absent), если в слоте нет питания. Мы используем quirk таблицу для разных модулей, которые отступают от стандарта. Также давно заготовлен механизм (должен появиться в 4.3), который позволит пользователю запустить практически любой модуль, путем ручной настройки PCS линка, задержек, игнора RX_LOS, приоритет MDI/SFP. Пришлите self-test в поддержку, сделав следующее - перезагрузите Кинетик без модуля в слоте - установите модуль в слот с подключенным волокном - подождите ~90 секунд и сделайте self-test

Потому что по стандарту WPA3/SAE по прежнему используется PSK, только PMK ключ генерится после каждого SAE key exchange. В WPA2-PSK PMK ключ всегда статический. А еще потому, что существует WPA3-Enterprise, который не использует SAE.

Сейчас на столе лежат модули QSC-SFP10GEW QSC-SFP20GEW оба синие (TX 1310nm, RX 1550nm), так вот, они оба заводятся на гигабите в паре с фиолетовыми модулями. На обоих модулях написано что они 1.25Gb/s, про 100 ничего нет. Т.е. есть сомнения, что они вообще могут работать на 125МГц в режиме 100Base-FX. Я еще проверю с двумя KN-2710, попробую порт форсировать в 100Base-FX, станет понятно, поддерживают они 125МГц или нет. На гигабите вообще никаких проблем не увидел. Если заведутся при форсировании 100Base-FX, то придется в настройки вынести скорость порта, чтобы можно было выставить жестко 100Base-FX. - У нас есть медные модули на 100Mbps, так вот, они без проблем работают в KN-2710 в автодетекте. Также есть пара оптических SFP-100LX-20, работающих на 100Mbps, работают в паре как в KN-2710, так и в паре с KN-1010.

Судя по описанию, это чистый 1000Base-X модуль (1250M), он не может работать как 100Base-FX. Возможно в нем отключена inband автонеготиация в режиме 1000Base-X, но это только предположение.

Чтобы разобраться в проблеме, нужна пара таких модулей, так как оптические модули не поднимают SGMII линк без линка среды. Других вариантов нет.

Это неверное заключение. SerDes 100Base-FX на частоте 125МГц поддерживается, такие модули есть на столе и они работают, проверено лично. Порт на кинетике настроен на авто-определение 1000Base-X/100Base-FX и это работает.

vasek00 В общем случае - это означает что именно клиент прислал Deauth пакет, где указал один из возможных кодов Reason. Причин формирования такого пакета может быть великое множество, начиная от чужых Deauth от имени вашего MAC (защита только PMF) так и от любых других причин, известных только самому клиенту. По поводу IoT датчиков. Некоторое время назад разбирался с WiFi датчиком Tuya (температура/влажность). Датчик работает от внутреннего таймера, интервал таймера задается из приложения (применяется при следующем просыпании датчика). Датчик после успешного WiFi подключения шлет в облако порцию данных, получает из облака данные (например смену настроек), затем происходит следующее - он высылает в сторону AP NULL data фрейм с PSM=1 и просто выключает питание WiFi модуля. С этого момента он висит в таблице клиентов на AP с флагом PSM, AP не получает от него ни одного пакета, не работает ARP discovery, вообще ничего, модуль wifi у него выключен. Так вот, если интервал таймера меньше времени Idle timeout на AP (600c на Кинетиках), датчик будится по таймеру и всегда первым пакетом высылает в сторону AP Deauth, затем подключается как ни в чем не бывало. Если интервал больше Idle timeout, AP его отстреливает по таймауту неактивности, но датчик ничего об этом не знает и в любом случае после просыпания, первым делом отправляет Deauth. Это видно при захвате эфира.

vasek00 Дампы давно есть, они все как под копирку одинаковые. Толку от них мало. Мы обсуждали реализацию костыля под 778G/888, но далеко не факт что он появится в прошивке, так как может затронуть других клиентов. Прямого решения проблемы (обман STA со стороны AP) на текущий момент не найдено. И вряд ли оно существует.

GermanAW Рутованный девайс может быть лишь полезным для смены региона WiFi путем ручного редактирования конфигов, либо еще каких-либо настроек, например wpa_supplicant. У вас может получиться решить эту проблему, так как она на стороне клиента. Но это мало полезно для не рутованных девайсов. Еще раз повторю детали данной проблемы - клиент 778G (и часть 888) показывает наличие 11ax (HE) только когда рассылает Probe Request броадкастом подключается к AP через Fast Transition (FT auth + FT reassoc) во всех остальных случаях он скрывает HE IE из своих MGMT пакетов, опираясь на региональное ограничение. Самое забавное это то, что второй пункт выглядит багом Qualcomm, т.е. региональное ограничение не срабатывает при FT auth/reassoc.

Автоматическое назначение BSS color добавлено, попадет в следующий релиз 3.9 (и 4.0). Не требует ручного вмешательства. Функционал Spatial Reuse уже доступен и управляется через CLI. (config)> interface WifiMaster1 spatial-reuse - enable 11ax spatial reuse OBSS PD

Архив получен, спасибо. У вас есть старые Apple клиенты, смените регион в 5ГГц на USA, проблема должна уйти. Отпишитесь по результату. Начиная с версии 3.09, в прошивке отключена подмена кода региона на US, которая ранее выполнялась прозрачно для региона RU, так как старые Apple устройства при обнаружении региона RU отключали либо 11ac (либо форсировали полосу 40 вместо 80), а более старые, отключали даже 11n. Это сделано в угоду новым Apple устройствам, которые видят проблему в разных кодах региона на двух бэндах. Соответственно выставив код US вручную на 5ГГц, вы возвращаете предыдущее поведение.

@Андрей Гриднев Точка доступа (AP) и встроенный Wireless клиент (он же WISP) шарят между собой один ресурс радио (речь об одном бэнде). Физически невозможно заставить встроенный Wireless клиент работать на разных каналах со своей AP. Например, удаленная AP провайдера работает на канале 48. Вы не можете подключиться к нему на канале 48, при этом установив канал, например 149, на AP этого же устройства. Это возможно только в рамках разных бэндов 2.4 и 5. Когда вы ставите Авто, Wireless клиент всегда следует за удаленной AP и становится ведущим для своей AP. При этом AP на вашем устройстве становится ведомой и также переключается на канал, который выставил Wireless клиент. В версии 3.09 управление каналом для удобства добавлено на закладку WISP.

Это не шутка была, wireless подразделение qualcomm давно находится в Индии. Насчет выбора кандидата на подключение между 3010 и 3710, я понял ваш вопрос, попробую воспроизвести. Возможно проблема в отдаче BSS окружения по RRM со стороны 3010. Это может быть критично, если клиент умеет запрашивать по RRM окружение (11k). Тогда он обычно пользуется списком, что ему отдала AP. В остальных случаях кандидата выбирает исключительно клиент, по своим критериям. - У Apple полно проблем с wireless, поскольку уши растут из broadcom. Я могу по пальцам пересчитать, сколько багов было выявлено и сколько было сделано подпорок. И само печальное, что эти баги перманентные и никуда не уходят с обновлением iOS. Уходят только в более новых устройствах, так как более новый чип радио получает обновленный драйвер. Старые так и умирают с багами.

Пока нет возможности зарутовать подобного клиента, чтобы понять почему он так делает. Эксперименты на AP с корректировкой IE в маяках и probe response пока ни к чему не привели. Есть ощущение, что решения со стороны AP не существует, нужно индусам из wireless подразделения qualcomm выпрямлять драйвер (либо настройки). - KN-3710 (и его брат 3810) - на мой взгляд прекрасный девайс, поддерживает WHNAT offload (как старший 2710), а также умеет аккаунтить до 64 зарегистрированных IP хостов через PPE без ущерба для производительности.

Как написал выше, было установлено что нет разницы, откуда такой клиент заходит по FT, хоть с самого себя, коннектится wifi6. Видимо все же есть там какая-то региональная блокировка, которая при подключении путем FT не работает, т.е. выглядит багом, который ее обходит. - Для ободрения могу лишь сказать, что Mi 11 Lite 5G NE умеет 160МГц и при подключении к KN-1810/KN-2510/KN-2710 дает линк 1733 Mbps в VHT. А если подключается в AX на 160МГц, то 2401 Mbps.

Интересное наблюдение - проблемные Qualcomm клиенты коннектятся в wifi6, если даже совершают FT переход внутри своей AP. Ставлю канал 36, подключаю клиента, коннектится путем 4-way hs, видим wifi5. Меняю канал на 149, клиент через несколько секунд заходит на эту же AP по FT и вуаля - wifi6. Отключаю его, подключаю заново, заходит через 4-way hs, опять wifi5. Новые wifi6 WCN клиенты определенно имеют баг.

Насчет макбука не скажу, с новыми Apple девайсами подобных проблем отрезания wifi6 caps не замечено, разве что старые устройства разных годов плохо реагировали на RU код региона. Например, макбук 13 года отключает 80МГц, если видит код RU. А макбук 10 года отключает HT и переходит в 11a, если видит код RU. Напомню, начиная с прошивок 3.09 мы удалили костыль, который подставлял в 5ГГц код US, если выбран регион RU. В пользу новых Apple устройств, которые имеют проблемы, если видят разные регионы на двух бэндах. В любом случае, руками можно задать любой код региона, при необходимости.

vasek00 Ваши дампы, что отправили в поддержку, выглядят как под копирку с Mi 11. - Можно попробовать вытащить системный лог с клиента, когда он не подключается на Wifi6 чтобы хоть что-то понять (если конечно это логгируется). Думаю без рута тут не обойтись, чтобы повысить log facility.

При этом данный клиент броадкастит пробами с поддержкой HE: Т.е. нужно понимать что он сам, по своей инициативе отрезает Wifi6 при подключении. И напомню, что его все же можно заставить подключаться Wifi6, сменив канал и быстро подключив к AP.

Вот наглядный пример, когда клиент сам стреляет в ногу (подключается как 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.