Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

Wi-CAT LLC
Навигация Форума
Вы должны войти, чтобы создавать сообщения и темы.

Роаминг. Меж двух огней.

Здравствуйте!

Предварительно описываю ситуацию, что была сегодня.  Сорри, что много букв. Отдельное сорри, что я генерю темы быстрее, чем вы их разгребаете). Но, замечу, что у меня ситуация не горит, ибо я выкрутился, но "разобраться хочу". Имеем следующий кейз: (см. рисунок сети).

Оба дуо в режиме ТД, прошивки от 06.08.2020. Настройки вайфай одинаковые, а именно, SSID2.4G на обоих точках совпадает и SSID5G на обоих точках совпадает, (И бэндстиринг, соответственно, выключен) каналы, пароли, шифрование - все одинаково. 802.11k/v - включены, 802.11r- выключена(ибо с ней было невозможно подключиться вообще - "AP STA xxxxxxxx roam from this AP, delete entry" на обоих диапазонах, рядом с точками, далеко - неважно, никто не мог подключиться). При такой конфигурации(когда 802.11r выключил), к сети, могли подключаться смартфоны и мой бук, с которого я рулил, но напрочь, просто категорически отказались подключаться банк терминалы ingenico. При этом, в логах одной из точек фиксировался факт (попытки) подключения:

Aug 7 14:24:41 kernel: ASSOC - Assign HT STA MODE=HTMIX, MCS=7, BW=20M, AID=1 to 2.4GHz AP мактерминала (WPA2PSK/AES)

 

Но терминалы (оба) уходили в перезагрузку, из-за чего были заподозрены в неисправности и их забрал представитель банка. Когда он вернулся, ситуация с терминалами повторилась. То есть терминал по кругу выдавал некую ошибку, расшифровку которой специалист банка не знал, но не суть)) Так вот, выяснилось, что терминалы так странно зацикливались по причине того, что не могли подключиться к вайфай. Подключиться они смогли только тогда, когда на точке1 мы выключили радио 2.4G. Оставили работать точку 2, так как она находится посредине зала. Ну, думаю , ладно - раз терминалы такие капризные, пусть раздавать 2.4Г сеть будет только одна точка, а сеть 5Г будут раздавать обе точки. И... выяснилось, что и к 5Г сети подключиться в такой конфигурации не так-то просто. А именно, я находился в зоне действия обоих точек, но сигнал точки 1 был сильнее.В логах точки 1 я наблюдал при этом следующее:

