Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

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

Настройка Handoff (принудительно скинуть клиента)

Две точки доступа FT-AIR-DUO-G-4.1.14.RU.04012022.

Включил на обоих Handoff. Пробую гулять между ними со старым телефоном.

Но первая точка не отфутболивает клиента, когда ухожу от неё за две стены.

Пробовал менять пороговые значения, но не помогло.

Подскажите пожалуйста что делаю не так?

 

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

Для начала проверять когда трафик какой-то идёт. Нет смысла сбивать поверсейвнутых  клиентов до которых не летит трафика. Да и не слушают они базу в PSMе. Потому подбиваем только при активности и если 30с (по дефолту) уровни были ниже заданных в том или ином режиме, причём сбиваем как только клиент проснулся и гарантированно нас услышит.

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

Ессно это всё переконфигуриться, однако не стоит увлекаться. Handoff следует использовать очень аккуратно и только когда реально необходимо.

Включили бы k/r/v, вдруг ваш клиент не так безнадёжен и например умеет мигрировать по прилёту BTM. Обычно дуалбэнды почти все худо-бедно умеют мигрировать и умеют handover.

Причём есть нюанс, ряд клиентов не умеет по факту 802.11r но, если в анонсах нет MobileDomain (появляется при включении R) то и мигрировать они никогда пытаться не будут. А для большинства клиентов умеющих R так это вообще норма. Нет MD - нет бесшовной миграции.

В мультиап схеме k/r следует отключать только если что-то из этого приводит несовместимости (реееедкие клиенты при включенном R не могут соединиться, давно  правда таких не видел). v тут уже по задаче и после проверки, что все клиенты нормально переваривают BTM для форсирования рескана и выбора кандидата для миграции, а не тупо отваливаются и затем прилетают назад (бывает и такое).

 

Да, я проверяю, только нагружая канал под завязку трафиком через iperf при том в udp режиме.

k/r/v пока не включаю, так как хочу отладить как будет работать handoff для не умеющих k/r/v устройств.

Сначала отключил вообще все опции роуминга (k/r/v и handoff, band steering по вашей рекомендации вообще не использую), погонял тремя телефонами разных поколений. Самый свежий телефон своевременно мигрирует вообще сам по себе и вполне гладко. А самый старый висит на одной точке доступа до самого упора до момента полной потери сигнала, хотя я подхожу к другой точке доступа прямо вплотную.

Нагружаете и не спинывает? Ну так не бывает.

Варианта 3 почему может не спинывать:

1) уровень выше порога

2) время измерений до принятия решения об отстреле не вышло, а вы уже убежали

3) клиент спит

В противном случае клиента выпнут с ТД с соответствующей записью в лог.

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

Да, обратите внимание на крутилку задающую дельту уровней между 5 и 2.4 ггц диапазонами.

 

В общем проверил. Регресси нет. Все значения кроме дельты оставил по дефолту, дельту уменьшил до 1Дб что бы просто проще было проверить. Получил в результате такие значения переданные драйверу:

Jan 20 13:36:18 roaming: Tune wifi handoff parametrs for ra0 2.4GHz mask: 3;0;0;-75;0;-80;-82;-84;60;-75;14
Jan 20 13:36:18 roaming: Tune wifi handoff parametrs for rai0 5GHz mask: 3;0;0;-76;0;-81;-83;-85;60;-76;14

Как видим отличия по диапазонам 1Дб.

Подключился и унёс железку в ванную.

Через минуту её подбило:

Jan 20 13:39:12 kernel: 5GHz AP Disonnect STA 90:97:f3:10:fd:a6 , RSSI Kickout Thres[-81:-83:-85], Current RSSI [-90], KickOutDelay [61] at last [63] seconds, FT Mode.

Т.е. всё отработало без запинки.

В реальной жизни 5ГГц клиентов сбивать чаще всего не имеет смысла. Они почти все нормально мигрируют, пусть не всегда бесшовно, но крайне редко залипают намертво.

