Относительно недавно была добавлена базовая поддержка варианта принудительного переключения клиента для обеспечения балансировки и роуминга (доступна для всех устройства SNR из MT серии). Это значит что появилась возможность распределять нагрузку по разным AP внутри сети. Выглядит это так. Финальная версия полноценно будет доступна для всех устройств начиная с 3.6.0 версии прошивки релиз которой намечен на эту неделю.

roam_eng.jpg

roam_ru.jpg

roam_eng.jpg

roam_ru.jpg

 

Определение роуминга от WiFi-Alliance (собсно компания развивающая 802.11 и определяющая как этот самый wifi работать должен) https://www.wi-fi.org/knowledge-center/faq/how-does-a-client-roam

 

По простому, при перемещении клиент должен измерять RSSI текущего подключения и время от времени сканируя эфир при падении RSSI переключиться на зарание выбранного кандидата. Некоторые, более искушённые клиенты могут для ускорения выбора кандидата использовать например RRM, а для ускорения фазы аутентификации FT. В целом же конкретная логика миграции отличается от вендора к вендору (говорит нам WiFi aliance).

 

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

 

Все подробности по работе wifi роуминг, реализаций handover/handoff/RRM/FT, примеры клиентской логики  и т.д. и т.п. можно найти в этой теме, которая будет регулярно пополняться по мере изучения всех встреченных мной вариантов.

roam_eng.jpg

roam_ru.jpg

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


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

Теперь едем по параметрам:

1) Максимальное число probe запросов от клиента сколько probe запросов в секунду может быть обработано от клиентов. По сути защита от флуда при выборе станции клиентами. Если AP много видимых разом и уровни высокие можно уменьшить до 1.

2) Отклонять ассоциацию/авторизацию при уровне ниже - если уровень ниже то при попытке ассоциации/авторизации, будет послан REJECT. Для ограничения подключения клиентов дальних клиентов стоит использовать режим отклонения ассоциации.