Aug 7 14:22:07 kernel: ASSOC - Assign HT STA MODE=HTMIX, MCS=15, BW=20M, AID=1 to 2.4GHz AP моймак, WNM supported (WPA2PSK/AES)
Aug 7 14:22:08 kernel: 2.4GHz AP STA моймак roam from this AP, delete entry
Aug 7 14:22:14 kernel: ASSOC - Assign VHT STA MODE=VHT, MCS=9, BW=80M, AID=1 to 5GHz AP моймак, WNM supported (WPA2PSK/AES)
Aug 7 14:22:14 kernel: 5GHz AP STA моймак roam from this AP, delete entry
Aug 7 14:22:16 kernel: ASSOC - Assign VHT STA MODE=VHT, MCS=9, BW=80M, AID=1 to 5GHz AP моймак, WNM supported (WPA2PSK/AES)
Aug 7 14:22:16 kernel: 5GHz AP STA моймак roam from this AP, delete entry
Aug 7 14:22:17 kernel: ASSOC - Assign VHT STA MODE=VHT, MCS=9, BW=80M, AID=1 to 5GHz AP моймак, WNM supported (WPA2PSK/AES)
Aug 7 14:22:17 kernel: 5GHz AP STA моймак roam from this AP, delete entry
Aug 7 14:22:19 kernel: ASSOC - Assign VHT STA MODE=VHT, MCS=9, BW=80M, AID=1 to 5GHz AP моймак, WNM supported (WPA2PSK/AES)
Aug 7 14:22:19 kernel: 5GHz AP STA моймак roam from this AP, delete entry
Aug 7 14:22:21 kernel: ASSOC - Assign VHT STA MODE=VHT, MCS=9, BW=80M, AID=1 to 5GHz AP моймак, WNM supported (WPA2PSK/AES)
Aug 7 14:22:21 kernel: 5GHz AP STA моймак roam from this AP, delete entry
Aug 7 14:22:23 kernel: ASSOC - Assign VHT STA MODE=VHT, MCS=9, BW=80M, AID=1 to 5GHz AP моймак, WNM supported (WPA2PSK/AES)
Aug 7 14:22:23 kernel: 5GHz AP STA моймак roam from this AP, delete entry
Aug 7 14:22:24 kernel: ASSOC - Assign VHT STA MODE=VHT, MCS=9, BW=80M, AID=1 to 5GHz AP моймак, WNM supported (WPA2PSK/AES)
Aug 7 14:22:24 kernel: 5GHz AP STA моймак roam from this AP, delete entry
Aug 7 14:22:26 kernel: ASSOC - Assign VHT STA MODE=VHT, MCS=9, BW=80M, AID=1 to 5GHz AP моймак, WNM supported (WPA2PSK/AES)
Aug 7 14:22:26 kernel: 5GHz AP STA моймак roam from this AP, delete entry
Aug 7 14:22:27 kernel: ASSOC - Assign VHT STA MODE=VHT, MCS=9, BW=80M, AID=1 to 5GHz AP моймак, WNM supported (WPA2PSK/AES)
Aug 7 14:22:27 kernel: 5GHz AP STA моймак roam from this AP, delete entry
Aug 7 14:22:29 kernel: ASSOC - Assign VHT STA MODE=VHT, MCS=9, BW=80M, AID=1 to 5GHz AP моймак, WNM supported (WPA2PSK/AES)
Aug 7 14:22:29 kernel: 5GHz AP STA моймак roam from this AP, delete entry
Aug 7 14:22:30 kernel: ASSOC - Assign VHT STA MODE=VHT, MCS=9, BW=80M, AID=1 to 5GHz AP моймак, WNM supported (WPA2PSK/AES)
Aug 7 14:22:30 kernel: 5GHz AP STA моймак roam from this AP, delete entry
Aug 7 14:22:31 kernel: ASSOC - Assign VHT STA MODE=VHT, MCS=9, BW=80M, AID=1 to 5GHz AP моймак, WNM supported (WPA2PSK/AES)
Aug 7 14:22:32 kernel: 5GHz AP STA моймак roam from this AP, delete entry

 

А в логах точки2 не было ничего. Тогда я подумал - наверное, это потому что я выключил на точке1 радио на 2.4 Г, а без него она не может полноценно работать? Включил опять на точке1 радио 2.4, но задал другой SSID, чтоб банковским терминалам крышу не сносило. Но не помогло, я по-прежнему не мог подключиться. Ибо точка 1 упорно меня куда-то мигрировала (в космос, видимо), при том, что я был рядом с ней, и сигнал был хороший. В общем, нормально заработало только тогда, когда я... полностью отключил на точке 1 радио, тем самым превратив её (надеюсь временно) в обычный свич. И точка под номером два более-менее покрыла всё пространство (ну кроме того уголка, где должна была покрыть точка1). В таком состоянии всё и было оставлено. Итак, формулирую вопрос-просьбу: могло ли с обновлением драйвера поломаться что-то в этой части? Просьба проверить такой кейз - из двух точек, роаминг включен, и точки соединены по кабелю.

 

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

ЗЫ: Такая дурацкая схема получилась, потому что на микротике все порты заняты, и к точке 2 оказалось проще и быстрее, без сверления дырок, кинуть кабель от точки 1, а не от микротика.

ЗЫ2: логи, конфиги дам позже. Особенно, если вы у себя повторить ситуацию не сможете - скорее всего куплю ещё пару точек, чтобы погонять спокойно у себя.

просто категорически отказались подключаться банк терминалы ingenico

Ну следует начать с того что им написать что из клиенты во первых не поддерживают R который вам нужен если хочется вменяемый роуминг. И более того видя анонсы R со стороны AP сходят с ума. Ситуация увы распространённая.

Но терминалы (оба) уходили в перезагрузку, из-за чего были заподозрены в неисправности и их забрал представитель банка. Когда он вернулся, ситуация с терминалами повторилась.

Тем более нужно репортить производителю.

Для старта временно отключиь BTM и посмотреть что будет. Точка не указывает куда мигрировать, клиент сам решает. Покрытие должно быть обеспечено с пересечением зон так что бы в любой точке клиент мог зацепиться как минимум к 1й АП.

 