Важно обеспечить такое размещение АП и режим работы радио (уровни в первую очередь) при котором будет возникать ситуация когда клиент инициирует процедуру хэндовера. Чаще всего это падение RSSI на стороне клиента ниже -75дБ на десяток секунд примерно (контроллить удобно auruba utils, там же можно пинг включить что бы клиент не спал).

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

Это так, если совсем "по домашнему".

По вашей рекомендации поставил Aruba Utils и заметил такую вещь - rssi, что показывает Aruba Utils и веб-интерфейс роутера имеют разные значения.
Для задания пороговых значений я сначала пользовался показаниями веб-интерфейса.
Попробовал задавать значения в соответствии с тем, что показывает Aruba Utils (то есть более агрессивные) и хендоф сработал.
Подскажите пожалуйста, здесь какая-то особенность, которую я пока недопонимаю?

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

Естественно разные, ибо в UI роутера мы видим то как роутер слышит клиента, а в утилите то как клиент роутер.

Роутер ориентируется исключительно на то, что может измерить на своей стороне. Как клиент его слышит он не знает.

Давайте ещё раз как Handoff принимает решение об отстреле. Он накапливает статистику по RSSI поклиентно в течении определённого времени (по дефолту минута) и если за это время все измерения ниже порогового значения то взводим флаг говорящий, что клиента нужно убить. И если клиент не спит то его убивает.

Если спит, то измерения продолжатся и флаг "застрелить" не снимается, т.е. как только клиент проснётся его тут же застрелит, если конечно, в этот момент не прилетит с клиента ни одного пакета с уровнем выше порогового.

Ещё раз повторюсь. Не стоит полагаться на handoff как на средство заставить клиента мигрировать чётко где вам нужно и прям сразу. Несмотря на то, что это возможно, но крайне сложно будет затюнить параметры таким образом ибо только эксперементально. Плюс вы гарантированно испортите жизнь нормально мигрирующим клиентам.

Именно потому Handoff по дефолту выключен, а его параметры заданы такими что бы он не мешал (почти гарантированно) клиентам которые умеют мигрировать нормально.

Т.е. его задача подбить совсем уз злостных залипал.

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

Ессно прощай бесшовность, зато можно оочень красиво раскидать абонентов по узлам на автомате.

Тут всегда компромисс...

Handoff это не про роуминг в общем случае, а про балансировку.

Да, но с такими настройками он вроде бы должен был давно спихнуть клиента. Но спихивает, если только задать более агрессивные настройки.

Вот сейчас с такими настройками клиент сидит на первой точке доступа как вкопанный хотя находится в полутораметрах от второй точки доступа, а первая за двумя стенами.

 

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

Остальные настройки роуминга я пока не принимаю во внимание. То есть то, что у меня - это не конечный вариант. Я можно сказать сейчас играюсь с настройками, экспериментирую.
Хочу понять как задавать пороговые значения.
В конечном варианте k/v/r будет активирован в каком-либо виде. А пока экспериментирую с handoff, чтобы понять применимость этой функции в моем случае.

Ещё раз смотрите описание выше. В комплексе и про время измерений и про PSM и т.д. Вы даже режим статистики в расширенный не переключили что бы видеть спит клиент или нет.

И ещё раз обращаю внимение что у вас задана дельта для 5ГГц в -16Дбм. Т.е. что бы правило сработало (для активных клиентов) нужно, что бы в течении 60с на обоих стримах был RSSI = -70 + -16 = -86Дб. У вас эти значения не достигаются.

Описание выше дано максимально чёткое. Разбирайтесь.

P.S. Для того что бы определить применимость следует начать с определения необходимости. В вашем случае для 5ГГц клиентов необходимость крайне сомнительна. А цели, кроме как поиграться, мне не видно.

PP.S.  С такими уровнями как у вас на стороне клиента у него не будет повода даже думать о миграции. И если уровни прибрать то скорее всего никакой handoff вам даром нужен не будет. Вообще стенки у вас похоже картонные.