3) Игнорировать попытки ассоциации/авторизации при уровне ниже - если уровень ниже то вообще не отвечаем на попытки авторизации (стоит установить значительно ниже чем порог в поле отклонить что бы точка не отвлекалась на таких клиентов.

4) Не отвечать на probe запросы от клиентов с уровнем ниже, аналогично п3 только для probe reqest`s, т.е. точка не будет отвечать таким клиентам на запрос информации о ней и не будет на них отвлекаться.

5) Отключить активного клиента при уровне ниже - собственно отстрел клиента если RSSI при передачи DATA Frames от клиента падает ниже заданного уровня. Для клиентов в активном режиме (PSM Mode=Active)

6) Отключить клиента в режиме энергосбережения при уровне ниж - отстрел клиента если RSSI при передачи DATA Frames от клиента падает ниже заданного уровня. Для клиентов в режиме энэргосбережения (PSM Mode=PSM)

7) Интервал измерения уровней до принудительного отключения - интервал за который производиться изменрение уровней от клиентов для принятия решения об отстреле.

 

Немного о алгоритме отстрела. Раз в секунду берём средний RSSI по обоим стримам радиомодуля и сравниваем с пороговвым значением. Если уровнь ниже порога увеличиваем счётчик на единицу, если меньше порога сбрасываем счётчик. Т.е. если клиент на протяжении заданного времени ни разу не передал ни одного пакета с уровнем выше порогового то он будет сброшен с AP.

 

Простейший вариант настройки это задать острел по уровню например на уровне -70 (ну например при выходе из кабинета в корридор в типовом ЖБ здании), и запретить ассоциацию клиентам с уровнем ниже -50 (что обеспечит возможность подключиться новому клиенту только в прямой видимости находясь в кабинете). Игнорирование probe и assoc выставить в пределах -75 - -80 что бы не грузить точку ненужными запросами.

 

Таймаут до отстрела нужен что бы исключить ложные срабатывания логики отстрела клиентов на грани зоны покрытия. Т.е. свести на нет ситуацию когда клиент из-за слегка плавающего RSSI будет вылетать с АП, так же с помощью задержки можно подгонять логику под разные типы задач. Например при развёртывании точек внутри помещения без прямой видимости может потребоваться малое время для того что бы держать минимум клиентов с низкими уровнями на одной АП, с другой стороны на открытом воздухе где с любой точки нажхождения клиента есть прямая видимость на несколько АП с достаточно высоким уровнем стоит увеличить интервал что бы исключить ложные срабатывания, а так же снизить число постоянно мигрирующих без нужды клиентов.

 

Несколько нюансов:

1) если это публичная сеть то стоит включить изоляцию клиентов в опциях беспроводной сети

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

3) если шлюзом выступает устройство на wive и нужно максимально быстрое переключение нужно в настройках DHCP сервера шлюза отключить проверку занят ли адрес арпингом установив соответствующую опцию в 0, или уменьшить таймаут до пары мс. Т.к. адреса встроенный dhcp выдаёт с привязкой к хэшу мака конфликты адресов и так исключены (если не специальная подмена одним из клиентов)

4) дополнительно настроить IDS

5) что бы уравнять шансы миграции клиентов между 2.4->5 стоит понизать мощность передатчика на 2.4ГГц на 2Дб (70%)

6) так же имеет смысл уменьшить lease time до ~30 минут дабы экономить диапазон и не держать мёртвые записи слишком долго

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


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

К сожалению назвать это полноценным роумингом нельзя (ну на мой взгляд нельзя, большинство товарищей производителей именно такой вариант и называют бесшовным роумингом) т.к. нет поддержки 802.11R (работаем над этим). Но даже текущая реализация намного гибче того что предоставляет например Miсrotik (правда у них и ubnt так же нет поддержки 802.11R/K, и похоже шансов что будет так же не имеется =)))).

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


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

при переключении клиента между точками трафик рвётся или нет?

роуминг на базе программного контролера и точек ubiquiti UAP конкурирует с этим решением? нет ли совместимости роутера-контроллера SNR с точками ubiquiti UAP ну совершенно случайно ;)) возможно ли в принципе создать контроллер для точек ubiquiti UAP на аппаратуре этого роутера или какой-то другой? ;)

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


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

Оффтоп:

 

ubnt так же нет поддержки 802.11R/K, и похоже шансов что будет так же не имеется

802.11r поддерживается на юбнт.

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


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

Конкретнее какие варианты поддерживаются (да да их несколько), в каком именно железе поддерживаются и т.д. Всё что мне удалось найти это стоны на их форуме и форуме микротика датированные 2015м годом типа неплохо было бы и поддержать.

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


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

в ЭирОс всё на уровне hostapd.У uni-fi тоже что-то было, есно через cli вся настройка.

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


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

А ну всё ясно, т.е. только R и только как оно в hostapd, т.е. можно сказать не как. Короче правильно стонут у них на форуме.https://community.ubnt.com/t5/Upcoming-Products/802-11r-Fast-Roaming/td-p/238085/page/4

 

Как бы такие вещи должны быть на уровне ядра ибо речь и дёт о мили секундах независимо от нагрузки на AP. Насколько реализация 802.11K/R в hostapd (и какая версия в этом самом OS) валидна мне неизвестно.

 

В MT7620/MT7602/MT7612 поддержка 802.11K/R встроена в драйвер, сейчас закончим с хотспотами и сяду уже основательно разбираться с этим делом. Жаль правда что клиентов с поддержкой оных кот наплакал, но ситуация слава богу постепенно меняется.

 

Если не лень поделитесь личным опытом с циферками.

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


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

при переключении клиента между точками трафик рвётся или нет?

 

Это лежит на совести клиента. Если он решит дропнуть IP и таблицу трэкинга на своей стороне при миграции то порвётся, если нет то нет.

 

роуминг на базе программного контролера и точек ubiquiti UAP конкурирует с этим решением? нет ли совместимости роутера-контроллера SNR с точками ubiquiti UAP ну совершенно случайно ;)) возможно ли в принципе создать контроллер для точек ubiquiti UAP на аппаратуре этого роутера или какой-то другой? ;)

 

Задайте вопрос им. Тут пока нет никакого контроллера, как нет и пока fast transition. Уж точно я не ориентируюсь на "совместимость" с кем либо вне стандартов 802.11. На текущий момент всё что предоставляет текущая реализация это возможность равномерно распределить нагрузку и если что пнуть мертвечину или еле живых (по уровню и числу ошибок) клиентов что бы те приняли решение и реконнектились к ближайшей АП. Т.е. это ещё не полноценный роуминг, да и в 802.11 полноценный роуминг эт скорее фантастика т.к. всё зависит от клиентов (максимум что может сделать АП с подачки контроллера или самостоятельно это послать DEASSOC и надеяться что клиент в зависимости от ххххх реконнектиться к более "правильной" АП), а клиентов с поддержкой хотя бы 802.11R/K или тупо не дропающих параметры на интерфейсе при миграции кот наплакал.

 

В перспективе (возможно не очень близкой) появиться поддержка 802.11K/R т.е. fast transition и сотоварищи, возможно попутно ещё что-нить придумается что бы уменьшить хэндовер. Но пока вот так. С реализацией контроллера пока вообще всё глухо. Мы вдвоём явно чисто по времени не тянем заниматься всем и сразу. Выделят человека, нарисуем ему ТЗ и будет пилить.

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


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

Дальнейшие изыскания не тему кто из мобильных клиентов (не ноутбуков) и что умеет из стека 802.11K/R/V оказалось что ситуация грустная грустная.

 

Apple IOS поддерживает FT только с версии 6 и то не для всех девайсов и не все методы, требует посылки доп данных в части R вне стандарта. А полноценно весь стек умеет только IOS8 на новых совсем железках.

 

Android поддержка 802.11R включена в последних релизах 5й ветки работает ли - видимо сильно зависит от железа (как минимум на риалтэках и младших не AC BCM точно не будет работать). Поддержки K/V нет вовсе и не предвидиться. В Android M обещают дефолтовую поддержку как минимум R, но зная как чипмэйкеры лепят свои SDK для андроид (см тот же риалтэк) могу абсолютно точно сказать что работать оно не будет нигде кроме Atheros и старших BCM.

 

Blackberry - что-то умет, но судя по форумам работает косо вплоть до невозможности аутентифицироваться в сети до ребута если уснули и перешли на соседнюю АП.

 

Windows Phone - тут всё как обычно у МС, сама система нифига не делает всё делает сторонний софт и драйвер поверх куцего АПИ, а реализация целиком и полностью лежит на плечах производителя мелкосхемы. Как пример Nokia Lumia 920 которые вообще не могут приконнектиться к AP с включенной поддержкой FT (в т.ч. проверено с цисками и не только мной).

 

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

 

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

 

И вот так везде в 802.11. Все хорошие начинания разбиваются о подобные проблемы.

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


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

Начиная с 4.2.0 параметр KickStaRssiLow разбит на 2

1) KickStaRssiLow - уровень при котором отстреливать клиента находящегося в активном режиме

2) KickStaRssiLowPSM - уровень при котором отстреливать клиента находящегося в режиме энергосбережения

 

Смысл в том, что новые клиенты включая свежие Ipad/Google Nexus (с обновлениями ОС на клиентах думаю и многие старые начнуть себя вести аналогично) начали заметно (в среднем на 10Дб) ронять уровень при переходе в режим энергосбережения, что приводит к циклической долбёжке таких клиентов до АП на краю зоны покрытия при каждом засыпании (уснул - через некоторое время АП его отстрелила, клиент не думая попёрся на ту же АП зачастую даже без скана подняв уровень и снова вписавшись по ограничениям и так по кругу). Батарейка у этих клиентов улетает на глазах.

 

Пришлось разделить на два параметра.

 

Из рекомендаций по использованию. Задавайте уровень отстрела PSM клиентов на 10-20Дб ниже чем активных, или вообще не отстреливайте их. Время в эфире они почти не жрут, но вот ложных срабатываний будет заметно меньше. Я бы рекомендовал забить (для начала) уровень где-то -95 что бы просто логика сносила мертвичину и не ждала пока оно по таймауту отвалиться.

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


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

В 4.3.2 добавлен параметр "delta threshold rssi level for 5GHz band parametr for tune 5GHz band roaming". По умочанию равен -5db (есть смысл крутить в пределах -2..-15db).

 

Смысл в том что в 5ГГц затухание выше, но при этом диапазон заметно чище и для достижения нужного для работы на высших модуляциях SNR нужен меньший RSSI. Параметр позволяет задать дельту для параметров базирующихся на RSSI параметров. Например порог отстрела зададим как -90, а дельту -5. В результате для 2.4ГГц порог отстрела будет -90, для 5ГГц -95.

 

Это позволяет более полно утилизировать 5ГГц диапазон и снизить взаимное влияние между логикой хэндовера и band steering.

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


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

В перспективе (возможно не очень близкой) появиться поддержка 802.11K/R т.е. fast transition и сотоварищи, возможно попутно ещё что-нить придумается что бы уменьшить хэндовер. Но пока вот так

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

сколько по времени обычно занимает переключение?

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


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

Сейчас:

1) FT на 5ГГц работает полностью во всех режимах WPA2+FT-PSK/WPA Enterprise, в 2.4 тоже могу дать ПО с поддержкой, но всё ещё в процессе разбора полётов по одной мелкой баге (которую не факт что кто-то заметит)

2) Для WPA2 Enterprise поддерживаются все штатные механизмы кэширования ключа + преаутентификация для обоих диапазонов, тут вообще проблем нет

3) Принудительный хэндофф поддерживается для всех режимов, диапазонов, совместим с одновременной работой п1/п2

 

Встроенный Radius Server для быстрого развёртывания WPA Enterprise сети так же имеется.

 

Время переключения зависит напрямую от логики на стороне клиента (умеет/не умеет и как умеет из того что предоставляется АП) и тормознутости свитча в который собирается всё это дело.

 

При работающем FT/RRM или хотя бы кэширование ключей в схеме с WPA Enterprise на клиентах его полноценно поддерживающим время переключения чуть за 150мс. Всмысле радио переключается, дальше как свитч у себя арп табличку прокакает.

 

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

 

Ну и ложка дёгтя, что вот сейчас из офиса 22 АП и ~210 устройств (постоянно онлайн примерно 80-100) поддерживают хоть что-то из перечисленных ускорялок менее 20 (обычно однобэндовые клиенты вообще толком не умеют FT, а из относительно небольшого числа дуалбэндов умеет FT в лучшем случае 3ть). Т.е. как всегда всё упирается в поддержку со стороны клиентского железа.

 

Так что для них один фиг только "универсальный пинок и непускание". Проблем особо нет (ну кроме когда клиент на стадии подключения говорит что он весь из себя FT Support,а по факту крив как... Тут подставляю костыльки, реализации увы FT на клиентах все разной степени кривости). Так же работает Band Steering параллельно со всем этим, вот он вносит доп тормоза при первой миграции если клиент кривоват. Но без него грустно т.к. большая часть дуалбэндных клиентов не умеет режим 5GHz preffered.

 

Ну а посмотреть думаю если бываете в ЕКБ и напишите на wifi@nag.ru то позволят побегать по офису и пощупать своими руками (работает Band Steering, принудительный сброс, RRM, WPA2+FT-PSK для 5ГГц и WPA2-PSK для 2.4, офис = этаж ТЦ). Правда там ещё не всё доделано в связи с переездом.

 

Так же можете взять железо в тест, всё расскажут, помогут настроить. Если не понравиться вернёте да и всё.

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


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

Так для затравки (правда юзвери уже на обед да в курилку убегать начали =)... Красивому распихиванию юзверей по АП благодарны в первую очередь гибкой логике принудительного хэндофа и поддержке BandSteering. ;)

 

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

sample.jpg

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


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

Так для затравки (правда юзвери уже на обед да в курилку убегать начали =)... Красивому распихиванию юзверей по АП благодарны в первую очередь гибкой логике принудительного хэндофа и поддержке BandSteering. ;)

 

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

Что за софт изображен на данной картинке?

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


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

Наша система мониторинга которая пока активно пилится. Надеюсь к КРОС представим на всеобщее обозрение.

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


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

Наша система мониторинга которая пока активно пилится. Надеюсь к КРОС представим на всеобщее обозрение.

а можно ее как нибудь получить для теста?

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


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

Пока нет, но можно написать на wifi@nag.ru о своём желании побыть тестером. Планировали закрытое тестирование через некоторое время когда допилим то что есть и причешем, т.к. там пока аврал.

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


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

я правильно понимаю список действий:

1. даём всем точкам одинаковый SSID;

2. разносим по возможности по каналам, чтобы точки с перекрывающимися каналами не видели друг друга;

3. включаем WPA2 с одинаковым ключом

есть ли смысл в WPA2 Enterpise? (даёт ли он что-то именно с точки зрения скорости перключения?)

если есть возможность оставить сеть открытой - есть ли в этом какой-то резон?

4. включаем 802.11k/r (стоит ли?)

5. настраиваем параметры отстрела

Простейший вариант настройки это задать острел по уровню например на уровне -70 (ну например при выходе из кабинета в корридор в типовом ЖБ здании), и запретить ассоциацию клиентам с уровнем ниже -50 (что обеспечит возможность подключиться новому клиенту только в прямой видимости находясь в кабинете)

хм, получается, если нет точек, которые видят с уровнем выше -50, то клиент вообще не сможет подключиться к сети?

не логичнее ли поставить тут близкие значения?

 

 

Время переключения зависит напрямую от ... и тормознутости свитча в который собирается всё это дело.

а в самой точке свитч не тормозит с обновлением таблиц макадресов?

 

Наша система мониторинга

а где она крутится? отдельный linux-хост?

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


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

я правильно понимаю список действий:

1. даём всем точкам одинаковый SSID;

2. разносим по возможности по каналам, чтобы точки с перекрывающимися каналами не видели друг друга;

 

Вот тут часто ошибка. 2 точки в одном помещении работающие даже на 1 и 11м каналах с полосой в 40МГц будут очень не кисло какать друг другу в ухо и скорость (при активной передачи на обе АП) будет заметно ниже чем если бы их запихать на один канал (к сожалению логика динамического подключения/отключения широкой полосы работает далеко не на всех клиентах, а часто оной нет вовсе, что вынуждает АП всегда использовать широкий канал если он был заявлен на стадии согласования, есть или нет нужда в нём).

 

В 2.4ГГц у вас нет выбора. Либо использовать 40МГц полосу и ставить все АП на один канал что бы разбор полётов происходил уже на логическом уровне после декодирования, или разносить 2*20МГц 1-11 каналы (там ещё и небольшой защитный интервал получиться).

 

С точки зрения миграции лучше что бы АП были на одном канале, с точки зрения ёмкости сети (по числу клиентов) лучше разнести по каналам.

 

3. включаем WPA2 с одинаковым ключом

есть ли смысл в WPA2 Enterpise? (даёт ли он что-то именно с точки зрения скорости перключения?)

 

Если клиент его корректно умеет (включая OKC) то на однобэндах безусловно даст эффект в виде снижения времени переключения. Однобэнды у нас пока не умеют FT-PSK, а значит что бы снизить задержку придётся использовать WPA Enterprise. Весь вопрос в клиентах, и в необходимости оного.

 

если есть возможность оставить сеть открытой - есть ли в этом какой-то резон?

 

Шифровать обязательно. И обязательно WPA2.

 

4. включаем 802.11k/r (стоит ли?)

 

RRM включить обязательно. А FT в состав ПО для однобэндов не входит пока. Да и как показала практика клиентов FT-PSK умеющих эт полтора яблока и половина ведроида.

 

5. настраиваем параметры отстрела

не логичнее ли поставить тут близкие значения?

 

Эксперементируйте. Универсальности тут не добиться. Потому собсно и вынесена стопка крутилок, что бы можно было под практически любую инсталляцию оттюнить.

 

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

 

 

а в самой точке свитч не тормозит с обновлением таблиц макадресов?

 

Нет.

 

 

а где она крутится? отдельный linux-хост?

 

Да, отдельная *nix машинка. В неё закладывается гораздо больше чем мониторинг в перспективе. И ессно на точке она шевелиться уже не будет. Ибо ресурсов надо сильно больше чем может предоставить даже 7621.

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


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

С точки зрения миграции лучше что бы АП были на одном канале, с точки зрения ёмкости сети (по числу клиентов) лучше разнести по каналам.

любопытно, а как сделано у вас в офисе? (на картинке выше)

 

Шифровать обязательно. И обязательно WPA2.

а можно провести ликбез?

 

ещё стало любопытно, если включить 802.11k, то точка должна сказать клиенту куда он может коннектиться, так? а где она сама возьмёт этот список?

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


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

любопытно, а как сделано у вас в офисе? (на картинке выше)

 

2*20МГц местами по 2 АП в помещении, над рабочими зонами (помещения большие). Band Steering распихивает прилипал по диапазонам, правда слегка портя для оных миграцию. Те что умеют FT-PSK и 5ГГц вообще свободно мигрируют сами, им не мешаем и не пинаем и именно на них роумиться всё красиво. А с прилипалами, с криво анонсирующими свои возможности клиентами и т.д. приходиться заниматься распиныванием т.е. для них приоритетно будет не прозрачно мигрировать, а обеспечить работу на оптимальной АП и в оптимальном диапазоне.

 

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

 

Все эти проблемы вытекают из-за того бедлама, что устроил WiFi альянс не требующий для получения Logo обязательной поддержки хоть чего-то кроме совсем базовых вещей, отсюда столько клиентов которые ни сном ни духом ни о роуминге ни даже часто о wide channel и SGI. Да и архитектурно все эти K/R и т.д. выглядят как попытка исправить ошибки проектирования протокола не ломая совместимость. В общем в очередной раз грустно тут всё.

 

ещё стало любопытно, если включить 802.11k, то точка должна сказать клиенту куда он может коннектиться, так? а где она сама возьмёт этот список?

 

802.11k это набор фишек. В т.ч. TPC и прочие фигушки.

 

У нас нет сейчас полноценной реализации запросов list of neighbor APs. Просто потому что мне не удалось найти ни одного клиента оные вообще запрашивающего. От слова совсем. И все виденные мной клиенты выбирают куда цепляться исключительно исходя из собственной логике, ориентируясь по имени сети + параметрам шифрования конкретной АП и если повезёт с учётом mobile domain.

 

Потому даже заморачиваться не стал с реализацией для 2.4.

 

А данные о АП в сети гонять (как и запросы на миграцию и прочее) обычно гоняются по 802.11f (iapp).

 

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

 

Среди расширений 802.11 такое количество мертвичины не поддерживаемой толком клиентами, что диву даёшся. Мне жизни не хватит, что бы всё это реализовать со стороны АП. А уж без тестирования...

 

а можно провести ликбез?

 

На тему необходимости шифрования? Ну эт вроде и так ясно. А WPA2 + AES эт единственное что ещё не отломали. =) Да и просто нафиг вам нужно собирать всяких клиентов которые видя открытую АП будут цепляться к AP и АП будет вынуждена в т.ч. гйены крутить. Да и даже если они тупо висят почти молча всё равно отъедают эфирное время + учитываются rate alg что будет приводить к более пессимистичной оценке эфира и занижению рэйтов (не обладает точка интеллектом на эту тему, не может она отличить свой чужой без использования парольной фразы). Она ж не знает чужой это или свой. Зацепился - привет. И т.д. и т.п.

 

Плюс часть клиентов не смогут использовать HT и/или VHT или 40МГц канал если используется WEP/WPA1 или шифрования нет ("требование" альянса, на которое как обычно почти все забили, т.к. для сертификации не обязательно). Но это реже.

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


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

я в итоге так и не понял, по факту между точками ходит какой-то служебный трафик? если да - то какой?

 

2*20МГц местами по 2 АП в помещении, над рабочими зонами (помещения большие). Band Steering распихивает прилипал по диапазонам, правда слегка портя для оных миграцию

речь про выталкивание в 5ГГц? а в 2.4 все точки на одном канале?

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


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

я в итоге так и не понял, по факту между точками ходит какой-то служебный трафик? если да - то какой?

 

В вашем случае (однобэнды) не ходят. Грю же нет для однобэндов реализации FT в текущей стабильной ветке (будет позже как только удастья полечить одну багу в dev ветке драйвера для 76x2/7620). Для дуалов там бегает нотификация АП о миграции клиентов через iapp (802.11f). Интересно подробнее - см код.

 

речь про выталкивание в 5ГГц? а в 2.4 все точки на одном канале?

 

Я же написал 2 канала по 20МГц в 2.4 (1/11). В 5ГГц так же 2 сети но по 40МГц (36/64). 40МГц выставлено из-за баги в яблофонах с BCM радио при работе в 80МГц (см рекомендации в соседних темах, там и линки есть по проблеме) плюс позволяет иметь достаточный защитный интервал между частотами на которых работают АП в одном помещении.

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


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

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

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

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

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


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

Войти

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


Войти