Padavan

Наводящий вопрос - если переключить в настройках точки доступа 5ГГц полосу в 40MHz, проблема c провалом линка уходит на данных устройствах?

Клиент сам выбирает лучший вариант, причем если поддерживает FT, то будет переключаться бесшовно. Нельзя прибить клиента к конкретной AP, потому что именно сам клиент выбирает кандидата в качестве AP. Единственный механизм со стороны AP - это WNM, но он лишь просит перейти, клиент все равно сам решает.

На смартфонах полоса 160 все же избыточна, это в основном удел для десктопов и ноутов, чтобы получать до 900mbps в пике (например копирование с NAS). Под рукой Galaxy S10 на exynos, он не поддерживает 160, однако на 80 прекрасно выдает до 650mbps даже со Speedster KN-3010.

В диапазоне 5ГГц всего два сплошных блока по 160МГц 36..64 100..128 причем, они могут быть недоступны для определенных регионов. Выбирая конкретный 20МГц канал внутри блока 160, вы по сути задаете только центральный канал VHT. Реальные данные передаются по всему блоку спектра. Странно что смартфон ведет себя подобным образом, по идее вообще нет разницы, какой центральный канал VHT выбирать внутри блока 160. Возможно какие-то ошибки в драйвере.

При использовании полосы 80 и 160 теряется какой-либо смысл в автовыборе канала. Поставьте ручной канал 36 и проверьте

Dkray При установке полосы 160МГц выбираете канал под сплошной кусок спектра? Если сплошной кусок недоступен, web выставляет 80+80, это видно в running-config. Под рукой два разных Intel 9260AC крайне плохо работают в 80+80. При этом хорошо работают в сплошном 160. Cкоро должны подойти Intel AX200, надо будет их глянуть. Наводящий вопрос - у вас ранее работал данный клиент на 160МГц с нормальными скоростями? Текущий микрокод, который управляет подстройкой rate_ctl чипа радио неизменный с 2.15. Если ранее были другие результаты, сообщите.

Поддержки каналов 32 и 34 пока нет, в старые устройства (чипы MT7610/MT7612) поддержку добавить не составит проблем, но поддержка в чипе MT7615 может быть пока затруднена, так как зависит от поддержки в микрокоде. Будем выяснять у вендора.

dsstroy Если мультикаст IPTV не работает ни по кабелю, ни по Wifi, нужно снимать захват пакетов с IGMP upstream и downstream интерфейсов. При попытке подписаться на канал с LAN. Настройки Wifi не нужно крутить, там M2U всегда включен и работает. А больше от Wifi ничего не требуется. Также смотрите в IPTV плеере интерфейс для подписки, если в Windows несколько интерфейсов, подписка наверх может просто не уходить. Можно сразу обратиться в техподдержку, но без захваченных пакетов разобраться в вашей конкретной ситуации будет крайне затруднительно.

Исправление также зашло в ветку 2.15, соответственно следующий корректирующий релиз 2.15 тоже его получит. Но дата релиза мне пока не известна.

pigovina Вчера удалось локализовать проблему FT ре-ассоциации с iPhoneX. Изменение будет включено в сборку 3.00.A.2.0-2.

Исправление для NULL data фреймов войдет в следующий билд 3.00 (в конце недели). Для 2.15 тоже войдет, но решение о перевыпуске корректирующего релиза принимается отдельно, пока у меня информации о дате нет.

Нет, в 2.15 не вошло. Хуже стать не могло. Не тратьте время, там ничего для FT не поменялось. Вошел только багфикс с закрытием интерфейса (падение в драйвере) и исправление для совместимости с PMF, которое вошло и в 3.0. Если PMF не включен, ничего не изменилось.

pigovina Спасибо за логи дампа эфира, получили из техподдержки. Предварительный анализ дампа показал, что iPhoneX шлет постоянно NULL data фреймы, если такой фрейм попадает в промежуток, когда AP еще не выставила флаг что клиент ассоциирован, то AP прозрачно отсылает клиенту Deauth c причиной Class2 Error. При этом Deauth Class2/3 от AP не видны в логе (на них отсутствует логирование в драйвере AP). В целом, это корректное поведение по WFA, однако есть смысл не реагировать на NULL data фреймы в контексте совместимости с подобным поведением клиента. В ближайшее время подготовим исправление для всех линеек Wireless чипов.

pigovina У меня под рукой есть iPad Air2, с ним вопросов нет. iPhone X есть в офисе, надо потестить внимательнее. Основной проблемой из ваших логов является то, что iPhone X сразу после успешной пары FT auth/reassoc Mar 23 21:25:28 wmond: WifiMaster0/AccessPoint0: (MT7628) STA(18:81:0e:6a:xx:xx) FT authenticated successfully. Mar 23 21:25:28 ndm: kernel: fastvpn: cleared binds for 18:81:0e:6a:xx:xx Mar 23 21:25:28 wmond: WifiMaster0/AccessPoint0: (MT7628) STA(18:81:0e:6a:xx:xx) had re-associated successfully (FT mode). спустя 2 секунды решает сделать подключение с нуля: Mar 23 21:25:30 wmond: WifiMaster0/AccessPoint0: (MT7628) STA(18:81:0e:6a:xx:xx) had associated successfully (FT mode). Mar 23 21:25:30 wmond: WifiMaster0/AccessPoint0: (MT7628) STA(18:81:0e:6a:xx:xx) set key done in WPA2/WPA2PSK. с полнным 4-way pairwise хендшейком. По факту это подключение с нуля. Что его вынуждает это делать, без дампа 802.11 заголовков не возможно понять. Селфтест в этом ключе не поможет.

vasek00 Тут все просто, если не-FT клиент перезапрашивает адрес по DHCP после reassoc, значит он с большой вероятностью почистил у себя L3 соединения, а значит любой сервис пострадает. FT клиенты после FT auth -> FT reassoc характерно не перезапрашивают IP по DHCP, поэтому получается практически бесшовный переход.

pigovina Не совсем понял, "Управление BSS-окружением 802.11k/v" у вас включено или нет? Apple требуют 11k, без RRM, клиент не может получить списки окружения с каждой AP.

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. Тег в сборке не менялся. Так что либо совпадение, либо эффект плацебо.

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, входящих в мобильный домен и селфтесты.

Да, но только те, что смогли воспроизвести. Также добавлен автоматический броадкаст запрос по всем членам домена на требование получить PMK-R1, если его не оказалось в локальной базе. Эта фишка была портирована из нового драйвера mt7615 во все линейки. Есть вероятность, что изменения помогут в вашем случае.

В ближайшем драфте 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 попытки и далее клиенту отдается право выбора.

T@rkus Спасибо за логи, попробуем разобраться.

Речь о другом, наличие такой ошибки допустимо, факторы я перечислил. Если у вас после 2.14.C.0.0-3 все равно весь лог засыпан этой ошибкой, то что-то идет не так, нужно разбираться в конкретном случае.

Ошибка означает, что хост-кейхолдер не может найти в базе 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 выводили специально для внутренней отладки.