[[4.1.A.9] - All devices started connecting as wifi5 20mhz instead of wifi5 80mhz]

PriSonerS61 , KYTECHNGAMIN

Thanks for your feedback, only MT7615D-based devices was affected, bug already fixed, update is coming soon.

[[4.1.A.9] - All devices started connecting as wifi5 20mhz instead of wifi5 80mhz]

Предварительный анализ показал, что зацепило только устройства на базе MT7615D (с DBDC), проблему пофиксили, выражаю благодарность за оперативный feedback.

[Firmware faults Giga (KN-1010) 3.9.x - 4.x]

M_Mikhail

We understand you opinion. Thanks.

I think we can offer you a solution.

[Firmware faults Giga (KN-1010) 3.9.x - 4.x]

M_Mikhail

Since 3.09, any Keenetic device use workaround for Full Duplex peer w/o AN mode:

Conditions:
- Keenetic side: port in AN mode
- Peer side: port in 10 or 100 w/o AN mode

Keenetic side will try second link-up in FD mode (see syslog). We assume that no longer exists real devices with 10 or 100 Mbps Half Duplex w/o AN. 

This workaround usually need for ISP.

If you have such devices, you can set Half Duplex mode w/o AN to desired Keenetic port.

[Firmware faults Giga (KN-1010) 3.9.x - 4.x]

10 часов назад, M_Mikhail сказал:

Different, classic NE2000 cards, NFORCE chipset based, mid 2000 notebooks, all fail

All these devices configured as 10HD w/o AN?

Why 10Mbps Half Duplex w/o Auto Negotiation?

[Firmware faults Giga (KN-1010) 3.9.x - 4.x]

M_Mikhail

Please show syslog after cable plug - from 3.08 and from 3.09.

[Wifi 36A5 микрокод 7615]

20190612110649 - нужная версия, свободная от проблемы свала.

Вошло в 36А5, также войдет в 3.05 (вероятно С4).

Надо будет поправить описание.

[3.5.1 сваливание в 40 МГц]

enterfaza

Если клиент регионально не ограничен, то оно нормально работает на 80МГц (в соответствующих условиях) на прошивке 3.4 (если речь об устройствах на MT7615).

Если клиент ограничен, ему только один путь - 40МГц. На полосе выше 40, он не может физически принимать data фреймы, которые размазаны по спектру 80. Надеюсь это доступно для понимания.

[3.5.1 сваливание в 40 МГц]

supilot

Не нужно все смешивать в кучу. Это разные проблемы. Есть также и Android устройства, которые режут полосу RX по регионалке и их не вправить никакими настройками, только рутовать смартфон. У Apple iOS регионалка гарантированно отключается решением выше, проверили на нескольких устройствах. Вероятно ее можно преодолеть другими способами, например отключив вообще трансляцию кода региона с AP. С яблочными устройствами всегда есть масса нюансов. Также по опыту могу сказать что обновление iOS на старых и новых устройствах - это не совсем одно и тоже. Старые устройства обычно не получают обновления Wifi драйвера вместе с обновлением самой прошивки.

ALL

Сухой остаток:

• Новый микрокод чипа MT7615 лучше справляется с дурными клиентами, включающими регионалку без уведомления, он практически незаметен для пользователя таких устройств, садится быстро на 40 и скорости соответствуют полосе 40.
• Предыдущий микрокод заметно хуже справляется с такими клиентами, скорость долго плавает из-за ретрансмитов, он гораздо больше требует времени чтобы вправить клиента в 40, при этом время от времени опять выпрыгивает на 80. Пока он не на полосе 40, скорость TX очень плохая, так как идет потеря данных, клиент не слышит половины спектра. Однако, он прочнее сидит на 80 и не дает ложно спрыгнуть на 40 для нормальных клиентов, слушающих всю полосу 80.

В 3.06 уже сейчас доступна возможность любого зарегистрированного клиента прибить к VHT40. Также есть планы пообщаться с вендором на тему ложного спрыгивания в 40. В любом случае в 3.06 будет решение, которое должно вернуть "стойкость" в полосе 80 для клиентов без ограничений. Напоминаю, что тот же MT7613 ведет себя сейчас нормально, поэтому речь конечно-же о конкретных устройствах.