Цитата: sfstudio от 07/08/2020, 15:28

Тем более нужно репортить производителю.

Представитель банка обещал передать "наверх" про такое поведение терминалов.

Для старта временно отключиь BTM и посмотреть что будет. Точка не указывает куда мигрировать, клиент сам решает. Покрытие должно быть обеспечено с пересечением зон так что бы в любой точке клиент мог зацепиться как минимум к 1й АП.

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

 

Если выключен Handoff и BTM АП никого вообще не отпинывает. Более того BTM лишь намекает, но не заставляет обязательно мигрировать. А вот handoff именно что выпинывает.

Правильный роуминг работает иначе. А именно логика на стороне клиентов используя процедуру handover по своим критериям мигрирует между AP используя или не используя возможности этой АП предоставляемые в виде K/R. С помощью BTM (задав уровни эксперементально) можно оптимизировать миграцию.

А с помощью handoff заставить переключаться и не умеющих это клиентов (но могут быть побочки т.е. надо быть очень аккуратным).

Вообще желательно иметь эталонного клиента (ноут с интеловской картой, телефон по человечески поддерживающий миграцию аля SGS A5 2017 как самый дешовый из них) и сначала проверяем на нём.

Ребут терминалов эт беда. Многие устройства тупо не задействуют процедуру handover если не видят анонсов 802.11r. А у вас клиенты ребутаются при включенном R. Так что в первую очередь конечно надо бы дождаться что вендор терминалов скажет и хотя бы дров поправит что бы в ребут не уходило.

В разделе статей есть пошаговое описание как вообще оно происходит. См меню сайта.

Цитата: sfstudio от 07/08/2020, 15:43

Если выключен Handoff и BTM АП никого вообще не отпинывает. Более того BTM лишь намекает, но не заставляет обязательно мигрировать. А вот handoff именно что выпинывает.

handoff и BTM были включены. Но в параметрах handoff я от дефолтных если и подкрутил, то только в сторону смягчения политики выпинывания, то есть где было к примеру -76 ДБ, поставил -78. Но в любом случае, этих значений не могло быть! Я сидел в трёх метрах от точки1.

 

По BTM да, я вижу в логе периодически "AP Try BTM move STA" и понимаю, что try - это попытка. В моём-же случае было "Aug 7 14:22:30 kernel: 5GHz AP STA моймак roam from this AP, delete entry" - вот это значит что клиент сам ушёл(а зачем он тогда опять на неё стучится, и почему он на другую не прицепился?)? Или его всё-таки выпнула точка? Если выпнула, то неплохо по логу видеть причину - уровень такой-то, как в других подобных строках. 

Кстати, "клиент" в данном случае это хуавей P10

 

Цитата: sfstudio от 07/08/2020, 15:43

В разделе статей есть пошаговое описание как вообще оно происходит. См меню сайта.

"Уж и так читали-читали" )) Но надо освежить. Я читал эти статьи абстрактно, а счас вот с новыми FT-DUO пробую практически. Я не спорю, клиенты конечно аховые,

но ведь во всяких мегах и аэропортах мы же как-то пользуемся вайфаем... Я пока ещё раз у себя ситуацию не повторю, с конфигами и логами, просто словесно описал случай - возможно, у кого-то будет подобное, и удастся обобщить. Кстати, в соседней ветке подобное я и видел.

handoff и BTM были включены. Но в параметрах handoff я от дефолтных если и подкрутил, то только в сторону смягчения политики выпинывания, то есть где было к примеру -76 ДБ, поставил -78. Но в любом случае, этих значений не могло быть! Я сидел в трёх метрах от точки1.

Я ж грю рубаните handoff и BTM для начала. Нормальным клиентам они не нужны. handoff так вообще вреден. Но его сообщений в виде  (kickout) я не вижу, однако пороги "не пускания" запросто могут отрабатывать. Сначала в любом случае всё делается без него. И если уж клиенты не мигрируют в т.ч. по сообщению через BTM что пора бы, то уже тогда нужно включать его и пытаться подобрать максимально мягкие значения.

