Запрос на функцию: CAPsManager — роуминг

Есть ещё одна проблема с «бесшовным» Wi-Fi. Если телефон подключается к ap1, а владелец телефона переходит к ap2, но телефон всё ещё остаётся подключён к ap1 с плохим сигналом. Ubiquiti использует централизованное управление, чтобы отключать клиентов от удалённых точек доступа. Было бы здорово, если бы capsman мог делать то же самое.

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

Проголосуйте и за это тоже. Очень люблю продукты Mikrotik, и обидно, что ubnt уже внедрили какое-то альтернативное решение, а у нас его до сих пор нет. Но, по крайней мере, надеюсь, что оно начинает появляться, и развитие CAPsMAN — это действительно хороший шаг.

Привет, я тоже за это проголосую! С уважением, Куба

Привет, думаю, нам не стоит волноваться насчёт seamless/zero-handoff, в первых версиях контроллера UBNT этого не было, так что, полагаю, это лишь вопрос времени, когда capsMan это получит.

Количество дезинформации просто поражает! Во-первых, роуминг — это всегда решение клиента: когда переключаться, к какому AP перейти, какую полосу (2.4 или 5 ГГц) предпочесть. Процесс очень простой: все AP передают beacon со своим SSID. Клиент, подключенный к AP А, время от времени сканирует другие AP. Клиент слышит beacon (на самом деле это probe response, но давайте упростим), у которого SSID совпадает с тем, к которому он уже подключён. Клиент замечает, что сигнал от AP В лучше, а отношение сигнал/шум (SNR) у AP С лучше. Клиент решает перейти на AP С (потому что в алгоритме клиента прописано отдавать предпочтение хорошему SNR, а не более высокому уровню RSSI — это называется превентивный роуминг). Клиент отправляет AP А кадр Disassociation, а AP С — кадр Association. Оба AP принимают. Клиент (а иногда и AP С) отправляет gratuitous ARP и иногда DHCP Renew через AP С, чтобы сообщить коммутаторам в сети о новом местоположении на проводном LAN.

Как видите, ни один AP ничего не делает, чтобы заставить клиента переключиться. То, о чем говорит автор, — это Single Channel Architecture компании Meru, которую скопировала Ubiquiti под названием Zero Handoff. Проще говоря, AP динамически создает виртуальную точку доступа для каждого подключённого клиента. Инфраструктура (Meru контроллер) затем перемещает эту виртуальную точку доступа между разными AP, в зависимости от того, где контроллер хочет видеть клиента. По сути, это обманывает клиента, заставляя его думать, что других AP нет, и поэтому он в реальности не совершает роуминг.

У SCA/ZH есть свои плюсы и минусы, но современные устройства значительно улучшили алгоритмы роуминга, и минусы этих технологий сейчас перевешивают плюсы. Даже Meru отходит от этой архитектуры. 802.11r и 11k — это стандартизированные протоколы, созданные для помощи роумингу клиентов. Обратите внимание на слово «помощь», потому что решение всё равно принимает клиент. 11r просто избавляет от долгого обращения к RADIUS-серверу при аутентификации 802.1x, а 11k сообщает клиенту о соседних AP, чтобы не тратить время на бесполезное сканирование эфира.

VoIP отлично работает и сегодня на любой стандартной WLAN, если она правильно настроена и используются хорошие VoIP-телефоны. Если хотите пример совсем плохого устройства для роуминга, не надо далеко ходить: MikroTik с WLAN-интерфейсом в режиме Station не будет сканировать или переключаться, пока полностью не потеряет соединение с AP. Это называется реактивный роуминг, и никакие «настоящие» Wi-Fi-клиенты (телефоны, планшеты, ноутбуки) так себя не ведут.

Примечание: я говорю «плохо», но на самом деле MikroTik рассчитан на фиксированные PTP/PTMP соединения, где роуминг вообще не нужен.

AP может отключать. Но потом клиент сам решает, к чему пытаться подключиться.

Мне тоже было бы интересно.