[sfstudio]

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

 

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

 

ZH (как и аналог от мираки) это попытка обойти в т.ч. этот момент. Решение крайне спорное и потенциально крайне геморройное для отладки. Но судя по словам убнт они таки это умудрились реализовать. Молодцы. Для определённых задач вполне пойдёт.

 

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

[sfstudio]

понятие относительное по отношению к сервису ( работающему приложению), он не должен прерываться ( деградировать) и определяется обеспечиваем latency

 

Большинство сервисов (работающих приложений) работающих что voip/online tv (кстати хоть тыртуб относительно недавно научился) и т.д. не учитывают что надо уметь быстро сделать реконнект ещё и без потери того что работало (было бы прекрасно буть это так), а т.к. клиент дропнул сэйты то будет прерывание сервиса.

[slv700]

щё раз ZH это не вид аутентификации, и работает на открытой сети.

ZH как раз работает только в сети c WPA аутентификацией. В открытой сети на ubnt без аутентификации WPA нельзя задать Zero Handoff. Собственно ZH является элементом WPA аутентификации на AP.

[slv700]

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

 

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

 

Дропнется клиент или нет зависит от соединения по радио клиента и точек доступа. Если клиент выйдет из зоны старого AP при переходе на новый, то дропнется , но ZH роуминг все равно будет работать. ZH от этого факта дропа клиента никак не зависит - accociation клиента -то есть его аутентификация и авторизация сохранятся, новый IP адрес не понадобится и поэтому AP при ZH не позволит DHCP обновить адрес.

А уйдет ли состояние радио интерфейса клиента в down не имеет значения. Up /Down клиента занимают незначительное время ( клиент же не ребутится). Не упадет стейт- хорошо, сэкономим пару мс, а упадет- тоже нормально, в общем -без разницы.

А вот если AP работают на разных каналах, тогда время на поиск нового AP это есть проблема , по сравнению с котором время up/down интерфейса- пустяк. Но ZH это это не грозит, там все AP работают на одном канале.

[slv700]

У вас неверной понимание постановки задачи роуминга. Есть такой стандарт на роуминг wi-fi клиента, в том числе с сетями 3/4G- Passpoint 2.0 или HotSpot 2.0

Hot Spot 2.0 (HS 2.0), also called Wi-Fi Certified Passpoint, is a new standard for public-access Wi-Fi that enables seamless roaming among WiFi networks and between WiFi and cellular networks. HS 2.0 was developed by the Wi-Fi Alliance and the Wireless Broadband Association to enable seamless hand-off of traffic without requiring additional user sign-on and authentication..

Это задача аутентификации клиента при смене точки доступа wifi или 3/4G без прерывания трафика ( если быть точнее сервиса/приложения ) клиента. Задача постоянного поддержания интерфейса клиента в UP ( wifi или 3/4G) при роуминге интересует в самую последнюю очередь, я бы сказал- это вообще не вопрос роуминга.

[slv700]

Но судя по словам убнт они таки это умудрились реализовать. Молодцы. Для определённых задач вполне пойдёт.

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

[sfstudio]

ZH как раз работает только в сети c WPA аутентификацией. В открытой сети на ubnt без аутентификации WPA нельзя задать Zero Handoff. Собственно ZH является элементом WPA аутентификации на AP.

 

Уверены? Потому как они на мыло пропели совсем обратное. К сожалению реализацию изнутри не видел, но по их данным там привязки вообще нет к секурити, а реализация как у кискокупленников сводиться именно к "растягиванию" АП.

 

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

 

И в чем же они молодцы ? Есть стандарты на роуминг, их надо соблюдать.

 

802.11K/R/V не являются обязательными к реализации. И требуют поддержки со стороны клиента, с чем туго. Так что даже если:

А сделать какую ту максимально упрощенную проприетарную фичу, которая работает ( как всегда это имеет место у убнт) только в узком диапазоне условий и ограничений- это ошибка.

 

И то плюс.

 

У вас неверной понимание постановки задачи роуминга. Есть такой стандарт на роуминг wi-fi клиента, в том числе с сетями 3/4G- Passpoint 2.0 или HotSpot 2.0