Для те кто "не в теме", напомню, что ни NDM, ни ядро, ни даже сам wireless драйвер (если речь о чипах новее MT7612) не отвечает за линк. По факту, тот линк, что вы видите в Web, запрашивается напрямую из микроконтроллера чипа (отдельный DMA канал для связи хоста и внутреннего микроконтроллера). И то, что управляет этим линком, находится в закрытом микрокоде, который загружает драйвер.

[3.5.1 сваливание в 40 МГц]

Чтобы опровергнуть выводы о том что якобы это регрессия именно 3.5.1 прошивки, а также приостановить лишний флуд на эту тему, было проведено исследование, которое показало, что свал в 40МГц - исключительно "заслуга" Andes микрокода 20191220015534, который вошел с самого начала в 3.5 сборки. Причем заостряю внимание - свал нормальных клиентов, которые сами не режут полосу 80 по региону.

Был взят последнний срез прошивки 3.06 с драйвером 5.0.5.0, который был сначала собран с микрокодом 20191220015534, затем была собраная такая же прошивка с тем же драйвером, но с микрокодом 20190612110649, который был до этого в прошивках 3.04 и 2.16.

На микрокоде 20191220015534 происходит практические мгновенный дроп в 40 МГц, когда последовательно идут ретрансмиты 80..100 data фреймов. Это прекрасное решение, чтобы пригвоздить плохиша, зарезавшего RX полосу на 40 и не сообщившего об этом. Однако, это дает со временем ложный свал в 40 для нормальных 80 МГц клиентов.

Микрокод 20190612110649 ведет себя совершенно иначе, поведение примерно соответствует текущему поведению чипа 7613. В этом есть минус, он заметно хуже справляется с задачей сброса плохишей с 80, однако из-за этого он прочнее сидит на 80 и не дает спрыгнуть на 40 при малейшем чихе (пачки ретрансмитов при ухудшении условий передачи).

 

 

 

[3.5.1 сваливание в 40 МГц]

У меня к S10 на Exynos + BCM тоже вопросов нет.

Тем не менее, сегодняшний свежий тест наглядно показал, что MT7615 на текущей фирмвари практически мгновенно дропает Apple с региональным ограничением (еще до отключения ограничения) в 40. Чисто по ретрансмитам, буквально 100 data фреймов c ретрансмитами и уже дроп в 40. Тот же MT7613 сильно дольше держится, пока не дропнет его в 40. Нужно провести исследование по сравнению с предыдущей версией микрокода MT7615 (20190612110649), которая была в 3.04 (и да, она же была в 2.16)  

 

[3.5.1 сваливание в 40 МГц]

ALL

Свежая информация для владельцев Apple устройств.

Описываемая выше проблема регионального ограничения, появившегося с версии iOS 13 решается следующим образом. Заходим в настройки iOS:

Настройки -> Конфиденциальность -> Службы геолокации -> Системные службы (внизу) -> Передача данных и беспроводные сети, отключаем ползунок. Возникнет диалог подтверждения, тапаем Выключить.  

Переподключаемся заново к AP и вуаля, 80 МГц теперь работает на всех каналах, как и ранее до iOS 13. Проверено на iPad Air2.

 

[3.5.1 сваливание в 40 МГц]

Селфы не помогут в расследовании данной проблемы.

В 3.06 мы вполне можем вернуть микрокод от 5.0.4.0 драйвера, если удастся подтвердить регрессию по rate_ctl. Тем более 3.06 есть возможность с помощью галочки задефолтить кривых клиентов в vht40.

Вполне возможно что вендор пытался улучшить авто-переход в полосу 40 по ретрансмитам, для решения того что я описывал выше, при этом, конечно же это могло повлиять на ложный уход в 40.

[3.5.1 сваливание в 40 МГц]

Space Alex

Для нас в техническом плане очень важно понимать, в каких рамках прошивок возникла предполагаемая регрессия. И не менее важна модель Keenetic, так как все индивидуально для каждого чипа.

[3.5.1 сваливание в 40 МГц]

Также хотелось бы поговорить по новым прошивкам для Keenetic.

Для чипов MT7615 переход на драйвер 5.0.5.0 с более свежим микрокодом произошел при переходе с прошивки 3.04 на 3.05 в конце апреля. С тех пор версия микрокода не менялась, соответственно стратегия rate_ctl, которая управляет скоростью линка к клиенту, измениться не могла.