По BTM да, я вижу в логе периодически "AP Try BTM move STA" и понимаю, что try - это попытка. В моём-же случае было "Aug 7 14:22:30 kernel: 5GHz AP STA моймак roam from this AP, delete entry" - вот это значит что клиент сам ушёл(а зачем он тогда опять на неё стучится, и почему он на другую не прицепился?)? Или его всё-таки выпнула точка? Если выпнула, то неплохо по логу видеть причину - уровень такой-то, как в других подобных строках. 

По BTM просто грит, чувак, не пора ли тебе свалить. Т.е. он даже не выпинывает и клиент в праве остаться. Вторая запись грит о том что клиент мигрировал (не важно как) и старая запись в mac table для него зачистилась + его заанонсили с другой точки DS что бы обновились все кэши всего промежуточного оборудования.

Почему клиент решает вернуться назад, ну вот такая у него логика оказалась. Беда...

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

Ни разу не видел что бы там был включено хоть что-то из проуминговых расширений. Т.е. обычно  делается максимально дубовая схема вообще без ничего. Разве что могут подбивать по совсем низкому уровню.

Для нормальной работы бесшовного роуминга требуется именно что и клиент человеческий и АП. Даже программа сертификации у WiFi альянс есть на эту тему.

Что бы просто жёстко сопнуть клиента и попытаться не пустить назад есть handoff. Параметры оного увы всегда зависят от места, клиентов и прочего. Т.е. сугубо экспериментально. Дефолты это параметры полученные методом длительных экспериментов в моей квартире для обеспечения принудительного переключения древних клиентов без 802.11r между комнатами.

Как-то так.

Ок, буду пробовать. Однозначно понял одно - в публичных сетях r включать категорически нельзя. С остальным - под вопросом.

Но его сообщений в виде  (kickout) я не вижу, однако пороги "не пускания" запросто могут отрабатывать.

 

вот это меня и смущает! И лог в данной части не достаточно информативен, имхо.

Именно так, в публичных сетях R по умолчанию == тараканы на очень многих девайсах. Да и V тоже. Т.е. публичные хотспоты в этом смысле чем проще - тем лучше.

Благо вроде потуги есть у альянса и возможно через пару лет всё станет сильно лучше. Пока шанс наступить на грабли сильно не нулевой, особенно если клиенты нижнего ценового сегмента, да ещё и от китайцев каких. Там можно ждать вообще чего угодно в этой части. Проверено уже и рукусами и циской и нами. =)

Также прошу добавить в интерфейс включения 802.11r красную пердупреждающую надпись, что старые клиенты, не поддерживающие r вообще не смогут подключиться к сети.

Цитата: termit от 07/08/2020, 16:45

Но его сообщений в виде  (kickout) я не вижу, однако пороги "не пускания" запросто могут отрабатывать.

 

вот это меня и смущает! И лог в данной части не достаточно информативен, имхо.

Ну дык если не было события о чём информировать? =) Лог с клиента интереснее был бы в разы. Можно поставить Aruba Utils там есть доступ к логу клиента. Куцее и не умеющее детектить R как Roaming но часто позволяет хотя бы косвенно понять чего оно мечется и пнули его или сам свалил.

Цитата: termit от 07/08/2020, 16:49

Также прошу добавить в интерфейс включения 802.11r красную пердупреждающую надпись, что старые клиенты, не поддерживающие r вообще не смогут подключиться к сети.

Вот это не правильно.

Старые клиенты не поддерживающие R прекрасно будут работать. У меня таких большинство и R включен всегда. Проблема возникает именно что когда, ну например, какой-нить китайский вендор или Федя кастомизатор поврубали например в дровах всё подряд при сборке, а что в ответной части аля суппликант поддержка этого тоже нужна как-то и позабыли (сложно когда не знал ещё и забыл).

В итоге драйвер вполне правильно начинает лезть к АП используя 802.11r и на каком-то этапе пытается дёрнуть суппликант для обработки коннекта  с использованием Fast Transition, тот в недоумении возвращает какой-нить невнятный -ERROR и всё тормозиться или даже ребутается.

Ну это как один из сценариев.

Иногда (типа Yotaphone 2) всё собрано относительно корректно, но в конфиге дров тупо вырублено то что надо и зачем-то врублено что не надо - привет роуминга нет вообще. А в некоторых случаях ещё и невозможно подключиться ибо в конфиге дрова пороги задали -60 и тот мучительно уже в 2х метрах начинает сканить эфир думаю куда метнуться и ессно метнётся и обломается. =)

