Что ещё можно сделать для девайсов которые не умеют никаких FT и не пранируют. ;)

 

На вкладке настройки безопасности увеличить значение параметра Key Renewal Interval до максимума. Т.е. девайсу достаточно будет один раз пройти по всем АП и его будут пускать по короткой фазе, т.е. в режиме реассоциации.

 

По сути этот параметр указывает как часто перегенерировать или удалять из кэша сессионные ключи и если клиент уже побывал на AP а rekey interval ещё не вышел то достаточно просто сравнить кэшированный ключ пользователя и АП что бы быть уверенным что это всё тот же Вася, он уходил, но вот вернулся.

 

Так же можно уменьшить Beacon Interval до примерно 50мс. Это заметно увеличит шансы нахождения АП в результатах BG scan и увеличит шансы на выбор наиболее подходящей АП, однако маяки тоже "едят эфир" поэтому общая производительность радио слегка снизиться.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Начиная с 6.1.1 будет изменена логика принудительного переключения клиентов (ap handoff) в части работы со спящими STA. Дело в том, что часть клиентов не в состоянии корректно обработать ситуацию когда их застрелили во сне, они продолжают думать что подключены и всё хорошо, и игнорируют то что AP им даже после просыпания при их обращении шлёт сигналы что мол всё, уйди (при обработке class2/3 error).

 

Поэтому было принято решение вместо прямого отстрела PSM клиентов взводить TIM бит, что заставит AP сразу послать накопленные в PSM очереди данные спящим клиентам, а тех проснуться и принять их. И вот в этот момент (пока клиент проснулся) мы его и застрелим.

 

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

 

По результатам испытаний время до отстрела спящих клиентов по такой логики увеличивается на 2-3с, но есть и беспробудные товарищи которые напрочь игнорируют попытки достучаться до их разума, по этому их киляет когда они таки сами решат проснуться (данные в любом случае накопленные из очереди надо забирать, и дольше чем пару минут черезчур глубоко спать нельзя, а если уснули на 240с и не забираем данные то АП вообще решит что пациент мёртв). В любом случае такое поведение оказалось менее чреватым проблемами, и более легко переноситься всеми клиентами + даёт больше шансов клиентам с нормальной реализацией миграции самим мигрировать, а не дожидаться пинка под зад.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Немного "радости". Начиная с версии 2.6 wpa_supplicant OKC включен по дефолту. ;) Т.е. новые ведроиды вероятно будут использовать OKC сразу при WPA Enterprise на AP.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Пришла в голову следующая идея:

если столько проблем при переключении от точки к точке и неизвестно что при этом произойдет на клиенте(привет андроидам из китая), то может быть просто не отключаться?

что если при подключении клиента к сети сразу выдавать ему один уникальный SSID и только с этого SSID взаимодействовать с клиентом, а при переходе от точки1 к точке2 мигрировать SSID с точки1 на точку2?

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

Допустим, сеть на 10 точек, к ним 1024 SSID, по сто на точку, примерно столько, сколько может выдержать точка.

Это прямо выглядит как полное решение всех проблем с роумингом на любых клиентах.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По моему фигня, уж простите. Что от этого изменится? Клиенту в любом случае нужно как то мигрировать между сетями, т.е он в любом случае при определенных условиях должен потерять старую точку и подключится на новую, а ваш SSIDperClient никак на поведение клиента вообще не повлияет, потому как если клиент после потери не захотел подключиться(да совершенно по любой причине), то ваш хлам из кучи сетей этого никак не исправят. И следуя вашей логике(хотя я лично ее вообще не уловил), если на точке живет порядка 20 клиентов, то точка доступа должна каким то образом "выложить" дВАдцать SSID'ов на этих клиентов? представляете какой срач вы устроите в эфире? а если у вас 20 точек в работе и 100-200 и более клиентов? Почитайте посты от sfstudio, он достаточно подробно описывает что к чему и почему.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

давайте по шагам

1) клиент1 находится в зоне действия точки1 SSID=SSIDклиент1(и много других) -80dBm и точки2 без SSIDклиент1 -90dBm

2) клиент1 находится в зоне действия точки1 SSID=SSIDклиент1(и много других) -90dBm и точки2 без SSIDклиент1 -80dBm

3) клиент1 находится в зоне действия точки1 SSID=(и много других) -90dBm и точки2 SSID=SSIDклиент1(и много других) -80dBm

то есть для клиента все выглядит так, как будто точка доступа просто переместилась в пространстве прыжком от точки1 до точки2, с учетом того, что у клиента диаграмма ненаправленая, то для него ничего не изменилось кроме того, что сигнал стал лучше, а он при этом сохранил соединение, ip и прочее

По моему фигня, уж простите. Что от этого изменится? Клиенту в любом случае нужно как то мигрировать между сетями, т.е он в любом случае при определенных условиях должен потерять старую точку и подключится на новую, а ваш SSIDperClient никак на поведение клиента вообще не повлияет, потому как если клиент после потери не захотел подключиться(да совершенно по любой причине), то ваш хлам из кучи сетей этого никак не исправят.

клиент и не отключался и исправлять нечего

И следуя вашей логике(хотя я лично ее вообще не уловил), если на точке живет порядка 20 клиентов, то точка доступа должна каким то образом "выложить" дВАдцать SSID'ов на этих клиентов?

да, должна выложить 100 SSID

точка доступа должна каким то образом "выложить" дВАдцать SSID'ов на этих клиентов? представляете какой срач вы устроите в эфире? а если у вас 20 точек в работе и 100-200 и более клиентов?

забинденные SSID просто не надо анонсировать, и никакого срача нет

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

такое реализовано на meru, очень слабая производительность, миграции ssid, конечно, не достаточно, необходимо тянуть как минимум bssid, и ещё уймову тучу параметров соглассованных при инициализации соединения, и то не факт, что клиент нормально отнесётся к переходу с одного канала на другой.

Такие сети называются "безроуминговыми" имеют очень маленькую ёмкость (не сильно отличающуюся от ёмкости одной отдельной точки) и требуются в крайне редких случаях...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1) мы не знаем куда дёрнет клиента на следующем этапе и куда надо переключить логику, нам просто не на что в таком случае ориентироваться

2) чипы имеют аппаратное ограничение на число "слотов" которые можно использовать например под MBSSID(VAP) т.е. с сотнями пролёт, в лучшем случае 16шт. Либо перетаскивать вообще всё в софт, но тогда это надо на SDR каком-нить делать, и сразу запасаться жирным hostcpu

3) такая реализация не чуть не проще реализации обслуживания с помощью переключаемых очередей (как у той же meru) они имеют фатальный недостаток, ёмскость сети = ёмкость одной АП. Ну и требование к транспортной сети в разы выше.

 

Ничего путнего не выйдет пока wifi альянс не почешется и не добавит хотя бы несколько полей на тему управления миграцией в базовую часть 802.11, т.е. не сделает логику миграции и выбора диапазона штатной и стандартизованной по поведению частью 802.11. С массовым приходом 802.11ad им всё же придётся это сделать. Надеюсь по крайней мере. Проблема не на стороне АП что-то реализовать, проблема в том, что клиент всё равно об этом не узнает и не сможет использовать. Нет ниодной технической причины не сделать нормальную миграцию в 802.11. Все причины чисто раздолбайско-лентяйские т.к. отсутствуют жёсткие требования со стороны альянаса на тему реалиазации оного в клиентах.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

, что клиент нормально отнесётся к переходу с одного канала на другой

 

Он никак не отнесётся, он просто будет висеть пока по TxRetryError или DataIdleTimeout не отвалится.

 

Такой подход возможен только когда параметры радиотракта абсолютно идентичны на всей сети. Что ещё существенно снижает ёмкость.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

забинденные SSID просто не надо анонсировать, и никакого срача нет

 

Мы всё равно должны слать как минимум update beacons т.е. один фиг при passive scan всё это будет прекрасно видно в эфире. Более того я ХЗ как клиент отнесётся если ему даже на ходу просто SSID Len объявить равным 0 (hidden ssid). А тут предлагается вообще прекратить маяками пулять... ИМХО работать не будет даже если оставить updat beacons и придушить всё остальное.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Прислали наизабавнейшию штуку. Объяснялка от мотороллы по её революционной функции Roaming Assistance =))) Ничего не напоминает? =)))) Если костыль назвать гордо то костыль сразу превращается в Enterprise технологию. =)

 

Ну и для всех Фом неверующих вот вам мотороллеры авторитетно заявляют, в 802.11 полный бардак с клиентами, и единственный универсальный способ оптимизировать работу wifi сети с множественными AP это пинать и не пускать. =)

 

Ну и там описана только часть схемы. С не ответами на probe req дабы клиент назад не прилетел, которых может и не быть если клиент использует background scan в пассивном режиме. Или у клиента может быть на лету подменён мак (как в новых яблочных осях и ведроидах), что делает невозможным временную преостановку ответов на probe req таким клиентам, т.к. для АП это будет уже другое устройство.

 

Но в общем смысле всё тоже самое. Да и надо сказать у нас погибче будет и уже с учётом причуд новых клиентов и большинства реальных кейзов. =)

Беспроводные WLAN сети корпоративного класса от Motorola Solutions. Технология Roaming Assistance.pdf

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

С 6.1.20 будет добавлено ещё несколько опций в настройки handoff.

 

Первая TmpBlockAfterKick - range 0 - 200 times, after kick block probe/assoc req from kicked STA, default 14

 

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

 

Тем самым мы исключаем реконнект к той же AP. А в случае если клиент не подменяет свой mac при посылке probe req то несколько упрощаем ему задачу выбора кандидата для переключения.

 

times в данном случае это разы. Число попыток общее для проб и ассоциаций. Т.е. например SGS5 после выбрасывания делает 8мь попыток probe (причём залпом) после чего пытается ассоциироваться (причём даже если ему на пробы не ответили). Так вот счётчик будет увеличиваться всю дорогу, т.е. запрет будет снят после 8ми probe и 6ти ассоциаций (нужно что бы не терять клиентов на краях, пусть цепляются фигово но смогут работать). Или если не было не одного запроса то счётчик будет увеличиваться один раз в секунду и запрет будет снят по истечении 14 секундного таймаута.

 

Для примера LG G2 mini не использует кэш и/или фоновое сканирование. В итоге шлёт пробы от своего имени и до упора пока ему не ответят. Так же поступает большинство линуксов и винды (до 8й точно, хотя опять же зависит от драйвера т.к. там каждый чипмэйкер сам себе режиссёр).

 

Вторая KickStaRssiLowFT - range 0 - -100 dBm, auto disonnect sta if rssi low (FT clients), default 0 (off)

 

Т.е. это порог по которому будет отстреливать Fast BSS Transition клиентов. Смысл в том, что если их убивать то прозрачной миграции почти никогда не случается (т.к. это заставляет их выполнить полное активное сканирование всех диапазонов даже если у них есть данные фонового сканирования и там явно присутствует АП с более лучшими параметрами), не всех и не всегда но часто это именно так. А как вы понимаете на активный скан одного диапазона уходит порядка 140мс и зависит как от "ширины" диапазона, так и от числа АП в эфире. Плюс например SGS5 на 6.0.1 андроиде (текущее актуальное обновления) начал с какого-то перепугу при link beat занова просить адреса у dhcp сервера (явная регрессия в их прошивке) при этом дропая адреса на своём интерфейсе и как следствие соединения активных приложений.

 

При этом клиенты умеющие FT зачастую поддерживают самостоятельный хэндовер при низких уровнях и непрерывно ведут базу используя фоновое сканирование. Т.е. сами инициируют переход. Однако делают они это обычно при уровнях -75 и ниже (с точки зрения клиента). И крутилки в большинстве случаев на клиентах для этого дела нет (ну разве что на десктопных интелах под виндой в настройках драйвера можно выбрать агрессивность роуминга, собсно именно порог при котором клиент будет пытаться фоном выбрать кандидата и прыгнуть на него этим и устанавливается).

 

Так вот то бы отделить мух от котлет добавил опцию которая перекрывает порог отстрела для FT клиентов и позволяет установить его заметно ниже остальных порогов. Если задано 0 - отключено и для всех клиентов включая FT будет использована общая логика. Если задано значение то в приоритете для FT клиентов будет именно оно.

 

Совсем не отстреливать их тоже не всегда возможно, т.к. некоторые клиенты не смотря на то, что умеют FT всё же имеют свойство залипать намертво до отстрела на одной АП (т.е. хэндовер на их стороне реализован некорректно или вообще не реализован кроме как по link beat). Потому сделал так.

 

Из advanced в basic roaming перенесены следующие опции.

1) Idle timeout before disconnect 240 sec (range 60 - 300) - если до клиента ничего не ходит (т.е. вообще ничего даже managment) то считаем что он умер и отстреливаем, уменьшение значение несколько разгрузит AP, но может приводить к ложным срабатываниям на глубоко спящих клиентах

2) TX retry fail before disconnect 1024 times (range 256 - 4096) - застрелить клиента если число попыток передачи в его сторону за последнюю секунда привысило значение (меньше - быстрее отстрелит полутрупов-глухарей часто прилипчивых, но может вызвать ложные срабатывания)

 

Эти параметры на самом деле к роумингу отношения почти никакого не имеют, однако крутить их имеет смысл только при настройке балансировки клиентов по AP и очень аккуратно

 

Плюс добавлен вывод в лог при соединении информации о том использует ли клиент Fast BSS Transition. Строчка если использует будет выглядеть так:

ASSOC - Assign AID=1 to 5GHz STA <мак адрес>
ASSOC - Update AP OperaionMode=1 , fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1, FT mode

 

Как допилят морду по этому делу так сразу зарелизим. Это будет последней сборкой в ветке 6.1.х Т.е. текущий рекомендуемый stable.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кстати вот есть такой списочек:

https://www.intel.com/content/www/us/en/support/network-and-i-o/wireless-networking/000021562.html

 

Т.е. видим что до 7625 интела ни о какой поддержку K/R речи не идёт (ну как минимум под виндами), при этом те же 3160 и 7260 прекрасно роумятся, имеют настройки агрессивности миграции, умеют выполнять в фоне попытку реассоциации до того как дропнуть текущее соединение совсем (при условии что кандидат на той же частоте работает, или с использованием логики с временным переходом в PSM описанное некоторое время назад), умеют фоновое сканирование, выбор preffered band (т.е. и band steering им не нужен, но и не мешает там где есть) и т.д. и т.п. В итоге и без вских K/R прекрасно мигрируют без пинков со стороны AP и даже мультикаст лишь соегка подсыпает. Т.е. от АП требуется только очень быстро приземлить и форсировать доставку ARP от мигрирующего клиента в DS что бы свитчи максимально быстро перестроились.

 

Когда гугл перестанет выделываться и из коробки реализует подобную логику + вынесет пару крутилок - проблема с band steering и миграцией решиться сама собой. А пока развлекаемся с костылями и дальше.

 

Т.е. проблема с миграцией большинства клиентов не в неумении ими ускорения фазы аутентификации (за исключением случаев с применением WPA Enterprise где без поддержки FT/OKC АП будет каждый раз бегать до радиуса, что накладно с точки зрения задержек), а именно в логике миграции на стороне клиента, и отсутствие средств управления этой логикой со стороны AP. Кто мешал заложить в IECAP или даже в RRM CAP несколько полей через которые можно было бы управлять порогом сканировния/миграции, предпочтительными режимами и принудительно инициировать штатную клиентскую логику хэндовера я ХЗ. Надеюсь разум возобладает и хотя бы вышеозвученное хотя бы гугл осилит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для андроидов есть костылик https://play.google.com/store/apps/details?id=com.heleron.wifiroamingfix&hl=ru Решает проблему того что клиент висит до последнего на АП позволяя выбирать уровень при котором клиента будет переключать на новую АП. Но он не решает проблемы "бесшовности". Так же не решает проблему с выбором preffered band. Т.е. применим только там где обрывы соединений клиентских приложений не критичны, и где все устройства сети подконтрольны.

 

Хотя автор мог бы сделать версию с поддержкой root и командовать wpa_cli roam <mac кандидата> не дожидаясь штатной андроидной логики, и эта бы проблема бы тоже решилась.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Залил 6.1.20 на wive-ng.sf.net с указанными правками.

 

Ну и ещё немного статистических данных. Погрепав логи офиса NAG на предмет того кто же юзает Fast BSS Transition ещё раз убедился, что это ровно 3 колеки. А именно примерно 2/3 яблофонов (которых самих совсем немного), и 1/3 самсунгов. Никакие другие устройства в сети NAG не используют FT. Т.ч. читай не умеют его.

 

Т.е. в прямом смысле слова. =) Ещё раз перепроверил и не увидел что бы кто-то кроме части яблок и части самсунгов по факту юзал 802.11R. Я как бы и до этого не сомневался, но вот настало время подбить статистику...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

а сколько всего устройств в сети?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Сейчас 103 активных (обычно болтается от 80 в обеденное время до 120 в пиках), всего регается за день чуть за 200. Причём там набор полный за исключением разве что безродного китая. Это техника сотрудников. А сеть = этаж ТЦ Краснолесья который собсно целиком теперь НАГ занимает. Этаж в смысле =)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Хотя автор мог бы сделать версию с поддержкой root и командовать wpa_cli roam <mac кандидата> не дожидаясь штатной андроидной логики, и эта бы проблема бы тоже решилась.

ну так может запилить свою версию с блэкджеком и шлюхами? )

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну дык напишите... Мне вот откровенно лень этим заниматься. Идея думаю понятна.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот пример правильного поведения при миграции в т.ч. использование FT+RRM. Собсно Apple.

Jul 10 09:38:29 172.31.68.23 kernel: ASSOC - Assign AID=5 to 5GHz STA 60:d9:c7:29:a9:55, FT mode
Jul 10 09:38:34 172.31.68.21 kernel: ReASSOC - Assign AID=1 to 5GHz STA 60:d9:c7:29:a9:55, FT mode
Jul 10 09:38:34 172.31.68.23 kernel: 5GHz AP ASSOC - receive DIS-ASSOC(seq-149) request from 60:d9:c7:29:a9:55, reason=7

 

