Padavan
-
Постов
495 -
Зарегистрирован
-
Посещение
-
Победитель дней
27
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Сообщения, опубликованные Padavan
-
-
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
-
-
Потому что один чип радио не может одновременно работать в одном диапазоне, но на двух разных каналах.Это физически невозможно.
-
t800
Ответил в теме.
-
Это не баг.
По дизайну, при 3-адресном заголовке 802.11, не могут в одном эфире (т.е. на одном канале) работать два клиента с одинаковым MAC. Когда вы включаете функцию MAC-репитера, то она проксирует на каждого своего клиента отдельное вышестоящее соединение к корневой точке доступа. Если клиент беспроводной и садится из под того же бэнда, на котором работает MAC-repeater, то сейчас прокси-MAC смешивается из OUI AP-Client и 3 октета от реального клиента. Иначе в одном эфире окажутся два клиента с одинаковым MAC, и все 4 пира будут слышат друг друга, в итоге сильно просаживается скорость из-за хаоса с ACK (очень сильная пила). Потому как неизвестно от кого прилетает ACK, так как MAC-и одинаковые.
Поэтому, если MAC-репитер вывешивает прокси соединение к вышестоящей корневой AP на клиента:
- проводного
- беспроводного, но с противоположного бэнда (например MAC-repeater настроен на 2.4, а клиент пришел с 5ГГц или наоборот)
то в этом случае проксируется оригинальный MAC клиента. Иначе, формируется составной MAC для прокси соединения, чтобы избежать двух одинаковых MAC в одном эфире.Все другие прозрачные мосты основаны на базе WDS и используют 4-x адресный заголовок 802.11. По своей сути MAC-repeater - это костыль, чтобы заткнуть брешь MAC Address Translation (MAT), без которой нельзя работать при 3-адресном заголовке 802.11.
У нас точно появится решение на базе WDS (4-адресного заголовка), после чего решим что делать с MAC-repeater-ом.
-
5
-
1
-
-
Да, спасибо за фидбэк, сломано в 2.15 и только на свитче MT7628. К следующей сборке исправим.
-
2
-
-
При включении в настройках 11r (FT), в список IE у маяков и пакетов probe/assoc response добавляется еще один тип Auth, который не знает ваш клиент и отказывается подключаться, несмотря на то что в списке есть WPA2-PSK. Точно такая же проблема с Intel 4965 и его старыми драйверами. Проблема чисто софтовая (в драйвере) на стороне клиента. Как можно вылечить баг на клиенте со стороны AP? Лечить нужно клиента.
Есть некоторые мысли, как подпереть костылем таких древних клиентов (так как у большинства не будет обновлений драйверов), надо пробовать, но это может сломать распознавание поддержки FT у нормальных клиентов.
-
4
-
-
T@rkus
Спасибо за логи, попробуем разобраться.
-
1
-
-
Речь о другом, наличие такой ошибки допустимо, факторы я перечислил. Если у вас после 2.14.C.0.0-3 все равно весь лог засыпан этой ошибкой, то что-то идет не так, нужно разбираться в конкретном случае.
-
3 часа назад, T@rkus сказал:
После обновления роутеров на прошивку 2.14.C.0.0-3 ошибка FT authentication rejected (status code: 28) по прежнему присутствует.
Ошибка означает, что хост-кейхолдер не может найти в базе PMK-R0 или R1 запись при попытке клиента пройти на нем FT auth. Такое сейчас возможно, после того как
- вы смените любые настройки Wireless и база PMK будет очищена при перезапуске драйвера
- роутер/AP будут перезагружены
- изменится IP на AP, при этом управляющий демон будет перезапущенНа текущий момент, в 2.14.C.0.0-3 это все факторы, приводящие к очистке базы данных PMK-R1 кейхолдера. До 2.14.C.0.0-3 существовали еще критерии, когда база кейхолдера обнулялась.
После того как клиент не смог перейти по FT auth, он обычно коннектится стандартным способом, используя 4-way хендшейк и база кейхолдера обновляется автоматически. У нас есть идеи, как побороть первые 2 пункта, не прибегая к сохранению PMK-R1 (так как он секретный).
-
На данной ошибке не стоит заострять внимание, так как результат FT auth выводили специально для внутренней отладки. -
Ethernet драйвер потребляет меньше ресурсов CPU на входящем локальном трафике, чем Wireless драйвер.
Wireless драйвер занимаеется преобразованием 802.11 заголовков в 802.3, де-аггрегацией MPDU. Локальный трафик также обычно имеет огромные TCP пакеты, которые также склеиваются программно уже в сетевом стеке.
На транзитном трафике (Wifi <-> WAN) все будет хорошо (там пакеты обычно не больше MTU), но для локального трафика, Wireless всегда будет проигрывать Ethernet по ресурсам CPU. Обратите внимание на загрузку CPU при копировании на накопитель. Она будет под 100%.
-
4
-
-
Это фича, а не баг.
Если клиент подключается в VHT режиме (с QAM256), то CLI так и пишет о 11ac, потому что это единственный статус, позволяющий понять что клиент в VHT режиме. Для того чтобы понимать как формируется mcs и rate, они формируются именно по 11ac таблице. WebUI автоматически конвертит строку в 11n, чтобы не смущать людей.
Вывод информации в CLI разбирает техподдержка в ваших селфтестах, им важно понимать текущий режим.
-
1
-
-
Цитата
Накатил на Giga II 2.11.D.0.0-1 (legacy) для сравнения. Что удивительно даже с включенным прямым mac на репитере качество голосовой связи в мессенджерах хорошее.
В сборке 2.11.D.0.0-1 драйвер rt539x для Giga2 отстает от 2.14.B.0.0-1 только на 1 изменение - с 2.14.A.5.0-0 увеличено максимальное число клиентов с 32 до 64 (увеличен массив статической таблицы клиентов). Это никак не должно сказываться на качестве работы.
По поводу проблемы подключения, посмотрим что еще можно сделать, проблема обычно связана с тем что иногда клиент не прощается со старой AP.
-
1
-
-
Leksey118
MCU микрокод для чипа MT7615 не менялся с 2.12 прошивки. Начиная с 2.13, в драйвере добавился функционал MAC-repeater и FT + RRM (11r + 11k). При отключенном в настройках 11r, драйвер должен себя вести так же как и 2.12. MAC repeater включается только в режимах Адаптер и Усилитель, причем из CLI (пока).
На первых сборках 2.13 не работало управление TxPower из Web интерфейса, в релизе 2.13 и свежей 2.14 это исправлено. Также в релизе 2.13 при выборе 11gn (любого без 11b) не вещается поддержка 11b в маяках и probe/assoc response. У вас в настройках стоит compatibility BGN, значит для вас ничего не изменилось.
У вас с этим клиентом (00:0c:43:95:55:e4) одна проблема
Sep 26 05:55:38 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(00:0c:43:95:55:e4) pairwise key handshaking timeout.
Sep 26 05:55:38 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(00:0c:43:95:55:e4) had deauthenticated (reason: PTK 4-way handshake timeout).Попробуйте в настройках точки 2.4
- выбрать режим 11g/n
- временно отключить eBF и MU-MIMO
- временно отключить TxBurst и QAM256Без дампа эфира сложно понять что происходит и кто виноват в обрыве 4way хендшейка, чтобы понять, нужно на внешнем хосте включать режим монитора на 11 канале и захватывать 802.11 заголовки во время проблемного подключения клиента.
-
1
-
-
AndreyUA
Несколько наводящих вопросов:
- замеченные проблемы с этими двумя клиентами стали проявляться с 2.13? Работали ли ранее по другому?
- на других кинетиках, кроме 1010 проблема также есть?
- включен ли RRM и FT в настройках на 2.13? -
При включении FT и RRM в маяки и probe/assoc response добавляются дополнительные элементы, на которые может реагировать Apple. Просьба проверить тот же самый кейз на 2.13, только временно отключить k и r.
-
У каждого вендора свой механизм дистрибуции PMK R1, это не оговорено стандартом. Поэтому точки доступа разных вендоров не смогут работать в одном мобильном домене 11r.
-
2
-
1
-
-
Maxwell Max
Попробуем воспроизвести. В вашем логе смущает одно - в 18:03:38 клиент прошел AUTH, а в 18:03:43 уже был отстрелен по превышению 1024 ретрансмитов. И чуть ранее - похожая ситуация.
Ретрансмиты инкрементируются, когда AP передает пакет, но клиент не присылает ACK, происходит повторная передача пакета и т.д. Когда клиенту отправлено подряд 1024 ретрансмита, считается что он протух, после чего отправляется DEAUTH и клиент удаляется.
В логе клиента все верно - deauth после set key done.
-
1
-
Проблемы подключения клиентов к WiFi ТД после обновления драйвера mt7615
в 2.15
Опубликовано
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 высчитываются с обоих сторон, это сильно осложняет отладку. Пока отправили багрепорт вендору в поддержку. Я также продолжил чтение кода, возможно удастся найти баг.