Просто клиентские устройства  даже не проверяют часто на то будет ли оно работать с 802.11r AP, ибо до недавнего времени таковых кроме корпоративной среды и не было почти ни где. А реализация поддержки R в 802.11 не является обязательной частью и при сертификации по общей программе не проверяется.

Отсюда все эти чудеса. Но вендоры клиентов будут вынуждены изменить подход. Ибо большинство самых свежих роутеров и AP в том или ином виде уже умеют 802.11r.

Однако это не быстро. Самсунг как первая ласточка.

Ну дык если не было события о чём информировать?

То есть точка не пускает клиента на аппаратном уровне, и отловить это событие и отразить его в журнале нельзя? Тогда поняяяяятно...

Если на AP я выведу эвенты всех отлупов - лог будет просто бесконечно бежать по экрану, как практика показала =). Потому выводятся только отказы пускания которые появились в следствии какой-либо ошибки. А вот когда AP выпинывает с себя  - то логируется в 100% случаев.

В любом случае такие вещи проще и лучше смотреть на клиенте. Там кроме прочего может оказаться инфа о том почему всё же что-то не срослось. Да и не будет левых эвентов вообще.

 

Вот это не правильно.

Да, но я наблюдал сегодня именно такую картину - подключиться не мог никто. Вот что вычитал на хабре (ну, то-есть не совсем на заборе)- врут?:

"802.11r/FT

Fast Roaming/Fast BSS Transition – 802.11r обязательна для клиента при использовании на точке, т.е. те кто его не поддерживают, не могут подключиться – это флаг в управляющих кадрах и измененный механизм обмена ключами, если абонент старый и не знает о его существовании, у него проблема (на новых устройствах даже при отсутствии поддержки функции иногда добавляют понимание данного флага, хотя по стандарту нужно полностью реализовать протокол). Может также обрушить некорректные драйвера старых клиентских адаптеров — дело в использовании при первоначальном подключении FT 4-Way Handshake для распространения общего ключа, вот что об этом говорит стандарт: «A STA shall not use any authentication algorithm except the FT authentication algorithm when using the FT Protocol».

Я тоже не мог подключиться, и банкир и тд... пока не отключили r. После отключения r,  я и другие подключились, кроме банковских терминалов. А им помогло отключение одной точки. В общем, мне надо ещё их погонять, пособирать статистику.

В любом случае можно начать подбор параметров handoff с -99dB уровней в Reject Assoc и Ignore Probe. Т.е. сначала настроить пороги для дисконнета и покрутить задержку срабатывания что бы не было ложный отстрелов. А только потом уже играться с уровнями не пускания и игнора probe во сканировния клиентом при низком уровне.

Вот такие вот общие подходы. Дальше уже всё индивидуально. Но всегда ооочень аккуратно и всегда помним, что мы выпнули, а там клиента если заклинило и на текущю AP мы его назад не пускаем он может вообще перестать пытаться. И такое встречается, правда очень редко.

Эта логика увы ни чем не регламентирована ;(

Да, но я наблюдал сегодня именно такую картину - подключиться не мог никто. Вот что вычитал на хабре (ну, то-есть не совсем на заборе)- врут?:

Врут. Это всё согласуется на стадии соединения. Т.е. разные клиенты идут по разной процедуре. Те кто умеют FT и заявляют его поддержку - идут по FT и наоборот.

Просто вам с банкиром похоже жутко повезло с клиентами. Или что-то такого в handoff крутанули.

Прямо сейчас работает вот у меня на одной AP как минимум 3 клиента без R и 2 с R причём часть из них WPA2 часть WPA3.

Нет проблем.

В логе кстати указано какая схема используется при подключении того или иного клиента. Буковки FT в логе как бы намекнут если выбран вариант с FT.

Тот же самый подход например используется и в PMF в режиме Capable или в mixed режимах аутентификации. Клиент сначала согласует с АП чего они оба умеют, выбирают схему по которой дальше пойдёт коннект и исполняют выбранный сценарий.

 

Эт в идеале. Но увы встречаются клиенты...

Скажу еще одну глупость (ибо,по-вашему, похоже ничего иного не умею) - при включении R все мои iPhone и iPad (правда старенькие, но обновы до сих пор прилетают) не могут подключиться. И это, заметьте, не дядя Ляо прошивки собирал. Так что предупреждение точно лишним не будет, дабы не потерять вдруг возможность подключиться к точке до полного сброса настроек.

Ага. Точно. А я ещё скажу что отладка роуминга шла всю дорогу на 5,6,7 яблоках и SGS S5/A5 и т.д. Я не знаю что вы делаете что бы достигнуть такого результата.

Однако и яблоки не непогрешимы. =) 5,6 яблофон получили багу с wide channel вместе с древним драйвером броадкома. Проблема не решена и не будет решена уже никогда ибо яблоки дров не обновляют. =)))

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

