Padavan
-
Posts
454 -
Joined
-
Last visited
-
Days Won
26
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by Padavan
-
-
Это как раз исправление критического бага с подключением клиентов на KN-1010/1810/1910. Было принято решение опубликовать для этих устройств промежуточный релиз, чтобы снизить нагрузку на поддержку.
-
2
-
-
В 7628 драйвере ничего не менялось c 2.14 по 2.15, кроме добавления WNM BTM, который полностью деактивируется, если не включена галка "Управление BSS окружением". Включение WNM BTM добавляет всего 1 бит в caps.
Я подобных логов с периодическим assoc/reassoc насмотрелся, это исключительно инициатива клиента, если AP его не отключает. Сейчас в логах подробная информация, когда прилетает DISASSOC/DEAUTH - кто его послал (AP или STA) и код причины.
-
1
-
-
Время подключения клиента обнуляется после каждого assoc/re-assoc
-
Почему вы считаете что он отваливается? В логе нет никаких DEASSOC/DEAUTH, ни со стороны STA, ни со стороны AP. А это значит что его не нагоняли и он сам не прощался.
По логу характерный handover на клиенте, когда он пытается просмотреть в эфир в поисках лучшего кандидата, затем возвращается. Более детально увидеть можно, сняв дамп 802.11 эфира.
-
Поддержка довольно загружена, сообщения зарегистрировали, но не всем успели ответить. Завтра, надеюсь, все устаканится.
-
1
-
-
Usatyj
Нет там ничего общего, драйвер mt76x2 не обновлялся, вся логика формирования RSN IE там еще с 2.13 прошивки, где добавили поддержку FT. Более того, на Ultra2 один драйвер обслуживает оба диапазона, так что код драйвера для обоих диапазонов одинаков. Создайте отдельную тему и опишите подробно проблему, приложив логи, когда клиенты уходят на 2.4.
All
Проблемы с подключением на 2.15 касаются только чипа mt7615 (KN-1010/1810/1910), пожалуйста не пишите сюда о других устройствах.
-
1
-
-
@leksey
160МГц доступны только у KN-1810
All
Проблемы с RSN IE локализованы (есть уверенность что это финальное исправление по данной проблеме), это оказался баг вендора, занесли еще в драйвер 5.0.2.0.
Всем у кого наблюдаются проблемы с подключением клиентов на 2.15 (на KN-1010/1810/1910), рекомендую обратиться в техподдержку для получения прошивки 2.15 с исправленным драйвером. Сегодня наверное только во второй половине дня.
Если проблема решилась, оставьте фидбэк, нам это важно, так как все разнообразие клиентов мы протестировать не можем. Это исправление войдет в ближайший корректирующий релиз 2.15
-
4
-
-
Она будет не совсем тестовая, это будет 2.15.C.1 + исправление в драйвере, которые войдут в ближайший корректирующий релиз 2.15
-
Причина уже ясна, все проблемы с такими клиентами начинаются, если перед ними хоть 1 раз подключился FT клиент. Скорее всего завтра можно будет получить промежуточный срез в тех. поддержке.
-
1
-
1
-
-
a.posadsky
С большой вероятностью проблема локализована, обратитесь завтра в оф. поддержку, они вам вышлют промежуточную сборку прошивки 2.15, а вы в свою очередь отпишитесь о результате. Спасибо.
-
1
-
-
a.posadsky
Да, дамп эфира во время подключения и последующей ошибки - было бы отлично. Селф-тест не принесет полезной информации.
-
a.posadsky
Проблема с подключением iOS , при разрешенном FT, когда клиент просто рвет подключение с кодом причины:
had deauthenticated by STA (reason: 4-way handshake IE different).
должна уйти в 2.15.C.1.0-0 (относительно 2.15.B.X.X и 2.15.C.0.0-0).
Соответственно вопрос - на какой конкретно модели роутера это проявляется и проявлялась ли на 2.15.B.X.X и 2.15.C.0.0-0?
-
FT over the DS - предназначена только старых iOS клиентов. Работает хуже по той причине, что первая половина обмена должна пройти со старой AP, а вторая половина с новой AP. Так как миграция началась, то очевидно что вы отошли значительно от старой AP и есть вероятность что пакеты будут потеряны.
Когда галка отключена, работает только FT over the Air, весь обмен происходит уже с новой AP. Если у вас клиенты iPhone5 и выше с обновленной iOS, то не используйте FT over the DS.
-
Andrew Voronkov
Вы хотя бы лог показали, что происходит во время подобных "соскоков".
В релизе 2.15.C.0.0-0 не было никаких изменений в Wireless драйверах (ни в одной линейке) с момента тега 2.15.B.0.0-2. Тег в сборке не менялся. Так что либо совпадение, либо эффект плацебо.
-
Sergey Zozulya
Я некоторое время отсутствовал (был в отпуске).
Проблему с невозможностью подключения клиента с ошибкой
had deauthenticated by STA (reason: 4-way handshake IE different).воспроизвели еще 2 недели назад. Воспроизводится на новом драйвере mt7615 и только на части iOS устройств, причем характерно на старом железе. Например с iPad Air2 (2SS 11ac 80MHz) и iPhone X проблема не воспроизводится ни при каких условиях. На iPad4, iPad2 mini, iPhone 4, 5S воспроизводится только при включении 11r. При этом пару раз они все же подключаются и дальше подключиться невозможно. Снимали дамп эфира - рвет сам клиент сразу после Msg3 от AP во время 4-way хендшейка, скорее всего не проходит проверку MIC. Из-за того что хендшейк рвет клиент, а MIC высчитываются с обоих сторон, это сильно осложняет отладку. Пока отправили багрепорт вендору в поддержку. Я также продолжил чтение кода, возможно удастся найти баг.
-
1
-
-
Andrew Voronkov
На релизе 2.15, "соскоков" iOS быть не должно, если вместе с Band Steering включен 11v. Включается одновременно с 11k (команда rrm в CLI), либо в Web галка "Управление BSS-окружением 802.11k/v".
Если 11v активен и клиент ответил что тоже поддерживает 11v, в списке устройств он будет отображаться c поддержкой 11v. В этом случае Band Steering работает с таким клиентом по отдельному алгоритму, никогда его не принуждая уйти и не перекрывая ему бэнды.
Это также касается Android 8 и выше, эти клиенты в большистве случаев поддерживают 11v.
-
pigovina
При попытке клиента пройти FT AUTH, если на текущем хосте не оказывается PMK-R1 ключа, выполняется запрос ключа броадкастом по мобильному домену, но так как это асинхронная операция и нужно время для получения ответа, клиенту немедленно возвращается код 53 (FT_STATUS_CODE_INVALID_PMKID). Обычно в данной ситуации ключ быстро прилетает от последнего кейхолдера, ключ сохраняется на хосте и все последующие попытки FT AUTH должны проходить без ошибки. Если 8 раз подряд после запросов броадкастом ключ так никто и не прислал, то будет выводиться знакомая ошибка 28.
Запрос броадкастом добавлен недавно, это лишь вспомогательный функционал, если по какой-то причине ключ был удален с хоста (например перезапуск драйвера из-за смены настроек). В нормальной ситуации ключ должен рассылаться по всем хостам домена прозрачно, при первом же подключении и не удаляться ни при каких условиях, кроме как перезапуск драйвера (или перезагрузка AP).
Вам лучше обратиться в поддержку, прислать конфиги со всех AP, входящих в мобильный домен и селфтесты.
-
Я юзаю intel 8265 и 9260, они точно умеют monitor mode, правда переключаются только скриптом, одновременно клиент и монитор не работают. Пример простых скриптов:
$ cat intel_monitor_on.sh #!/bin/sh iw phy phy0 interface add mon0 type monitor iw dev wlan0 del ip link set mon0 up iw dev mon0 set channel 36$ cat intel_monitor_off.sh #!/bin/sh ip link set mon0 down iw dev mon0 del iw phy phy0 interface add wlan0 type managed ip link set wlan0 up-
3
-
-
Нет, дамп эфира делается на отдельном хосте, он должен захватывать заголовки 802.11. Обычно делается под Linux + Wireshark. Под Windows, драйверы большинства адаптеров не умеют захват 802.11
Без дампа разобраться невозможно, так как отказ приходит со стороны клиента. Мы посмотрим что там с iPad2 mini.
-
Прямо сейчас перебрал с десяток клиентов (не поддерживающих FT), включая лохматый Android 2, все подключаются без ошибок (на AP включено k + r + v).
Вчера еще небольшой баг поправил в PMF юните 7615, xiaomi mi6 переключался с ошибкой RSN IE sanity check failure (при заведомо отключенном PMF).-
3
-
-
Сморю лог, сначала включен 11k + 11r
[I] Jan 30 14:03:55 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(fc:fc:48:64:c4:fd) had associated successfully (FT mode). [I] Jan 30 14:03:55 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(fc:fc:48:64:c4:fd) had deauthenticated by STA (reason: 4-way handshake IE different). [I] Jan 30 14:03:55 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(fc:fc:48:64:c4:fd) had deauthenticated by STA (reason: class 3 error - nonassoc STA).Клиент сам же рвет соединение. При этом явно видно, что он пытается сделать обычное подключение с 4-way хендшейком, но что-то не нравится ему.
Дальше вы действительно отключаете 11k (RRM), клиент что-то меняет со своей стороны. Тут без дампа хендшейка не разобраться. У нас в офисе есть iPad mini 2, попробуем потестить. Я тестирую сейчас с iPad2 Air (iOS 12), там все хорошо. -
Поправочка, обновился драйвер mt7615 до 5.0.3.x. Там очень много изменений, по сути новая линейка. По 7628 пока изменений не было.
ЦитатаЭкспериментальным путем выяснилось, что iPad без проблем подключается при отключении 802.11k
11k (он же RRM) не принимает ни малейшего участия в Auth. Может имели ввиду 11r (FT)?
-
Да, но только те, что смогли воспроизвести. Также добавлен автоматический броадкаст запрос по всем членам домена на требование получить PMK-R1, если его не оказалось в локальной базе. Эта фишка была портирована из нового драйвера mt7615 во все линейки.
Есть вероятность, что изменения помогут в вашем случае.
-
1
-
-
В ближайшем драфте 2.15 выйдет
1) поддержка 802.11v BTM в Band Steering
2) исправления по 802.11r по проблемам обмена PMK-R1По первому пункту, Band Steering для всех клиентов, поддерживающих BSS Transmission Management будет вежливо просить перейти на противоположный бэнд, без принудительного отстрела. При этом анализируется ответ (BTM response). Это значит, что появится нормальная работа как с FT клиентами, так и свежими Android, большинство из которых из коробки умеют 11k и 11v, но не умеют 11r. После того как клиент получит запрос, он сам решает, согласиться или нет.
Пример работы с Apple iOS 12 (11/k/r/v):
WNM BTM steering 2.4 to 5GHz (клиент соглашается):
[I] Jan 30 00:24:35 bndstrg: band steering: (1) send BTM request to ec:ad:b8:80:c8:21 for roam to 5GHz band [I] Jan 30 00:24:35 bndstrg: band steering: WNM client ec:ad:b8:80:c8:21 accepted 5GHz band [I] Jan 30 00:24:36 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(ec:ad:b8:80:c8:21) FT authenticated successfully. [I] Jan 30 00:24:36 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(ec:ad:b8:80:c8:21) had re-associated successfully (FT mode).WNM BTM steering 5GHz to 2.4GHz (клиент не желает переходить по внутренним соображениям):
[I] Jan 29 23:30:28 bndstrg: band steering: (1) send BTM request to ec:ad:b8:80:c8:21 for roam to 2.4GHz band (Low RSSI: -71) [W] Jan 29 23:30:29 bndstrg: band steering: WNM client ec:ad:b8:80:c8:21 rejected 2.4GHz band (code: 1) [I] Jan 29 23:30:33 bndstrg: band steering: (2) send BTM request to ec:ad:b8:80:c8:21 for roam to 2.4GHz band (Low RSSI: -71) [W] Jan 29 23:30:34 bndstrg: band steering: WNM client ec:ad:b8:80:c8:21 rejected 2.4GHz band (code: 1) [I] Jan 29 23:30:38 bndstrg: band steering: (3) send BTM request to ec:ad:b8:80:c8:21 for roam to 2.4GHz band (Low RSSI: -71) [W] Jan 29 23:30:38 bndstrg: band steering: WNM client ec:ad:b8:80:c8:21 rejected 2.4GHz band (code: 1)Если клиент не услышал BTM реквест или не согласился, выполняется 3 попытки и далее клиенту отдается право выбора.
-
3
-
-
Потому что один чип радио не может одновременно работать в одном диапазоне, но на двух разных каналах.Это физически невозможно.
2.15.C.1 реализация Band Steering
in 2.15
Posted
Если подключаемый клиент в assoc request принес бит поддержки WNM BTM, то Band Steering отделяет таких клиентов в отдельное правило.
Для того чтобы включить поддержу WNM BTM со стороны AP, нужно включить галку "Управление BSS-окружением 802.11k/v", либо CLI команда rrm. Одна команда включает сразу RRM и BTM, поскольку BTM не может работать без RRM. При включенном BTM, AP взводит 1 бит в beacons и probe response/assoc response. Большинство клиентов, видя у AP поддержку BTM, высвечивают со своей стороны бит в assoc request. Есть исключение, некоторые клиенты могут показывать этот бит, даже если на AP не включена BTM. Если клиент приносит бит BTM, он отображается в списке с тегом 11v.
Если клиент приходит с битом WNM BTM, то Band Steering действует так:
- оба бэнда остаются открытыми для него, никаких ограничений. Куда клиент хочет подключиться, туда он и подключается (хоть быстро переходит по FT, хоть 4-way), без каких либо ограничений
- если клиент на 5G бэнде и у него падает уровень RSSI ниже порогового значения, ему отправляется BTM реквест с просьбой перейти на соседний 2.4 бэнд (в BTM реквест помещается Neigh Report c target BSS 2.4). Если клиент решает что это ему подходит, он отвечает кодом 0 и вскоре сам быстро перемещается (особенно быстро по FT). Иногда он решает что это ему не подходит и отвечает любым ненулевым кодом. Причина может быть любая, у Apple своя логика, у Android своя. Android обычно отвечает отказом, только если у него в скан-листе нет этого BSS. Поэтому важно, чтобы оба бэнда были открытыми, чтобы клиент мог рассылать probe и получать ответ. Если клиент ответил отказом, повторять BTM реквесты нет смысла, практика показала что это ничего не дает. Есть другая ситуация - клиент не услышал BTM реквеста, поэтому если ответа не пришло за 4000мс, то выполняется повтор BTM реквеста до 3 раз.
- если клиент сидит на 2.4G бэнде и в течении 10 секунд уровень от него выше нормы (+ небольшой запас), и если с последнего переключения прошло более 50 секунд, то ему генерится BTM реквест с просьбой перейти на соседний 5G бэнд. Без насилия.
- независимо что ответил клиент в BTM response, клиент c поддержкой 11v (либо 11r) никогда не будет отстрелен принудительно.
11v - отличный инструмент, поэтому Band Steering его использует элегантно, без принуждения. Если на клиенте логика 11v не совсем мертвая, он никогда не уйдет с нашей AP (в пользу мобильного 3G/4G), независимо сколько раз его будут вежливо просить о переходе.
---
Если клиент приходит без поддержки WNM BTM, то Band Steering использует второе правило и оно немного отличается от того (единственного правила) что было ранее:
- вновь прибывшему клиенту (время протухания клиента в BS списке = 90 секунд отсутствия), сейчас открыты оба бэнда, поэтому клиент подключается на свое усмотрение
- если клиент сейчас сидит на 5G бэнде и у него падает уровень RSSI ниже порогового значения, то ему применяется событие OP_STEERED, после которого 5G бэнд блокируется (не выдается ответ на probe request/auth request), тем самым ему мотивируется уход с данного бэнда (других штатных механизмов влияния нет), а если в BS preference выбрано значение не Default, то клиент принудительно отстреливается. Дальнейшее его поведение неконтролируемо. Он может совсем уйти (например на 3G/4G или вообще на другую AP). На это повлиять со стороны AP невозможно.
- если клиент сейчас сидит на 2.4G бэнде и в течении 10 секунд уровень от него выше нормы (+ небольшой запас), и если с последнего переключения прошло более 50 секунд (180 для iOS), то ему применяется событие OP_STEERED, далее все как в пункте 5G
iOS обычно заявляет поддержку FT (11r), поэтому отстрел не выполняется. Но правило переключается все равное не ранее 180 секунд, так как iOS имеет механизм бана, если ее нагнали чаще этого интервала, она заносит BSSID в бан-лист и больше к нему не подключится автоматически (только по тапу вручную).
Ранее, все клиенты получали семафор по логике открытия бэнда. Т.е. если клиент в probe/auth/assoc request приносил хороший уровень, то ему сразу перекрывался бэнд 2.4G и открывался 5G. К сожалению эта логика очень плохо работает с тупыми клиентами, не имеющих handover логики. Они начинают долбиться в 2.4 и не хотят подключатсья к 5. В итоге такие клиенты либо совсем не подключаются, либо с очень большой задержкой. Что сильно снижает юзабилити.