Для чипов MT7613, микрокод обновляется чаще, последний раз обновился 11 сентября.

Версия микрокода сейчас видна в системном логе при загрузке модуля драйвера.

Если пытаться анализировать проблемы свала клиентов в 40МГц, в диапазоне 5ГГц, то всех клиентов можно разбить на несколько групп:

• клиент имеет региональное ограничение и уведомляет о полосе 40. Такие клиенты уходят в 40 сразу при подключении или почти сразу по уведомлению VHT Operation Mode Notify. Работают хорошо на всех Keenetic, включая старые устройства на чипах MT7610/7612. Все эти уведомления прекрасно видны при захвате эфира 802.11.
• клиент имеет региональное ограничение и НЕ уведомляет о полосе 40. На старых Keenetic (MT7610/7612) всегда все плохо, скорости очень низкие, для них решение только ставить полосу 40 руками или в 3.06 ставить галочку "Режим VHT-совместимости" в карточке клиента. На новых Keenetic (MT7615/7613) логика rate_ctl может их быстро скинуть в 40 и скорость наладится. Однако 100% гарантии сброса в 40 нет, поэтому также лучше в 3.06 ставить галочку "Режим VHT-совместимости".
• клиент не имеет регионального ограничения и работает в 80МГц на любом блоке каналов. Если такой клиент выбрасывается на 40, нужно смотреть эфир, слал ли он сам Action пакеты VHT Operation Mode Notify или нет. Если не слал, значит были ретрансмиты и логика rate_ctl его туда скинула. Это поведение на новых чипах зависит только от версии микрокода Wireless чипа.  

 

[3.5.1 сваливание в 40 МГц]

Напоминаю, что существует достаточно большое кол-во мобильных клиентов, прошивка которых включает региональное ограничение в 5ГГц. Начиная с iOS 13, это постигло и многие устройства Apple, например iPad Air2 и iPhone 6S (для Apple уже найдено решение, см. мой пост). Также региональное ограничение наблюдается на некоторых моделях мобильных устройств Huawei, LG, Apple (преимущественно на старых wifi чипах Broadcom).

В чем выражается региональное ограничение - такие устройства ограничивают полосу 40МГц в 5ГГц 11ac.

У тех устройств, где клиентский STA драйвер умеет делать это правильно, при подключении, в пакете Assoc Request он заполняют поле VHT Operation Info, где указывают Channel width 20/40. AP, понимая что такой клиент не поддерживает 80МГц, заносит его к себе в WCID таблицу с полосой 40 и работает с ним всегда не выше чем 40. Также, такие правильные клиенты могут при подключении в Assoc Request совсем не заполнить VHT Operation IE (при этом подключение произойдет с полосой 80), но через некоторое время прислать Action пакет VHT Operation Mode Notify, где просят переключить полосу на 40 (либо число стримов на 1). AP, получив такой пакет, переключает их в требуемый режим, до тех пор, пока клиент не пришлет новый Action пакет с VHT Operation Mode Notify с другим режимом. С такими устройствами всегда будет все хорошо.

Подавляющее большинство не очень "свежих" мобильных клиентов, которые включают региональное ограничение в 5ГГц, совершенно никак не информируют AP о том, что они ограничены 40МГц. Они не делают этого при подключении (VHT Operation IE отсутствует) и не присылают Action пакет с VHT Operation Mode Notify. С такими устройствами все идет по плохому сценарию, по той причине, что у них RX фильтр на фронтэнде режет полосу до 40. А сценарий такой:

• новые чипы MT7915/7622/7615/7613 имеют внутри микрокода интеллектуальный rate_ctl, который через несколько десятков (сотен) отправленных пакетов в сторону клиента на полосе 80 по не-получению ACK и накручиванию ретрансмитов, может переключить такого клиента на полосу 40 и держать его там неопределенного долго. Весь механизм rate_ctl в этих чипах находится внутри микрокода. Версия микрокода видна при загрузке прошивки в системном логе. Если микрокод не поменялся между прошивками, нужно понимать, что rate_ctl не изменился. Снаружи он практически не управляется (кроме включения фиксированного рейта). Однако, механизм броска таких клиентов на 40 не всегда надежно срабатывает, при этом рейт плавает вниз до 6 и обратно, а полоса не высаживается в 40. При этом наблюдается сильная потери скорости (2..10mbps).  
• cо старыми чипами MT7610 и MT7612 этот сценарий сразу же ведет к сильной потери скорости, она падает до 2..10mbps, потому что драйвер не может переключить такого клиента на 40. А даже переключив, быстро выбрасывает его опять на 80, потому что при 40 ре-трансмиты исчезают.