Не удивлюсь если в ещё более старых девайсах используется ещё более старый дров который имеет и глюк с FT. =)

Но ни разу не слышал о проблемах совместимости яблока и Fast Transition и РЕГУЛЯРНО проверяю на них это дело ибо в корп среде они далеко не редкость.

Что-то такое есть, мне кажется. Возможно, некая комбинация галочек в настройках роуминга, которая приводит к фатальным последствиям.  Хотя по-отдельности они(режимы) рабочие.  Если мне склероз не изменяет, у меня r тоже не сразу вот так сработала. Возможно, это обострилось после обновления прошивки. Всё, я пока удаляюсь для сбора доп. инфы.

В софте не трогалось давно по роумнгу ничего. Сбросить на всякий и минимально настроить. Просто что бы точка отсчёта понятная была.

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

К несчастью т.к. handoff это адовый костыль появившейся по причине того что клиенты не умеют зачастую роуминг, то крутанув в нём что-то неаккуратно можно получить любые эффект. Или даже не крутив, а "удачно" разместив AP. Эт достаточно жёсткая штука.

Конкретно - iPad mini (1 gen), iPad4, iPhone5S нормально переваривают любые настройки раздела "роуминг" кроме R. Настройки разумеется в дефолте, только Enable переключаю и все. Отключаю R и остальное можно как угодно менять, к сети цепляются. Только роуминг все равно не работает.

iPhoneSE нормально работает и с R.

Я без претензий, просто для статистики, если еще кто жаловаться будет, может не будете на смех поднимать.

iPhone 5s лично проверено работает с R как из пушки... Однако проверялось в последний раз в январе, в этот раз (неделю назад) девайса в лабе уже не оказалось. Списали старичка. Может в свежих обновлениях чего начудили. Но сомнительно.

Ниже не проверялось ибо даже на тот момент это уже были мамонты.

И опять таки. Всегда пишется репорт вендору. Яблочники почему-то будут писать всем, крутить всё подряд, но яблоку не зарепортят. В итоге живут с этими глюками веками. Хотя в апстримных дровах BCM обычно уже эти глюки все поправили.

Причём с яблоками относительно полноценно нормализовалось всё у большинства вендоров ровно тогда когда они свои роутеры выпускать перестали. =)

А так под них прям в официальных дровах костыли тянуться с самых первых устройств. И каждое устройство разные костыли. Редкий вендор у чипмэйкеров удостаивается отдельного упоминания в workaround`s =)

AP всех клиентов обрабатывает одинаково в зависимости от того, что они умеют.

Конкретно iPhone 5S я и использовал обычно для настройки и тестирования, и он точно с R не подружился. Пришлось SE брать у жены.

Правда, это было неделю назад и с тех пор прилетело обновление (до этого полгода вроде не было), с ним не проверял, тк понял, что роуминг между диапазонами этими клиентами сделать не получится.

 

Раз поддерживается до сих пор, и у вас такое желание сделать всем лучше - напишите репорт в яблоко. Опишите ситуацию и т.д. Может быть яблоко снизойдёт и поправят.

Это самое правильное действие.

Резюмируя, что на сайте wifi alliance есть возможность посмотреть кто прошёл сертификацию по программе voice enterprise. Вот эти устройства должны работать с FT и RRM без проблем. Остальные  - как повезёт.

Однако, если устройство не умеет FT и при этом не работает с роутером на котором включен 802.11R так же является проблемой клиента. Ибо обработка этой (и сходных ситуаций) заложена в стандарте 802.11 и устройства корректно следующие спекам не будут иметь подобных проблем.

 

Не удержался. Попросил парней с лабы найти 5s где-нить и проверить. Результат озвучу. Не было с ним точно никаких проблем в части FT от слова вообще. С 80МГц полосой были.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: