HandOFF дословно — передавать. Однако, в контексте 802.11 я бы скорее перевёл бы этот термин (применительно к AP) как “руки прочь”.
В третьей части цикла мы рассмотрели такую процедуру как handover, которую выполняет клиент для миграции внутри wi-fi сети.
А что делать, если клиент по какой-то причине отказывается инициировать переход? А если клиент вообще не умеет самостоятельно мигрировать?
Вот тут к нам на выручку придёт механизм HandOFF. Как обычно в 802.11, этот механизм не является частью стандарта, не обязателен к реализации и вообще не предусмотрен. Сюрпрайз!
Настройки HandOFF в Wive-NG
Ну что же, нам не привыкать.
В чём смысл? А смысл прост, AP мониторит уровни от клиентов, и при достижении минимального порога посылает DEAUTH сигнал клиенту.
Клиент благополучно «слетает» с AP, а дальше…
А дальше выполняет всё то, что мы описывали в первой части. Чаще всего при этом сразу же будут оборваны все соединения локальных приложений. Т.е. так называемой бесшовностью тут не пахнет. Исключение составляют разве что клиенты с модифицированной логикой обработки события прихода DEAUTH фрейма и обработкой его как сигнала к форсированию логики handover. К сожалению, этот вариант встречается не очень часто, например, так умеет радио от Qualcomm (описывал опцию в соседней статье, см. опцию gEnableHandoff).
Кто-то разумно заметит, что DEAUTH фрэйм может быть послан с несколькими десятками reason code. Зачем слать StaLeave, если можно использовать что-то более «мягкое».
Ну во-первых, потому что ничего более мягкого по сути и нет. А во-вторых, в 802.11 как обычно, даже если в стандарте это есть, совсем не факт, что на деле эти reason коды будут обработаны клиентом, т. е. вообще будет присутствовать реализация обработки этих reason`ов.
Как пример, вот что об этом говорит CISCO. Смотрим табличку https://supportforums.cisco.com/t5/wireless-mobility-documents/802-11-association-status-802-11-deauth-reason-codes/ta-p/3148055
Нас интересует 802.11 Deauth Reason Codes. Слегка офигиваем от NOT SUPPORTED и успокаиваемся.
Справедливости ради стоит заметить, что в 802.11 есть нужный reason за номером 12 – Disassociated due to BSS Transition Management. Однако, даже CISCO оный ризон не поддерживает. И вообще, по факту мне не удалось найти клиента, который бы его обрабатывал корректно.
Чаще всего клиент его обрабатывает так же как и 8 (sta leave) или же вовсе игнорирует, и в итоге получаем клиента, который до упора будет считать, что подключен к ТД, в то время как ТД считает, что клиент обработав сигнал ушёл на соседнюю AP.
В результате, даже если клиенты, умеющие 12 reason и существуют в природе, мы всё равно вынуждены, ради совместимости, слать всё тот же Sta Leave т. к. ТД не знает, что именно реализовано в клиенте.
Также нет никаких механизмов сказать при этом клиенту, куда нужно мигрировать, и нужно ли вообще.
Проще говоря, мы просто выпинываем (kick out) клиента с ТД и надеемся, что клиент переключится на более подходящую ТД, что не всегда так. А многие клиенты первым делом пытаются вернуться назад. Или вовсе впадают в ступор и ждут, пока пользователь снова ткнёт «подключиться». Благо, последний вариант всё же редкость. А против возвращенцев можно использовать временную блокировку на уровне probe/assoc/auth (как, например, это сделано в Wive).
Подведём итог. Handoff в 802.11 это по сути простое спинывание клиента с ТД в надежде, что клиент перейдёт на соседнюю ТД с лучшими параметрами. Процедура инициируется ТД, что даёт возможность более гибко, исходя из различных параметров линка (но чаще всего просто из уровня, с которым AP слышит клиента) вынуждать клиента мигрировать (не всегда успешно и почти всегда с потерей соединения приложениями).
Безусловно, это лучше, чем ничего. И если не стоит задачи получить именно бесшовность, то можно смело использовать данный механизм для балансировки нагрузки и обеспечения максимальной производительности сети. И/или как подстраховку в бесшовной сети для клиентов, не умеющих мигрировать самостоятельно. Правда в этом случае придётся выбрать порог срабатывания настолько низкий, чтобы не затронуть нормально мигрирующих клиентов. Что в свою очередь сильно уменьшит эффект от такой балансировки.
В ближайшее время постараюсь расписать, как handover реализован у нас (в Wive-NG), как его настроить в зависимости от задачи и т. д.
P.S. По традиции немного веселья из мира Enterprise $). Описание настройки handoff для Ruckus : https://support.ruckuswireless.com/answers/000002277. Они называют это smart roam. Как всегда в мире Enterprise, любой костыль выдаётся за мегадостижение, а т.к. сейчас всё SMART, то и костыль должен быть Smart. Также по ссылке есть рекомендации по отладке роуминга, которые сводятся к обновлению софта (видимо для поддержки RRM) и настройке агрессивности роуминга на клиенте (говорил в первой части об этой опции). Ну и если совсем не помогло, включаем smart roam. =) Ну и обилие опций (аж одна штука) поражает воображение. =)