Для того чтобы хоть как-то решить эту проблему с такими клиентами (а она в принципе нерешаемая, если клиент режет полосу по регионалке и не информирует об этом), в 3.06 прошивке появилась возможность любого зарегистрированного клиента "прибить" к VHT 40. В web доступна галочка "Режим VHT-совместимости" в карточке клиента. Это одинаково хорошо работает c любыми чипами, как новыми, так и старыми.

Непосредственно по Apple, могу привести пример, что iPad Air2 RU, на iOS до 13 версии работал абсолютно на всех каналах в 80МГц, даже на блоке 132..144. С iOS 13 все каналы зарезали до 40, кроме 3 поддиапазона (149..161), там по-прежнему работает на 80. И печаль в том что его драйвер также никак не уведомляет о полосе 40. Я проверял на последней iOS 14.1, ничего не изменилось. На новых чипах он довольно быстро высаживается на 40МГц и для подобных клиентов это наоборот не минус, а плюс. На старых чипах MT7610 и MT7612 все также плохо, поэтому только новая галочка в 3.06 позволяет решить проблему достаточно красиво.

 

[KeeneticOS: 3.5 Beta 7, или сново про поломку поддержки DVB]

Проблема подтверждается, будет исправлена в очередной сборке.

[Периодический отвал от WiFi - клиент Galaxy S10]

Цитата

есть подозрение что сломалось после 3.4.3 надо будет проверить

Очень сомневаюсь, в 7615 драйвере 4-way hs не менялся. Было несколько исправлений 2-way hs (group rekey) а также множество исправлений по FT примерно с мая. С вашими клиентом явно проблема в 4-way hs.

-

Глянул по ссылке, там никакой конкретики. При этом другой человек пишет, что ему увеличение max retries to 4 and timeout to 2000 никак не помогло. Лучшее решение - сделать дамп эфира к AP во время подключения с ошибкой и к той AP, к которой заведомо подключается успешно. Я разберу дампы и возможно смогу помочь. Если сможете это сделать, присылайте сразу в техподдержку, мы каждый день на связи.

 

[Периодический отвал от WiFi - клиент Galaxy S10]

All

Если AP застреливает клиента с сообщением had been aged-out and disassociated (retransmits limit reached), это означает что при передаче данных клиенту, клиент не прислал ни одного ACK/Block ACK на серию передач к нему. В итоге после последовательного накопления 2000 ретрансмитов, считается что клиент мертв (например просто ушел из зоны связи) и удаляется. Важно что выполняется проверка, если клиент находится в PSM режиме, он не удаляется. Так что с большой долей вероятности клиент ушел в Power Save Mode, не уведомив AP.

По поводу согласования GTK ключа (bcast/mcast) трафик, в свежих версиях 3.04 выводится подробная информация о Group rekey. Если у вас rekey отключен, то пере-согласование не выполняется и GMK на AP не меняется. Рекомендуемый период Group rekey для AES шифрования - 86400 секунд (сутки). Если Group rekey прошел не успешно (например клиент уснул и не ответил в течении минуты), то драйверы 7615 и 7613 сейчас удаляют клиента с ошибкой Group rekey timeout, поскольку AP меняет GMK и все кто не получил новый GTK, не смогут получать bcast/mcast фреймы.

 

[Периодический отвал от WiFi - клиент Galaxy S10]

Dick

Нужно смотреть эфир 802.11 во время подключения такого клиента. Либо клиент слишком часто повторы EAPoL Msg2/4 шлет, либо наоборот долго отвечает. С нашей стороны драйвер выполняет до 3 повторов, если от пира нет EAPoL пакета в течении секунды. С другой стороны, неверный MIC говорит о том что либо PSK неверный, либо клиент несколько раз пачкой шлет EAPoL Msg2 с одним SNonce.