Т.е. клиент при падении уровня ниже заданного у него порога (на самом деле у всех считается по разному, да и даже внутри разных яблок по разному, где-то дельта уровней ситается где-то просто порог и т.д.) получив данные о ближайших AP из RRM (похоже только яблоки это умеют, допиливаю сейчас, с 6.2.2 уже работает осталось только несколько вопросов закрыть), клиент выполняет короткое фоновое сканирование на каналах на которых работают подходящие с его точки зрения AP в целях подтвердить/скорректировть выбор кандидата для миграции, не "обрывая связи" (т.е. не деатентифицируясь шлёт probe req выбранной АП и если всё хорошо посылает Reassoc Req т.е. пытается мигрировать с использованием короткой процедуры аутентификации. И только после того как его пустили на новую АП шлёт DIS-ASSOC предыдущей.

 

Для пользователя такая миграция будет прозрачной. Замечу что клиент сам принимает решение когда начать процесс миграции и куда именно он будет мигрировать. Только в этом случае всё будет почти "как у взрослых" дектов и иже с ними.

 

И тут критичнее всего наличие именно правильной логики миграции на клиенте. На втором месте RRM что бы не сканировать весь диапазон (в 5ГГц это может занимать очень много времени в зависимости от того какие региональные ограничения в той или иной стране). Но проблема как раз в том что RRM большей частью никто и не умеет ;(

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот небольшой списочек с описанием различий в поведении при миграции от CISCO: http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/device_classification_guide.html

 

Однако данные несколько устаревшие и похоже (ну как минимум на S5) самсунг заломал логику миграции (не используются данные RRM и зачем-то выполняется link down перед ресканом) в 6.0.1 обновлении.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А вот казалось бы тоже яблоко, но видимо другого поколения:

Jul 10 09:04:40 172.31.68.23 kernel: ASSOC - Assign AID=4 to 5GHz STA 18:65:90:7e:cf:b2, FT mode
Jul 10 09:30:32 172.31.68.23 kernel: ASSOC - Assign AID=4 to 5GHz STA 18:65:90:7e:cf:b2, FT mode
Jul 10 09:43:00 172.31.68.16 kernel: ASSOC - Assign AID=1 to 5GHz STA 18:65:90:7e:cf:b2, FT mode
Jul 10 09:47:19 172.31.68.12 kernel: ASSOC - Assign AID=1 to 5GHz STA 18:65:90:7e:cf:b2, FT mode
Jul 10 09:50:21 172.31.68.23 kernel: ReASSOC - Assign AID=4 to 5GHz STA 18:65:90:7e:cf:b2, FT mode
Jul 10 10:20:24 172.31.68.29 kernel: ReASSOC - Assign AID=2 to 5GHz STA 18:65:90:7e:cf:b2, FT mode
Jul 10 10:21:13 172.31.68.32 kernel: ASSOC - Assign AID=2 to 5GHz STA 18:65:90:7e:cf:b2, FT mode
Jul 10 10:21:43 172.31.68.29 kernel: ASSOC - Assign AID=2 to 5GHz STA 18:65:90:7e:cf:b2, FT mode
Jul 10 10:23:42 172.31.68.16 kernel: ASSOC - Assign AID=1 to 5GHz STA 18:65:90:7e:cf:b2, FT mode
Jul 10 10:31:17 172.31.68.23 kernel: ASSOC - Assign AID=4 to 5GHz STA 18:65:90:7e:cf:b2, FT mode

 

Не смотря на то что использует FT но один фиг пытается всегда ассоциироваться и аутентифицироваться "по полной", при этом не прощается с предыдущими АП впринципе, ну хотя бы в 90% случаев мигрирует без пинка.

 

Самсунги зачастую кстати тоже не утруждают себя прощанием.

 

 

Т.е. логика поведения при миграции отличается даже среди железок одного класса и одного вендора, зависит от версии оси и похоже погоды на солнце.

 

А ведь по хорошему логика со стороны АП должна предусматривать возможное поведение. В итоге оптимизируем миграцию на одних - ухудшаем для других...

 

Единого поведения не наблюдается вовсе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Детальное описание логики миграции от яблока правда на практике я вижу несколько иное поведение, и сильно отличающееся от версии устройства https://support.apple.com/en-us/HT203068

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну и так для раздумий. Фуллскан wpa_sullpicant nl80211 драйвер карта Intel 7260:

nl80211: Scan included frequencies: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 5745 5765 5785 5805 5825
wlan0: Event SCAN_RESULTS (3) received
wlan0: Scan completed in 3.165684 seconds

 

Т.е. просканировать оба диапазона это больше 3х секунд. Т.е. даже если клиент не решил залипнуть в 2.4 и его там не начал выпинывать Band Steering то миграция будет выполнена не меньше чем за эти 3 секунды.

 

Вот тут и может помочь RRM. Чуть позже расскажу как. Ну и дураку ясно что 802.11R со своим ускорением PSK аж на десяток мс тут просто меркнет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну и для сравнения время авторизации без FT по полной процедуре:

1499941539.096053: wlan0: SME: Trying to authenticate with f8:f0:82:9f:70:62 (SSID='SF' freq=5220 MHz)
1499941539.099222: wlan0: Trying to associate with f8:f0:82:9f:70:62 (SSID='SF' freq=5220 MHz)
1499941539.102714: wlan0: Associated with f8:f0:82:9f:70:62
1499941539.102769: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
1499941539.235426: wlan0: WPA: Key negotiation completed with f8:f0:82:9f:70:62 [PTK=CCMP GTK=CCMP]
1499941539.235491: wlan0: CTRL-EVENT-CONNECTED - Connection to f8:f0:82:9f:70:62 completed [id=2 id_str=]

 

в человеческих величинах, старт в 15:25:12.096. Все проверки пройдены и клиент работает в 15:25:12.235.

 

Т.е. 235-96=139мс. В зависимости от клиента может быть чуть быстрее или чуть медленнее. Процедура реассоциации и FT примерно вдвое быстрее. При работе с локальным радиус сервером в 802.1x полная процедура уже занимает около секунды. Но даже это минимум втрое меньше времени затраченного на полный рескан обоих бэндов.

 

На замету. В Android миграцию выполняет не wpa_suppicant и решение принимает не он. Суппликант в Android собирается с опцией NO_ROAMING. Всё вынесено на уровень дров и специфично для каждого из чипмэйкеров чьи чипы вендор заюзал в своих устройствах (раньше по теме была ссылка на BRCM драйвер там можно посмотреть ради интереса).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!


Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.


Войти