Padavan

Поддержки каналов 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 выводили специально для внутренней отладки.

Ethernet драйвер потребляет меньше ресурсов CPU на входящем локальном трафике, чем Wireless драйвер. Wireless драйвер занимаеется преобразованием 802.11 заголовков в 802.3, де-аггрегацией MPDU. Локальный трафик также обычно имеет огромные TCP пакеты, которые также склеиваются программно уже в сетевом стеке. На транзитном трафике (Wifi <-> WAN) все будет хорошо (там пакеты обычно не больше MTU), но для локального трафика, Wireless всегда будет проигрывать Ethernet по ресурсам CPU. Обратите внимание на загрузку CPU при копировании на накопитель. Она будет под 100%.

У каждого вендора свой механизм дистрибуции PMK R1, это не оговорено стандартом. Поэтому точки доступа разных вендоров не смогут работать в одном мобильном домене 11r.

Maxwell Max Попробуем воспроизвести. В вашем логе смущает одно - в 18:03:38 клиент прошел AUTH, а в 18:03:43 уже был отстрелен по превышению 1024 ретрансмитов. И чуть ранее - похожая ситуация. Ретрансмиты инкрементируются, когда AP передает пакет, но клиент не присылает ACK, происходит повторная передача пакета и т.д. Когда клиенту отправлено подряд 1024 ретрансмита, считается что он протух, после чего отправляется DEAUTH и клиент удаляется. В логе клиента все верно - deauth после set key done.

Здесь можно наглядно посмотреть различия Over-the-Air/Over-the-DS https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/80211r-ft/b-80211r-dg.html https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/5700/software/release/ios_xe_33/11rkw_DeploymentGuide/b_802point11rkw_deployment_guide_cisco_ios_xe_release33/b_802point11rkw_deployment_guide_cisco_ios_xe_release33_chapter_01.pdf Современные iOS умеют оба метода, старые только Over-the-DS. Каналы могут быть разными. SSID должен быть одинаковым в рамках Mobility Domain. Также IP подсеть в рамках домена должна быть одна. Поддержка RRM/FT пока в процессе, некоторые вещи еще не доделаны.

Serzh333 Проверьте через Wifi Analyzer, что в эфире нет других точек доступа с MAC адресом (либо SSID) как у вашей AP. Если ваша AP такая одна в эфире, понаблюдайте (желательно с двух разных устройств) через Wifi Analyzer за маяками в эфире. Если маяки будут пропадать через минуту после включения, то с большой вероятностью ваше устройство неисправно.

Поддержка WPA2 Enterprise возможна только на уровне точки доступа (AP). Для клиента (AP-Client) поддержки нет от вендора и не планируется. Мы обсудим с руководством поддержку WPA2 Enterprise для точек доступа в 2.13 прошивке, в 2.12 ее точно не будет.