Можно сказать, что чип здесь не имеет значения, так как 4-way хендшейк программный.

 

Цитата

 

Похожая проблема у другого производителя правиться параметрами

config advanced eap eapol-key-timeout
config advanced eap eapol-key-retries

 

 

Было бы интересно на это взглянуть.

 

[(web) галочка на "DL MU-MIMO"]

1) MU-MIMO переименована в DL MU-MIMO (Downlink) по причине совместимости с Wifi6 (там добавляется Uplink)

2) MU-MIMO в 2.4GHz невозможна по дизайну Wifi5, так как OFDM фреймы при включении 256QAM не меняются, меняется только максимальная модуляция. В описании CLI и web была допущена ошибка.

3) MU-MIMO в 2.4GHz по дизайну возможна только в Wifi6.

4) В Wifi5, на 2.4GHz с KN-1810 доступен только HT Explicit/Implicit Beamforming и QAM256. С KN-1010, 1910 доступен только QAM256.

[Привязка к диапазону. Снижается скорость линка.]

r13

На rxrate смотреть не стоит, там выводится последний rate, который был получен из RX пакетов клиента. Он не на всех чипах сейчас выводится корректно, туда могут попадать legacy пакеты, например с линками 1 или 6.

txrate - да, это текущий ucast TX rate при передаче от AP к клиенту data фреймов и им управляет rate_ctl.

 

[Привязка к диапазону. Снижается скорость линка.]

Sonpul Sonpulov

Пока могу связать проблему сваливания линка только с обновлением драйвера MT7615 5.0.5.0, который используется в ветке в 3.05, у него микрокод MCU новее, чем был в ветке 3.04. Микрокод закрытый, поэтому достоверно сказать не могу, были ли там изменения, которые могли затронуть rate_ctl.

[Привязка к диапазону. Снижается скорость линка.]

drugold

KN-1910 на базе чипа MT7615D, у него rate_ctl полностью управляется внутренним микрокодом MCU. А это означает, что на одной и той же версии микрокода MCU логика всегда одинаковая и не зависит от прошивки совсем. Версия микрокода на некоторых чипах выводится в системный лог при загрузке системы, я проверю и добавлю вывод для MT7615 и MT7613, если сейчас это не выводится.

На текущий момент в ветке 3.03, 3.04 используется драйвер 5.0.4.0, в ветке 3.05 используется 5.0.5.0 (версия микрокода новее).

Fallback to CCK в 2.4 у нас также давно запрещен, если в настройках задан режим, не включащий 11b (например 11g/n).

Идея переподключения клиента, когда он свалился на дно rate_ctl таблицы не выглядит хорошо, потому что это нормальное поведение при long-range клиенте. Любое переподключение - это deauth клиента со всеми вытекающими. Apple iOS клиенты, например, если их напнуть 3 раза подряд с интервалом менее 180 секунд, вносят эту AP в бан лист и больше не будут к ней автоматически подключаться, пока не тапните вручную.

 

 

 

[Привязка к диапазону. Снижается скорость линка.]

Sonpul Sonpulov

Привязка к диапазону работает по принципу блокирования смежного диапазона. Т.е. если вы включили MAC привязку к 5GHz, то данному MAC драйвер в 2.4GHz не отвечает ни на probe response, ни на assoc response, ни на auth request. Никакой явной причинно-следственной связи с падением линка на противоположном диапазоне от этого быть не может.

В таблице подключенных клиентов отображается его текущий TX rate от AP к клиенту. Им управляет встроенная логика rate_ctl и текущий TX rate зависит от множества факторов, основной - это RSSI, BER, количество ре-трансмитов. Когда клиент подключается, AP обычно выставляет для него максимальный поддерживаемый TX rate за минусом Short GI. Дальнейший TX rate будет всегда дышать и зависеть от передаваемых данных и работает это автоматически, в новых чипах весь алгоритм rate_ctl спрятан во внутреннем микрокоде MCU.

Значения линка в OFDM 6 (это и есть 11a) при среднем уровне RSSI говорят от том, что от клиента наблюдается пропуски ACK-ов (большое количество ре-трансмитов к нему во время передачи данных), поэтому rate_ctl снижает линк до него до нижнего порогового значения.