Читал вашу статью (https://wi-cat.ru/wi-fi-roaming/wifi-roaming-handoff/), но там не описаны параметры настройки, только обещание сделать описание в неком будущем.

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

Подскажите пожалуйста, зачем вообще нужен параметр "Delta threshold rssi level for 5GHz band"?

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

Уровни на скринах чисто для теста. Есть более отдаленные участки квартиры. Handoff нужен, так как точек по крайней мере две. Нехорошо, если телефон будет висеть на первой точке, когда он уже находится в зоне уверенного сигнала второй. Стены кирпичные.

Вообще проекту Wive-NG не хватает какого-нибудь хорошего wiki. Тогда бы сразу бы отпало множество вопросов.

Займитесь.  У нас нет человеческих ресурсов на это. Вот просто нет, от слова совсем. Когда появляется минутка - появляются статьи.

Затухание напрямую связано с частотой + в 5ГГц при том же RSSI, SINR будет выше, а значит качество сервиса будет выше и при более низком RSSI. Поэтому и добавлена дельта. Что бы учесть большее затухание, но при этом меньшее деградацию сервиса в 5ке.

То есть, чтобы на 5 ГГц отфутболивало клиента на более низком RSSI чем для 2,4 ГГц? То есть, чтобы не плодить два, фактически одинаковых, блока настроек для 5 ГГц и 2,4 ГГц?

Еще вопрос возник (может его выделить в отдельный топик?).
Вы где-то упоминали, в каком-то топике форума, что для роуминга на 5 ГГц нужно на всех точках доступа выставить одинаковый канал.
Подскажите почему так? Вроде бы классическим является рекомендация на разных радиоустройства выставлять разные каналы, которые разнесены друг от друга дальше их полосы 20/40/80 МГц?

Не нужно выдумывать. Я говорил что ряд клиентов не умеет мигрировать бесшовно если АП работают на разной частоте, потому как не умеют ни offchannel scan ни RRM, ни background scan за пределами рабочего канала, а активный скан 5ГГц диапазона может занимать вплоть до 7сек и ессно никакой бесшовности и близко тогда не будет.

Как следствие если хотим увеличить шансы, того что произвольный клиент будет бесшовно мигрировать то юзаем одинаковые каналы. Всё зависит от цели, ресурсов и т.д. и т.п. Это вопросы радиопланирования и тут нет единственного ответа на все случаи жизни.

Не нужно ничего ни в какой отдельный топик выделять. Это вопросы уже никак не связанны с Wive, и для них есть иные форумы, например, где обсуждаются вопросы радиопланирования. И даже специализированные курсы с программой сертификации https://www.cwnp.com/certifications/cwna

У нас нет возможности заниматься подобными консультациями. Тем более всё давно есть в сети достаточно лишь использовать гугл.

И заглядывать например сюда https://wi-cat.ru/forums/forum/23/ особенно вот тут https://wi-cat.ru/forums/topic/65/#postid-502

Давайте всё же разграничивать цели данного форума (поддержка ПО) и всё остальное? Спасибо.

Цитата: xredy от 23/01/2022, 12:30

То есть, чтобы на 5 ГГц отфутболивало клиента на более низком RSSI чем для 2,4 ГГц? То есть, чтобы не плодить два, фактически одинаковых, блока настроек для 5 ГГц и 2,4 ГГц?

Бессмысленных 2 блока ибо все значения там так и сяк будут отличаться на одинаковую величину. А чаще всего для 5ГГц вообще handoff будет выключен ибо даром в 5ГГц не нужен и только потенциально мешает нормально мигрирующим клиентам.

Подскажите пожалуйста параметр "Delta threshold rssi level for 5GHz band" учитывается только для параметра "Disonnect sta if rssi low (active clients)" или и для всех остальных?

Для всех. Ибо все параметры взаимосвязаны. В лог загляните там при применении настроек скрипт настройки хэндофф выдает сводку по получившимся цифрам.

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

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

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