Hot Spot 2.0 (HS 2.0), also called Wi-Fi Certified Passpoint, is a new standard for public-access Wi-Fi that enables seamless roaming among WiFi networks and between WiFi and cellular networks. HS 2.0 was developed by the Wi-Fi Alliance and the Wireless Broadband Association to enable seamless hand-off of traffic without requiring additional user sign-on and authentication..

Это задача аутентификации клиента при смене точки доступа wifi или 3/4G без прерывания трафика ( если быть точнее сервиса/приложения ) клиента.

 

Это пока ещё ни у кого вообще не жизнеспособно, судя по реализации в последних драйверах от MTK/Ralink ещё долго не будет жизнеспособна.

 

Задача постоянного поддержания интерфейса клиента в UP ( wifi или 3/4G) при роуминге интересует в самую последнюю очередь, я бы сказал- это вообще не вопрос роуминга.

 

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

[slv700]

Уверены? Потому как они на мыло пропели совсем обратное. К сожалению реализацию изнутри не видел, но по их данным там привязки вообще нет к секурити, а реализация как у кискокупленников сводиться именно к "растягиванию" АП.

См документацию на котроллер. Или вот здесь обсуждают почему это вдруг ZH нет без WPA. Да потому, что ZH -это ответвление процедуры WPA, инициируемый AP при выполнении определенных условий. Если клиент поддерживает WPA, то ZH ubnt на нем работает, ничего дополнительного не надо.Собственно FT roaming - он же Fast-Secure Roaming, то есть это элемент аутентификации. Одинаковый SSID, частоты ( эффект растягивания AP), ну и использование собственно WPA - это ограничения, при которых эта схема ZH ubnt работает.

802.11K/R/V не являются обязательными к реализации. И требуют поддержки со стороны клиента, с чем туго

802.11r - это стандартизованный ( обязательный де факто) FT roaming. 802.11k- это выбор AP при роуминге, необязательный, к аутентификации не имеет отношения, 802.11v- вообще к роумингу не имеет отношения.

FT требует поддержки на клиенте, ну так и что ? WPA2 тоже требует поддержки на стороне клиента. Все это есть и на Андроиде и Apple.

FT 802.11r нормально работает на Cisco точно также как проприетарный Сisco CCKM. Собственно Сisco этот Fast Secure Roaming и придумало.

Я абсолютно уверен что FT 802.11r будет хорошо работать на Камбиум cnPilot. Сейчас находится в бета тестировании.

Но почему свет клином сошелся на этих разновидностях Fast Secure роуминге?

Есть обычный не Fast, а роуминг при стандартной 802.1x/ WPA Enterprise ( WPA2-PSK и WPA2 EAP) аутентификации. Точки доступа и контроллеры сертифицируются как Passpoint2.0 ( HotSpot 2.0). Поддерживаются Cisco, Ruсkus и др. Cambium cnPilot ( полное соответвие HotSpot 2.0 ( Passpoint) тоже в роадмап.

Я так понял Вы -программист вайфай SNR? Так чего фигней маетесь с дисконнектами клиента и пропритарными решениями чтобы время этого дисконекта уменьшить? Если хотите, чтобы на вашем оборудовании работал seamless роуминг ( даже в корпоративном SME сегменте, не обязательно в Hotspot публичном доступе), то точке доступа делайте функционал Passpoint 2.0 ( не весь конечно, а то что вас касается).

Если дополнительно нужен Fast-Secure ( Fast Transition)роуминг ( для работы VoIP), то делайте функционал 802.11r.

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

[slv700]

И то плюс.

У убнт нет продвинутых архитекторов систем, они им и не нужны, потому что ubnt не ставят серьезных задач разработки правильных систем ( дорого, не впиcываются в target price). Обходятся красивым дизайном ( оберткой) устройств, видимо это осталось еще со времен , когда их президент работал в Apple,мощным маркетингом, но вот мозгов ( правильного софта) у всех без исключения устройств ubnt нет. Делают по софту всегда все упрощенно, какие то костыли, приморчки,с нежизненными ограничениями, что как то работает только у пионеров и только потому, что эти пионеры и не знают как это должно правильно работать.

[sfstudio]

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

2) 802.11r не требуется для сертификации 802.11 wifi альянсом, а значит необязателен

3) FT даже гуглом заявлен только с 6ки, я грю что должен быть и есть разные вещи, с андроидом вообще раздрай, проще найти AP умеющую оный, чем клиента

4) с 802.1x WPA Enterprise проблем нет, кроме опять таки что не всё так разужно и сказать клиенту куда пересеть не реально, т.е. опять таки только решение проблем с авторизацией, куда переключиться и как будет выполнена процедура (со сбросм стэйтов или без) это уже на совести клиента

 

Я так понял Вы -программист вайфай SNR? Так чего фигней маетесь с дисконнектами клиента и пропритарными решениями чтобы время этого дисконекта уменьшить?

 

Можно и так сказать. Я то и не маюсь фигнёй. Я смотрю все решения. У меня работает в железе 802.1x/ENT, базовый вариант с отстрелом, работает R с новым драйвером (но там есть проблемы в продакшн пока не пускаю), но и смотрю решения что бы заставить куцих клиентов не отваливать соедиенения приложений при миграции, и вот тут сделать почти ничего не реально, ибо вендор их так логику написал на клиенте что link down/up = сброс стэйтов соединений, т.е. едиснтвенный вариант придумывать как сделать так что бы клиент вообще ничего не знал о переключении.

 

Если хотите, чтобы на вашем оборудовании работал seamless роуминг ( даже в корпоративном SME сегменте, не обязательно в Hotspot публичном доступе), то точке доступа делайте функционал Passpoint 2.0 ( не весь конечно, а то что вас касается).

 

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

 

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

 

Я привык разбирать всё по полочкам от и до и принимать решение на что тратить время в первую очередь при понимании что это не будет время потраченное в пустоту, именно поэтому сначала извучаю вопрос, затем уже дёргаюсь. У меня нет 100500 студентов что бы делать что-то что в итоге будет почти мертво как 802.11r т.к. потребуется что бы клиенты это тоже умели, но таких клиентов будет кот наплакал из 3х вендоров по конским ценам.

 

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

 

Увы жопа с поддержкой всех плюшек заложенных в расширения 802.11 включая 802.11r (тот же риалтэк класть хотел и в mobile sdk для андроид поддержкой K/R/V не пахнет) приходиться городить. А отсутствие нормальных заложенных в протокол методов контроля миграции клиентов и возможности повлиять на критерий выбора АП при миграции клиентом со своей стороны заставляет рассматривать и костыли как возможное и допустимое в редких случаях решение.

[sfstudio]

802.11v- вообще к роумингу не имеет отношения.

 

Не совсем так, это единственный протокол который в стеке 802.11 позволил бы иметь на клиенте чуть больше инфы о топологии сети при планировании в т.ч. миграции со стороны клиента. Хотя говорить о нём смысла нет, поддержки даже близко нигде не видно. Так же как почти никто из клиентов не умеет учитывать инфу о загруженности BS в beacon при выборе вариантов куда коннектиться.

[sfstudio]

P.S. Вот спор эт хорошо (если он не с батареей аля Сааб), появилась хитрая идея как как минимум для TCP обеспечить полную прозрачность миграции даже если по какой-то причине ip на клиенте сменился, при этом без доп софта и затрагивания вообще логики переключения в радиочасти как на клиенте так и на АП. Займусь на досуге смоделирую логику. Увы траблы со сбросом стэйтов это не решает. Тут надо думать, и ждать пока хотя бы существенное количество клиентов не будет этого делать как бы не вариант.

[gustas0617]

То что вы описали вообще не имеет никакого отношения к роумингу между AP. Это что то вроде проприетарного распределения нагрузки между AP или х.з. что. Роуминг клиента,- вообще любой 1) между Radius серверами провайдеров WISPr, 2)между AP одного или нескольких контролеров в группе seamless или FT roaming - это вопрос механизма аутентификации клиента при смене точки доступа- а именно- где и как аутентифицируется клиент при смене точки доступа.Вопрос передачи управления трафиком клиента -вторичен. Никакие фронэнды и бекэнды, очереди пакетов не имеют к аутентификации клиента при смене точки доступа -роуминге никакого отношения. Мы вообще говорим о разных вещах.

Да, это все так. Но самое главное в Роуминге, как быстро он работает. На данный момент то что я тестировал, только поддержка 802.11r/k может сделать бесщовный роуминг по приемленной цене. А офисе мы планируем поставит 8шт cap1750 так как обещали сделать поддержку 802.11r/k до конца февраля.

[sfstudio]

Ну вот и расскажете как оно на практике.