The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Раздел полезных советов: Бесшовная миграция (роуминг) Wi-Fi ..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Бесшовная миграция (роуминг) Wi-Fi ..."  +/
Сообщение от auto_tips (ok) on 26-Фев-18, 12:59 
С wpa_supplicant из GIT теперь можно настроить в Linux прозрачную миграцию, позволяющую переключиться на другую точку доступа без разрыва соединений приложений, в том числе продолжается вещание мультикастовоего IPTV, а выполнение iperf в большинстве случаев не умирает, а лишь деградирует по скорости в момент миграции. При этом даже корректно отрабатывает вариант с несколькими AP в разных поддиапазонах 5ГГц.

Для настройки роуминга потребуется (на примере Mageia Linux 5):

1) wpa_supplicant из git. Можно взять подготовленный автором src.rpm

    wget http://wive-ng.sf.net/downloads/wpa_supplicant-2.6-1.mga5.sr...

и собрать командой

   rpmbuild --rebuild wpa_supplicant-2.6-1.mga5.src.rpm

2) переключить его на использование nl80211 вместо wext, драйвер вашего wifi-модуля должен полностью поддерживать nl80211 (при использовании wext всегда будут долгие периоды реконнекта с потерей соединений пользовательских приложений) так как требуется, чтобы SME был на уровне wpa_supplicant.

Большинство дистрибутивов по умолчанию использует WEXT, т.е. до сих пор далеко не все драйверы wifi, даже входящие в состав ядра, умеют nl80211 (iwlwifi точно умеют, ath*k тоже должны, в rt28xxx  по факту даже сканирование не работает). Проверить, что используется на данный момент, можно, посмотрев, с какими опциями запущен supplicant

   ps ax | grep wpa_supplicant

должен выдать что-то типа

   25201 ? Ss 0:01 /usr/sbin/wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf -D nl80211 -f /var/log/wpa_supplicant.log

Для этого редактируем /etc/sysconfig/network-scripts/ifcfg-имя_интерфейса

Важно установить:

   WIRELESS_WPA_DRIVER=nl80211
   WIRELESS_WPA_REASSOCIATE=no
   MII_NOT_SUPPORTED=yes
   USERCTL=yes

В /etc/wpa_supplicant.conf везде отключаем рандомизацию MAC. Включаем фоновое сканирование:

   bgscan="simple:30:-60:200"

Т.е. при уровне ниже -60 будем начинать время от времени "щупать эфир" на предмет наличия кандидатов для миграции и по возможности мигрировать. Вместо фонового сканирования можно было бы использовать данные из RRM, но этой логики в wpa_supplicant пока нет.


Также следует обратить внимание на используемый DHCP-клиент. Важно, чтобы он не сбрасывал адрес на интерфейсе (иначе сбросится состояние соединений приложений) по сигналу от ifplugd. Я использую штатный "
"Internet Systems Consortium DHCP Client 4.3.3-P1". Ну и естественно, точки доступа и опорная сеть должны нормально отрабатывать ситуацию с перемещением клиентов.

В прошивке Wive-NG для этого сделано абсолютно всё, что возможно. Больше ничего не требуется. Проверено на адаптерах Intel I3160/I7260. Выпинывать их принудительно не надо - оно само инициирует переход без всяких проблем. Под Windows эти карты ведут себя аналогично, т.е. без проблем мигрируют с сохранением пользовательских соединений, достаточно лишь в настройках драйвера увеличить агрессивность роуминга.


++ Настройка миграции Android-устройств с беспроводными чипами от Atheros/Qualcomm.


Достаточно давно atheros/qualcomm добавили в свои драйверы вполне внятную логику handover (миграции внутри плоской L2 сети, с точки зрения клиента,  с множественными AP, на которых установлен один SSID). Собственно, тот самый роуминг, да ещё и бесшовный (ну если используемые AP не совсем плохи и умеют моментально передавать в опорную сеть критичные данные, например, ARP-ы для обновления ARP-таблиц на устройствах в сети + ещё ряд условий на тему кривости).

Теперь о проблеме. Handover есть, сеть с нормальными AP есть, но чтобы клиент мигрировал, по-прежнему требуется пинок, иначе висит до последнего... Что делать и кто виноват?

Для продолжения нужно само устройство, обязательно рутованное, обязательно использующее радио на чипе qualcomm (например yota phone 2).

Перемонтируем разделы в RW, идём в /system/etc/wifi, видим там файл WCNSS_qcom_cfg.ini - собственно, это основной конфигурационный файл, читаемый драйвером wifi.

Драйверы QCA сами реализуют слои SME/MLME, не экспортируя эти функции на плечи wpa_supplicant. И вся логика управления подключениями и миграцией возложена на них. Wpa_supplicant в Android собран с NO_ROAMING, а значит можно ожидать, что это сделано так же у всех абсолютно чипмэйкеров для Android (файлы конфигурации, естественно, разные, или же, как у Broadcom, интересующие нас параметры к исправлению задаются при компиляции, и изменить их на лету невозможно).

Первая настройка, которая нас будет интересовать в файле конфигурации, это:

   # default value of this parameter is zero to enable dynamic threshold allocation
   # to set static roming threshold uncomment below parameter and set vaule

   gNeighborLookupThreshold=78

Эта настройка напрямую отвечает за то, когда клиент начнёт пытаться искать кандидата (форсирует сканирование, или запросит список ближайших AP по RRM и проведёт короткую процедуру скана для подтверждения).  И значение у нас выставлено -78дБ...

И вроде бы всё хорошо, но... Мы как обычно забыли, что то, что слышит клиент и то, что слышит AP, может отличаться по уровню на десятки дБ. Обычно в android-клиентах передатчик в 20МГц полосе может выдать 16дБм, в 40МГц в лучшем случае 14дБм. Тогда как со стороны AP обычно имеем как минимум 20дБм дури даже в 40МГц полосе (обычно определяется законодательными ограничениями конкретной страны, для РФ 20дБм в 2.4ГГц и 23дБм в 5ГГц независимо от ширины, хоть в 80МГц эти 23дБм, хоть в 20МГц). Из опыта, при таком раскладе в среднем перекос по уровням в прямой видимости уже в 10 метрах будет составлять около 10-15 Дб, а если есть преграды, то запросто перевалит и за 30 Дб.

Но возьмём 10дБ для простоты. Т.е. когда клиент видит AP с уровнем в -78дБ, AP видит клиента уже с уровнем около -88дБ. Стоит говорить, что нормальной работы при таком раскладе уже не будет (особенно в 2.4ГГц в зашумленном эфире офиса)? TCP, требующий подтверждения доставки, просто встанет колом, голос начнёт квакать и т.д.

Что бы этого избежать (плюс приземлить побольше клиентов, ведь для этого надо заставить всех работать на самой ближней AP, желательно с максимальными рэйтами и без повторов передачи), админ в сети наверняка на AP настроил handoff с уровнем эдак в -75дБ. Т.е. при -75дБ RSSI handoff со стороны AP застрелит такого клиента (при этом на клиенте уровень от AP будет аж -65дБ, т.е. далеко до заветных -78дБ, когда он решит подумать мигрировать). Т.е. будет link beat, сброс стэйтов и обрыв соединений на пользовательской стороне.

Ещё пример - когда AP видит клиента с уровнем в -75дБ, клиент видит AP с уровнем -65дБ!! Или, когда на клиенте видим -78дБ, то со стороны AP клиент будет слышен лишь с  уровнем -88дБ.

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

Или же нам придётся снижать мощность на AP что бы "уравнять" шансы, что в условиях грязного эфира может привести к катастрофическому падению SNR и как следствие бульканью, хрипам и прочему.

А вот чтобы этого не происходило, достаточно выше обозначенную переменную поправить, выставив значение в диапазоне -65 ~ -70дБ.

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

Следующий блок:

   # CCX Support and fast transition

   CcxEnabled=0
   FastTransitionEnabled=1


CcxEnabled - это поддержка rrm ccx location-measurement, т.е. определения местоположения. Зачастую бесполезна и лишь будет расходовать аккумулятор.

FastTransitionEnabled - поддержка 802.11R, однако в старых драйверах не полная, но хотя бы умеет учитывать MDIE при миграции (работает всегда, если переменная в значении 1). Заметим, что FT, а именно ускорение фазы аутентификации просто при взводе значения переменной в 1 работать не начнёт, так как требуется ещё пропатчить Supplicant  и обвязку андроидную (как это делает, например, Samsung в своих топовых моделях). Однако, учёт MDIE - уже польза. Включаем.

Не забываем также отключить 802.11d,  иначе встретим много чудес в 5ГГц с DFS каналами. Пусть использование или не использование оных лежит на совести админа сети.

   # 802.11d support

   g11dSupportEnabled=0

Далее блок:

   # Legacy (non-CCX, non-802.11r) Fast Roaming Support
   # To enable, set FastRoamEnabled=1
   # To disable, set FastRoamEnabled=0

   FastRoamEnabled=1

Включает возможность миграции в любых сетях. Иначе, логика  handover будет активироваться, только если клиент видит, что AP вещает поддержку 802.11R в IECAP. И/или используется WPA*-Enterprise.


В новых драйверах, поставляемых в SDK для Android 6.0.1, добавлена ещё одна прекрасная опция:

   # Handoff Enable(1) Disable(0)

   gEnableHandoff=0

Эта опция (если выставить в 1) позволяет обрабатывать handoff с пинком со стороны AP как сигнал к миграции, т.е. банально не генерируется LinkBeat при kickout со стороны AP, а сразу выполняется попытка перескочить на следующую подходящую выбранную сканом AP, и только если не получилось сгенерировать Link Beat системе (т.е. о том, что его выпнули, знает только драйвер, и сразу пытается мигрировать, если не получается, то тогда уже сообщает системе, что всё, связи с этой сетью больше нет, надо выбрать другой SSID из тех, которые знает Android).

Пользовательские соединения при этом останутся целыми (ну разве что iperf пострадает, но мессенджеры и голос останутся работать, правда в случае голоса будет квак).

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

А вот ещё одна крайне полезная настройка:

   #Check if the AP to which we are roaming is better than current AP in terms of RSSI.
   #Checking is disabled if set to Zero.Otherwise it will use this value as to how better
   #the RSSI of the new/roamable AP should be for roaming

   RoamRssiDiff=5

Дельта уровней между AP для выбора кандидата при миграции. Больше значение - меньше вероятность прилететь назад на ту же AP, но более отложенный старт миграции. Установленных по умолчанию 5дБ  маловато. Нужно иметь дельту около 8-10дБ. Для начала выставим 8.

   RoamRssiDiff=8

Ещё интересная штука:

   #Beacon Early Termination (1 = enable the BET feature, 0 = disable)
enableBeaconEarlyTermination=1

   beaconEarlyTerminationWakeInterval=11

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

   gActiveMaxChannelTime=60
   gActiveMinChannelTime=30
   gActiveMaxChannelTimeConc=60
   gActiveMinChannelTimeConc=30

Настройки времени прослушивания эфира при активном сканировании поканально, в мс. Больше значения - больше времени уйдёт на сканирование всего диапазона. Меньше время - быстрее просканируем, но можем половину не услышать.

RRM включается так:

   # 802.11K support
   gRrmEnable=1
   gRrmOperChanMax=8
   gRrmNonOperChanMax=8
   gRrmRandIntvl=100

Правда, я на доступных мне железках (в смысле, на тех, в которых было выключено и включил, на SGS A5 2017 запросы есть, но там и так всё с миграцией более-менее) так и не дождался ни одного запроса с использованием RRM от Yota Phone. Видимо, отключена поддержка при сборке драйвера.

Это основное, что касается миграции.

Да и ещё:

   # 1: Enable standby, 2: Enable Deep sleep, 3: Enable Mcast/Bcast Filter
   gEnableSuspend=3

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

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

Ну и на закуску:

   #Channel Bonding
   gChannelBondingMode24GHz=1
   gChannelBondingMode5GHz=1
   gShortGI20Mhz=1
   gShortGI40Mhz=1

Поддержка широких каналов (>20МГц) + поддержка SGI. Зачастую для 2.4ГГц поддержка 40МГц отключена, т.е. gChannelBondingMode24GHz установлен в 0. Что, во-первых, не позволяет работать на максимальных рэйтах (150Мбит/с для 1T1R в 2.4ГГц при 40МГц, будет только 72). Увы, проблема в том, что видимо для первого соединения значение перекрывается откуда-то ещё, и даже выставив gChannelBondingMode24GHz=1, сразу мы 150Мбит/с не видит. Но после первой же миграции драйвер плюёт на всех и взлетает в 40МГц полосе.

Также установка gChannelBondingMode24GHz решает проблему совместимости с некоторыми 2.4ГГц AP на Xiaomi и One+ (как обычно, намутили с анонсами в зависимости от региона, в итоге AP и клиент не могут договориться, в какой полосе разговаривать).

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


URL: https://wi-cat.ru/2018/02/17/besshovnaya-migraciya-rouming-w.../ https://wi-cat.ru/2018/02/17/besshovnaya-migraciya-rouming-w.../
Обсуждается: http://www.opennet.me/tips/info/3051.shtml

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по ответам | RSS]

1. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от LeNiN (ok) on 26-Фев-18, 12:59 
@sfstudio, спасибо большое!
А если сделать настройки из вашей статьи только на роутерах — как будут вести себя клиенты?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от sfstudio email(ok) on 26-Фев-18, 14:29 
Процедуру хэндовера в 802.11 инициирует клиент. Со стороны АП его разве что сбить можно послав deauth. Что почти всегда будет приводить к потери соединений приложениями на клиентах (такова уж реализация).

Со стороны AP это делать точно бесполезно от слова совсем.Это клиентская логика. ;)

Я начал писать цикл статей на эту тему пытаясь объяснить простым языком как это всё работает без всякого интырпрайзного лапшенавешивания.

Пока дошёл только до 3х статей, пояснив некоторые аспекты L1 части. Со временем тяжко. Но буду потихоньку дополнять.

Следите за соответсвующим разделом у нас на сайте https://wi-cat.ru/tag/roaming/

За корректность миграции с 802.11 на 99% отвечает клиент. От АП требуется совсем не много. А всякие FT/RRM так и вовсе не обязательны и мало кто оных умеет из реальных клиентов.

Когда и для чего нужны RRM/FT я уже затронул кратко в статьях.

Читайте и потихоньку разберётесь.

Так же (в самом конце) разберу такую штуку как безроуминговая сеть, аля ZeroHandoff.

Репосты с линками приветствуются. =)

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от sfstudio email(ok) on 26-Фев-18, 14:35 
Редактор зачем-то поправил текст так что, смысл несколько съехал.

Видимо подумал, что слово "пинок" это я придумал.

Нет, это штатная терминология. Процедура деаутентификации с reason code STA_LEAVE называется kickout (спинывать). И т.д.

Это устоявшаяся в 802.11 терминология.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от Maxim Chirkov email(ok) on 26-Фев-18, 18:31 
"Пинки" я не трогал, на первый взгляд все на месте. Заменил только "прилетит по голове" на "отсоединит".
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +1 +/
Сообщение от sfstudio email(ok) on 26-Фев-18, 18:36 
> "Пинки" я не трогал, на первый взгляд все на месте. Заменил только
> "прилетит по голове" на "отсоединит".

Ок, ок. =)))

Но в данном случае именно прилетит по голове. Ибо отсоединит это зело мягко. Там натурально выпнет с АП, нагло и безжалостно и будь что будет. В этом и соль.

Нет в 802.11 нормальных механизмов мягко попросить уйти, можно только в голову пнуть =)

Стопка reason code заложенных в этот типа стандарт, не реализуется ни кем, даже циской. А говорить о клиентах вообще не приходиться.

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

Вот такой вот бубльгум.

802.11k/r так же не содержат механизмов для мягких уговоров.

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

При этом RRM так же обычно не реализован на клиентах или реализован лишь частично.

Основной профит от него это сокращение фазы сканирования. Ибо можно просто у текущей ап узнать хотя бы список АП и каналы на которых они работают и не тратить время на сканирование всех диапазонов, что может занимать больше 5 секунд для дуалбэнд клиентов запросто. В случае же со схемой с RRM мы должны потратить всего порядка 20мс что бы послать broadcast probe на уже известном нам из данных от АП канале. 5с vs 20мс. ;) Но блин всё упирается опять таки что даже клиенты умеющие RRM далеко не всегда предсказуемо работают с этими данными, а уж спросит или не спросит данные у RRM зависит от погоды на марсе.

В общем усё есть у нас на сайте, и будет дополняться со временем.

Я откровенно устал за последние 1,5 года столько железок (клиентов) проанализировал, можно энциклопедию издавать.

P.S. Как ни странно, но что касается имено корректного handover то максимально правильно оно реализовано в яблофонах старше 6го поколения на последних версиях IOS. В мире Android близко к ним подобрались топовые и полутоповые самсунги, но они регулярно что-то ломают в радио, и после каждого обновления поведение меняется.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от Maxim Chirkov email(ok) on 26-Фев-18, 18:52 
> Но в данном случае именно прилетит по голове. Ибо отсоединит это зело мягко. Там натурально выпнет с АП, нагло и безжалостно и будь что будет. В этом и соль.

Для целостности терминологии заменил на "выпнет". "Прилетит по голове" со стороны вообще не понятно о чем речь.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от sfstudio email(ok) on 26-Фев-18, 18:57 
Ну скорее не для целостности. Просто придумать чем заменить длииинное объяснение на простое, наглядное и красочное словосочетание не очень просто... =)

Цель именно уйти от углубления в матчасть, а описать общее удручающее состояние дел в части миграции в wi-fi максимально простым языком. Хотя ситуация меняется, и даже программу сертификации альянс запустил. Через годик посмотрим на результат.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от Аноним (??) on 27-Фев-18, 21:18 
И если все сделать как описано тут, то
1) Будет работать с полутора прошивками полутора устройств. После дикой камасутры.
2) Работать будет очень так себе, потому что -60 Дб мобильные устройств видят только если их на роутер положить. Можно конечно прыгать как белка с базы на базу, но результатом станут лаги в передаче данных и жор батарейки.
3) Приваси отправляется в пешее эротическое и сливается до уровня хуже чем у эппловских зондов в ипхоне.
4) Агрессивно сватается какая-то убогая прошивка вместо удобного и фичастого openwrt. Нет бы туда запилить.

То-есть оно как бы прикольно с точки зрения "во как я могу" но для домашнего применения это много камасутры с неочевидным результатом. Рецепт с фольгой из соседнего совета в 1000 раз проще, не накладывает ограничений на прошивки/устройства и неизбежно приводит к результату, поскольку потоки энергии заворачиваются в нужные стороны и SNR улучшается. Ах да, автор почему-то забыл сообщить что уровни сигналов - ни о чем. Куда важнее SNR линка, но про это почему-то ни гу-гу :). А корпоративщиков нужда рутовать телефоны и перенастраивать дрова врядли устроит вообще.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +1 +/
Сообщение от sfstudio email(ok) on 27-Фев-18, 21:38 
> И если все сделать как описано тут, то
> 1) Будет работать с полутора прошивками полутора устройств. После дикой камасутры.
> 2) Работать будет очень так себе, потому что -60 Дб мобильные устройств
> видят только если их на роутер положить.

Работать будет прекрасно, не для всех да. Эт что у вас за ... то такое в роли АП и клиента? =)) -60 если положить. -60 на SGS A5 + SNR-CPE-ME1 в 5ГГц за 40см стенкой из пеноблоков. Радио калибровано в нём чётко под наше законодательство 23dBm, в 2.4ГГц 20dBm, опять таки законодательные ограничения.

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

Никаких лагов. Никаких левых прыжков.

> 3) Приваси отправляется в пешее эротическое и сливается до уровня хуже чем
> у эппловских зондов в ипхоне.

У эйпловских и других зондов ровно та же самая реализация только от броадкома. Вот разборы критериев от циски, там и яблоки и прочее https://www.cisco.com/c/en/us/td/docs/wireless/controller/te...

> 4) Агрессивно сватается какая-то убогая прошивка вместо удобного и фичастого openwrt. Нет
> бы туда запилить.

Берите и пилите. Я 10ть лет работаю над Wive и на WRT не тянет. Вам ничего не сватается, это статья с моего ресурса по wive.

> То-есть оно как бы прикольно с точки зрения "во как я могу"
> но для домашнего применения это много камасутры с неочевидным результатом. Рецепт
> с фольгой из соседнего совета в 1000 раз проще,

Можно узнать причём тут домашнее использование?

не накладывает
> ограничений на прошивки/устройства и неизбежно приводит к результату, поскольку потоки
> энергии заворачиваются в нужные стороны и SNR улучшается. Ах да, автор
> почему-то забыл сообщить что уровни сигналов - ни о чем. Куда
> важнее SNR линка, но про это почему-то ни гу-гу :).

Потому, что вся логика handover в клиентах завязана именно на RSSI. А т.к. речь идёт о handover и рассматриваются его критерии, то и оперируем RSSI.

Это лишь заметка и не более.

> А корпоративщиков нужда рутовать телефоны и перенастраивать дрова врядли устроит вообще.

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

Благо все аппараты одинаковые и процесс проходит быстро и безболезненно.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  –1 +/
Сообщение от Аноним (??) on 28-Фев-18, 03:26 
> Работать будет прекрасно, не для всех да.

Вот я и пытаюсь прикинуть на сколько инсталляций вас хватит до того как вы забодаетесь :)

> Эт что у вас за ... то такое в роли АП и клиента? =)) -60 если
> положить. -60 на SGS A5 + SNR-CPE-ME1 в 5ГГц за 40см

Это обычный смарт на андроиде и все что угодно в роли роутера. У них антенны поганые, а если в руках держать не 2 пальчиками, руки будут прилично экранировать. 5ГГц к тому же умеет полтора устройства, так что радости от них.

> 23dBm, в 2.4ГГц 20dBm, опять таки законодательные ограничения.

Длинки-тплинки на это дружно кладут :). Рекорд того что я видел 27dBm @ 2.4GHz с фабричной прошивкой. Оно нормально прошибает, но даже так -60 на смартфоне будет не сказать что далеко.

> Никаких лагов. Никаких левых прыжков.

При хотелке в -60? Мне просто интересно откуда именно такая цифирь взята? Я практикую прогулки с замерами уровней на смарте и не скажу что часто вижу именно такие цифры, хоть в чьей инфраструктуре.

> У эйпловских и других зондов ровно та же самая реализация только от броадкома.

В обычной инфраструктуре даже ипхоны маки рандомизируют худо-бедно.

> Вот разборы критериев от циски, там и яблоки и прочее

Я что-то такое уже давно видел, сейлзы от цыски рассказывали. Даже всякий гламур с heatmap показывали. По своему прикольно.

> Берите и пилите. Я 10ть лет работаю над Wive и на WRT не тянет.

RO файлуха, отсутствие нормального пакетного менеджмента и прочие ядра эпохи молодости моей бабушки очень так себе радость для технарей. В опенврт этого нет, что выгодно отличает оный для технарей от хлама для хомячков. А пилите... я пока не понял надо ли мне оно так. Патчить все телефоны в округе я морально не готов. Переделываться в интегратора этого направления - вроде бы тоже.

> Можно узнать причём тут домашнее использование?

Вот я и пытаюсь прикинуть как это использовать на практике предлагается. А, кажется понял, не хватает тега РЕКЛАМА посту :). Видимо подразумевается что надо купить у вас правильные роутеры и возможно еще услуги патчинга девайсов.

> Потому, что вся логика handover в клиентах завязана именно на RSSI. А
> т.к. речь идёт о handover и рассматриваются его критерии, то и оперируем RSSI.

С точки зрения оптимизации линка имело бы смысл что-то типа анализа SNR и миграция с учетом оного и накопления статистики. Примерно как минстрел делает с разными скоростями и собирает статистику потерь пакетов. При этом учитывается все что можно, в том числе и SNR.

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

Забавная история. Но реально для сильно некоторых инсталляций :)

> Благо все аппараты одинаковые и процесс проходит быстро и безболезненно.

Да понятно, если их дофига - обкатаете технологию, потом накатаете какую-нибудь автоматизацию флешовки. Я на самом деле сам так немного развлекаюсь но не с уклоном в вайфай :)

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от Аноним (??) on 28-Фев-18, 03:36 
> Так же (в самом конце) разберу такую штуку как безроуминговая сеть, аля ZeroHandoff.

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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

12. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от sfstudio email(ok) on 28-Фев-18, 03:58 
> Вот я и пытаюсь прикинуть на сколько инсталляций вас хватит до того
> как вы забодаетесь :)

Я не занимаюсь инсталляциями. Я занимаюсь разработкой софта для АП. И волей не волей столкнулся с тем, что если говорить о миграции, нужно говорить о клиентах


> Это обычный смарт на андроиде и все что угодно в роли роутера.
> У них антенны поганые, а если в руках держать не 2
> пальчиками, руки будут прилично экранировать. 5ГГц к тому же умеет полтора
> устройства, так что радости от них.

Опять обычный порошок? Чем YP2 и SGS5 не обычные?


> Длинки-тплинки на это дружно кладут :). Рекорд того что я видел 27dBm
> @ 2.4GHz с фабричной прошивкой. Оно нормально прошибает, но даже так
> -60 на смартфоне будет не сказать что далеко.

Куда они кладут? Если бюджетные чипы в них с интегрированным FEM могут 64мВт то хоть убейся. Только что штыри ставить с более высоким Ку. Что будет с диаграммой объяснять надо?


> При хотелке в -60? Мне просто интересно откуда именно такая цифирь взята?
> Я практикую прогулки с замерами уровней на смарте и не скажу
> что часто вижу именно такие цифры, хоть в чьей инфраструктуре

Дык вы для смарта видите или для ноута? =) -60 это цифра для I7620 в его попугаях. Та же цифра для i3160. Причём эти цифры это не когда он должен в обязаловку спрыгнуть, а когда должен форсировать сканирование как минимум и быть готовым к прыжку.

Думаю не нужно объяснять, что показометры далеки от реальных значений? Не поверите, но в силу специфики работы у меня так же есть доступ и к безэховым камерам, есть наборы эталонных антенн и спектрик умеющий в т.ч. IQ.

> В обычной инфраструктуре даже ипхоны маки рандомизируют худо-бедно.

Как только они видят включенный 802.11r или 802.1x (wpa_enterprise) всю рандомизацию как языком слизывает. Учитывая, что рандомизация напрочь ломает band steering (костыль костылём как гриться) и т.д.

FT туда же пойдёт если кроме broadcast probe будет хоть что-то ещё рандомизировано. И ock и preauth и pmk cache даже отвалиться. В 802.11 почти всё завязано на MAC.


> Я что-то такое уже давно видел, сейлзы от цыски рассказывали. Даже всякий
> гламур с heatmap показывали. По своему прикольно.

По своему бредово.

> RO файлуха, отсутствие нормального пакетного менеджмента и прочие ядра эпохи молодости
> моей бабушки очень так себе радость для технарей. В опенврт этого
> нет, что выгодно отличает оный для технарей от хлама для хомячков.

А ещё нет нормальной поддержки оффлоадов и прочего. Удачи. Более того, раздел RWFS никто не отменял, а всю ось в RW держать эт простите.

> А пилите... я пока не понял надо ли мне оно так.

Ну я вас вроде и не принуждаю. Ваш выбор - ваше право. Я делаю для себя и своих заказчиков. Вы можете пилить что угодно. Мне WRT не нравиться, причины в очередной раз разжовывать лень. Однако это не мешает ни мне не им затягивать правки.

Например фикс запуска WRT на RT305x с SPI флэшемпришёл из Wive.

Мы (wive/wrt/etc) живём совместно, и каждый делаем то, что считаем нужным и интересным. Время от времени контактируем и даже наработки время от времени кочую туда-сюда.

Не кажется вам, что мой выбор - моё право? И я его сделал не случайно? Вот на этом и закончим. Как-то не я никого с WRT не переманиваю на wive, да и WRTшники не занимаются подобным в обратную сторону. Мы просто живём и работаем, делаем то, что полезно и интересно. Чего и вам желаю.

> Патчить все телефоны в округе я морально не готов. Переделываться в
> интегратора этого направления - вроде бы тоже.

Ну вот и я не интегратор, и тоже ничего не патчу. Однако мне пришлось расколупывать от и до логику миграции на клиентах. Могу рассказать как score считаются при выборе, тоже хитро. Не дошёл ещё до этого.

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

Реализовывал бы я клиентскую часть - исходил бы из обратного.

Был бы я wi-fi альянсом - прекратил бы этот разброд и шатания из-за отсутствия внятных требований к реализации, да и вообще отсутствие требования реализации большей части стека протоколов 802.11 для получения лэйбы.

Не говоря уже о том, что нагорожена куча всякой непотребщины, вместо банальных решений аля rssi feedback который так и умер в застенках, ибо не кому было пролоббировать. На его место в 802.11k появился link margin на который все срут ибо для сертификации не требуется.

Вот проблемы... А не то, что кто-то разрабатывает WRT, а кто-то Wive... И т.д.

> Вот я и пытаюсь прикинуть как это использовать на практике предлагается.

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

И не говоря уже про то, что сделано через Ж, так даже крутилки не вынесены.


> кажется понял, не хватает тега РЕКЛАМА посту :). Видимо подразумевается что
> надо купить у вас правильные роутеры и возможно еще услуги патчинга
> девайсов.

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

> С точки зрения оптимизации линка имело бы смысл что-то типа анализа SNR
> и миграция с учетом оного и накопления статистики. Примерно как минстрел
> делает с разными скоростями и собирает статистику потерь пакетов. При этом
> учитывается все что можно, в том числе и SNR.

Вы очень далеки от реальности. =)

> Забавная история. Но реально для сильно некоторых инсталляций :)

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


> Да понятно, если их дофига - обкатаете технологию, потом накатаете какую-нибудь автоматизацию
> флешовки. Я на самом деле сам так немного развлекаюсь но не
> с уклоном в вайфай :)

Мне то зачем обкатывать? Моя задача была на стороне АП реализовать поддержку для нормальных клиентов + костыли в виде handoff для залипал. Попутно выяснилось много интересного включая то, что сертифицированные по вышеупомянутой процедуре девайсы и не сертифицированные по сути отличаются конфигом. Причём одной строчкой. -78 для старта сбора данных и привентивного подбора кандидатов для миграции и -70. Где и какой порог выставлен догадайтесь сами.

В остальном (судя по objbdump) дрова и суппликант собраны с одним и тем же набором опций.

Проблема миграции (и не только) в 802.11 лежит в раздолбайском отношении альянса, который вместо контроля и выработки требований, занимается сшибанием бабла и лёгким движением руки может например превратить 802.11ac draft 1 в 802.11ac wave-1, 802.11ac draft 2 в wave-2, а draft/wave 3 выкатить уже как 802.11ax. Хотя весь набор фич ax был запланирован к реализации в AC. Но жажда бабла...

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

13. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +1 +/
Сообщение от sfstudio email(ok) on 28-Фев-18, 04:15 
>> Так же (в самом конце) разберу такую штуку как безроуминговая сеть, аля ZeroHandoff.
> С такими аппетитами напрашивается сразу что-то типа mesh, но в батарейных устройствах
> батарейка таки долго не протянет...

Каким местом тут ваши меши??? Куда вам оно напрашивается и какое из слов в моём посте побудило вас вспомнить про mesh? Причём какой меш? Меш который меш в виде бэтмена и иже с ними, или меш который в зебрах, камбиумах и прочих типа ынтырпразах, который по сути является WDS на стероидах?

Ай. Тут точно говорить не о чем.ZH и его предшественники решали именно проблему того, что все решения в 802.11 на тему миграции принимает клиент, и нет механизмов кроме грубого пинка их принудить к чему-то.

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

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

Т.е. применимость в условиях реального офиса, где на каждого сотрудника по 3-4 девайса, а таких сотрудников за сотню...

Меш это вообще не из этой оперы и близко не нать для решения подобных задач + меш в закрытом помещении при CSMA на доступе будет иметь море проблем, а эфир будет использован максимально не эффективно.

Напомнить как реализуется доступ к среде передачи в 802.11? =)))

Вот простите, работать надо. Следите за публикациями, может и этот момент раскрою.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

14. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от Andrey email(??) on 01-Мрт-18, 12:37 
А на SGS 7 на snapdragon (американец) нет такого файла WCNSS_qcom_cfg.ini по указанному пути /system/etc/wifi
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от sfstudio email(ok) on 01-Мрт-18, 14:48 
> А на SGS 7 на snapdragon (американец) нет такого файла WCNSS_qcom_cfg.ini по
> указанному пути /system/etc/wifi

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

16. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от Andrey email(??) on 01-Мрт-18, 15:32 
Samsung 1316S7 Wi-Fi Module
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

17. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от sfstudio email(ok) on 01-Мрт-18, 15:38 
> Samsung 1316S7 Wi-Fi Module

Ну так и я умею. =))) Вот только это ни о чём не говорит.

Самсунг сам не делает 802.11 модулей, закупает оное у Murata, внутри модулей чаще всего что-то на чипах BCM или QCA. Вот что внутри модуля тут, вот это надо знать.

В BCM параметры handover не вынесены в конфиг который можно править по факту. Всё задаётся на стадии сборки.

Я допускаю, что там может быть что-то ещё и у этого чего-то ещё вполне как и QCA параметры могут оказаться вынесены в конфиг.

Как пример https://www.murata.com/en-us/about/newsroom/news/application...

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

18. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от Andrey email(??) on 01-Мрт-18, 15:43 
>> Samsung 1316S7 Wi-Fi Module
> Ну так и я умею. =))) Вот только это ни о чём
> не говорит.

Подскажите как выяснить?

В Edge такой модуль Murata KM5D17074 Wi-Fi module

Вот исходники ядра http://opensource.samsung.com/reception/receptionSub.do?meth...

Не факт же что исходники wifi драйвера открыты?

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

19. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от sfstudio email(ok) on 01-Мрт-18, 15:46 
>>> Samsung 1316S7 Wi-Fi Module
>> Ну так и я умею. =))) Вот только это ни о чём
>> не говорит.
> Подскажите как выяснить?
> В Edge такой модуль Murata KM5D17074 Wi-Fi module

Модель известна - гуглить. Или внимательно изучать dmesg


> Вот исходники ядра http://opensource.samsung.com/reception/receptionSub.do?meth...
> Не факт же что исходники wifi драйвера открыты?

Абсолютно верно. Но есть у меня тут "один могиличек"/доступ к сырцам через китайских коллег. Не ко всем но есть.

Гляньте лог загрузки ядра, почти уверен что там BCM ;(

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

20. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от Andrey email(??) on 01-Мрт-18, 15:52 
В папке /system/etc/wifi куча файлов начинающихся с bcm и nvram.

Судя по некоторым текстовым файлам там BCM4359 WLCSPSS Module



Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

21. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от sfstudio email(ok) on 01-Мрт-18, 16:04 
> В папке /system/etc/wifi куча файлов начинающихся с bcm и nvram.
> Судя по некоторым текстовым файлам там BCM4359 WLCSPSS Module

Ну фигово. Но не так страшно. Надо смотреть сырцы самсунга, есть ли там дров. В  makefile оного есть стопка параметров задающие пороги и т.д.

Т.к. понятно, что пересобирать его никто не будет, то хотя бы узнать какие пороги заданы. А далее исходя из этого знания скорректировать уровни со стороны сети, что бы миграция инициировалась там где нужно. Скорее всего там задано в пределах -72..-75, т.е. придётся заметно уронить уровень со стороны АП.

Контроллировать это можно утилиткой от Aruba.

Т.к.все топовые самсунги прошли сертифкацию по программе VoIP Enterprise от альянса, то логика хэндовер там включена по дефолту. Весь вопрос на каких порогах она срабатывает.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

22. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от Andrey email(??) on 01-Мрт-18, 16:05 

> Гляньте лог загрузки ядра, почти уверен что там BCM ;(
> Compiled in drivers/net/wireless/bcmdhd4359 on Jan  8 2018 at 13:27:06

И в исходниках кстати есть этот драйвер

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

23. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от sfstudio email(ok) on 01-Мрт-18, 16:08 
>> Гляньте лог загрузки ядра, почти уверен что там BCM ;(
>> Compiled in drivers/net/wireless/bcmdhd4359 on Jan  8 2018 at 13:27:06
> И в исходниках кстати есть этот драйвер

Скиньте мне на мыло sfstudio[at]wi-cat.ru что бы все сырцы не качать, освобожусь гляну что там наворотили.

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

24. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от Andrey email(??) on 01-Мрт-18, 16:11 
> В  makefile оного есть стопка параметров задающие пороги
> и т.д.

Вот файл https://drive.google.com/file/d/17HoEtFkr23YGMNeB7fqPdRVJ-L7...

Какие имена параметров?

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

25. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от sfstudio email(ok) on 01-Мрт-18, 17:30 
>> В  makefile оного есть стопка параметров задающие пороги
>> и т.д.
> Вот файл https://drive.google.com/file/d/17HoEtFkr23YGMNeB7fqPdRVJ-L7...
> Какие имена параметров?

Ок щас гляну по быстрому. Вы думаете я на память всё это помню? =)))

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

26. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +1 +/
Сообщение от sfstudio email(ok) on 01-Мрт-18, 17:40 
>>> В  makefile оного есть стопка параметров задающие пороги
>>> и т.д.
>> Вот файл https://drive.google.com/file/d/17HoEtFkr23YGMNeB7fqPdRVJ-L7...
>> Какие имена параметров?
> Ок щас гляну по быстрому. Вы думаете я на память всё это
> помню? =)))

Хэндовер включен
DHDCFLAGS += -DDHD_LOSSLESS_ROAMING

Смотрю какой-то API организовали в новых дровах (не прошло и 7ми лет)
DHDCFLAGS += -DROAM_AP_ENV_DETECTION -DKEEP_CUSTOM_ROAM_TRIGGER
DHDCFLAGS += -DROAM_ENABLE -DROAM_CHANNEL_CACHE -DROAM_API

Нас интересуют триггеры
Поиск по KEEP_CUSTOM_ROAM_TRIGGER натыкает нас на WL_AUTO_ROAM_TRIGGER

который живёт в dhd.h

В котором мы видим все дефолты

#define WL_AUTO_ROAM_TRIGGER -75
/* hooks for custom Roaming Trigger  setting via Makefile */
#define DEFAULT_ROAM_TRIGGER_VALUE -75 /* dBm default roam trigger all band */
#define DEFAULT_ROAM_TRIGGER_SETTING    -1
#ifndef CUSTOM_ROAM_TRIGGER_SETTING
#define CUSTOM_ROAM_TRIGGER_SETTING     DEFAULT_ROAM_TRIGGER_VALUE
#endif

/* hooks for custom Roaming Romaing  setting via Makefile */
#define DEFAULT_ROAM_DELTA_VALUE  10 /* dBm default roam delta all band */
#define DEFAULT_ROAM_DELTA_SETTING      -1
#ifndef CUSTOM_ROAM_DELTA_SETTING
#define CUSTOM_ROAM_DELTA_SETTING       DEFAULT_ROAM_DELTA_VALUE
#endif

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

Вопрос в том, что их дёргает, вероятнее всего в их фирменной утилитке wl появились нужные опции. Вот где её свежую дёрнуть это вопрос. Раньше оно в BCM Android SDK шло, но уже пару лет как её там не видать.

В dhd_linux.c можно видеть то, что можно конфигурить по ioctl

#if defined(ROAM_ENABLE) || defined(DISABLE_BUILTIN_ROAM)
#ifdef USE_WFA_CERT_CONF
        if (sec_get_param_wfa_cert(dhd, SET_PARAM_ROAMOFF, &roamvar) == BCME_OK) {
                DHD_ERROR(("%s: read roam_off param =%d\n", __FUNCTION__, roamvar));
        }
#endif /* USE_WFA_CERT_CONF */
        /* Disable built-in roaming to allowed ext supplicant to take care of roaming */
        bcm_mkiovar("roam_off", (char *)&roamvar, 4, iovbuf, sizeof(iovbuf));
        dhd_wl_ioctl_cmd(dhd, WLC_SET_VAR, iovbuf, sizeof(iovbuf), TRUE, 0);
#endif /* ROAM_ENABLE || DISABLE_BUILTIN_ROAM */
#if defined(ROAM_ENABLE)
        if ((ret = dhd_wl_ioctl_cmd(dhd, WLC_SET_ROAM_TRIGGER, roam_trigger,
                sizeof(roam_trigger), TRUE, 0)) < 0)
                DHD_ERROR(("%s: roam trigger set failed %d\n", __FUNCTION__, ret));
        if ((ret = dhd_wl_ioctl_cmd(dhd, WLC_SET_ROAM_SCAN_PERIOD, roam_scan_period,
                sizeof(roam_scan_period), TRUE, 0)) < 0)
                DHD_ERROR(("%s: roam scan period set failed %d\n", __FUNCTION__, ret));
        if ((dhd_wl_ioctl_cmd(dhd, WLC_SET_ROAM_DELTA, roam_delta,
                sizeof(roam_delta), TRUE, 0)) < 0)
                DHD_ERROR(("%s: roam delta set failed %d\n", __FUNCTION__, ret));
        bcm_mkiovar("fullroamperiod", (char *)&roam_fullscan_period, 4, iovbuf, sizeof(iovbuf));
        if ((ret = dhd_wl_ioctl_cmd(dhd, WLC_SET_VAR, iovbuf, sizeof(iovbuf), TRUE, 0)) < 0)
                DHD_ERROR(("%s: roam fullscan period set failed %d\n", __FUNCTION__, ret));
#ifdef ROAM_AP_ENV_DETECTION
        if (roam_trigger[0] == WL_AUTO_ROAM_TRIGGER) {
                bcm_mkiovar("roam_env_detection", (char *)&roam_env_mode,
                        4, iovbuf, sizeof(iovbuf));
                if (dhd_wl_ioctl_cmd(dhd, WLC_SET_VAR, iovbuf, sizeof(iovbuf), TRUE, 0) == BCME_OK)
                        dhd->roam_env_detection = TRUE;
                else {
                        dhd->roam_env_detection = FALSE;
                }
        }
#endif /* ROAM_AP_ENV_DETECTION */
#endif /* ROAM_ENABLE */

Т.е. в общем-то можно наколупать утилитку которая будет через ioctl это дело тюнить.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

27. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от Andrey email(??) on 02-Мрт-18, 06:55 
> Т.е. в общем-то можно наколупать утилитку которая будет через ioctl это дело
> тюнить.

Я не исключаю, что как минимум часть из них конфигурируются через механизм CSC, в частности гуглятся следующие параметры:

CscFeature_Wifi_SetOffApRoaming
CscFeature_Wifi_ConfigDisconnectApThreshold
CscFeature_Wifi_SupportEapFastReauth
CscFeature_Wifi_PreferredBand

Я думаю их больше, но естественно всё не в открытом доступе


Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

28. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от sfstudio email(ok) on 02-Мрт-18, 14:36 
>> Т.е. в общем-то можно наколупать утилитку которая будет через ioctl это дело
>> тюнить.
> Я не исключаю, что как минимум часть из них конфигурируются через механизм
> CSC, в частности гуглятся следующие параметры:
> CscFeature_Wifi_SetOffApRoaming
> CscFeature_Wifi_ConfigDisconnectApThreshold
> CscFeature_Wifi_SupportEapFastReauth
> CscFeature_Wifi_PreferredBand
> Я думаю их больше, но естественно всё не в открытом доступе

Всё может быть. Сейчас не на чем проверить.

Глянул мельком код. В общем тут ещё одна засада заложена броадкомом или самсунгом или вместе взятыми.

Суть в том, что важная часть логики миграции. А именно отключение FlowControl (что бы в процессе по tx retry не отвалилось) срабатывает только если на AP использован WPA Enterprise (802.1x).

Без него если сразу не успел с первого раза и по быстрому (пока счётчик не зашкалил или всю очередь не выбрал на долго) перескочить то отвалишся просто по числу переповторов.

И нет никаких причин почему не юзать ту же логику и для схемы без 802.1x как тот же QCA. Но тут видимо опять муркетинг.

На досуге ещё гляну что там по нюансам.

Чую данных на ещё одну заметку насобирается. =)))

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

Хотя может это уже творчество непосредственно самсунга.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

29. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от Andrey email(??) on 02-Мрт-18, 14:38 
Забыл поблагодарить, спасибо за потраченное время и полезную информацию.
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

30. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от sfstudio email(ok) on 02-Мрт-18, 14:40 
> Забыл поблагодарить, спасибо за потраченное время и полезную информацию.

Не за что, как бы часть работы, а публикации это побочный продукт. Жалко просто хоронить инфу.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

31. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от Andrey email(??) on 02-Мрт-18, 15:04 
> На досуге ещё гляну что там по нюансам.

Если вдруг заметите как одну проблему решить видимо связанную вот с этим:

>Да и ещё:
>   # 1: Enable standby, 2: Enable Deep sleep, 3: Enable Mcast/Bcast Filter
>   gEnableSuspend=3
>По умолчанию обычно 0. В таком режиме клиент при переходе в режим сна (часто просто при выключении >экрана) полностью тушит RF часть, временно просыпаясь только для того, чтобы AP его по таймауту не >выпнула. При этом, реализация такова, что и роумингу зачастую становится плохо. Следует установить >его в 3, т.е. фильтровать броадкасты и мультикасты во сне, и только.

Было бы очень круто, т.к. это большая проблема для S7, если на ТД включено обновление ключей (Group Key Update Interval), то телефон отваливается от WiFi и во сне ходит в инет через сотовую сеть пока не разбудишь.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

32. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от sfstudio email(ok) on 02-Мрт-18, 15:09 
> Было бы очень круто, т.к. это большая проблема для S7, если на
> ТД включено обновление ключей (Group Key Update Interval), то телефон отваливается
> от WiFi и во сне ходит в инет через сотовую сеть
> пока не разбудишь.

Это чисто для QCA. У BCM тоже есть типа MCAST/BCAST filter in suspend, но оно работает всегда.

Вообще на наших железках ни на BCM клиентах, ни на QCA ни даже на вечно кривом в этом плане риалтэке такой проблемы не вижу. Я очень много времени потерял на отладку PSM в дровах от MTK.

Возможно проблема не на стороне клиента и никак не связано именно с описанным.


Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

33. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от Andrey email(??) on 02-Мрт-18, 15:18 
> Возможно проблема не на стороне клиента и никак не связано именно с
> описанным.

Возможно и что-то с согласованием обновления ключей, но это прям фича S7 http://4pda.ru/forum/index.php?act=findpost&pid=48167500&anc... (2 пункт)


Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

34. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от sfstudio email(ok) on 02-Мрт-18, 15:19 
Ещё интересность. Тут сделано всё несколько хитрее.

Обычно практикуется 2 подохода:

SME/MLME в драйвере а суппликант лишь нахлобучка, всё это связывается и управляется через WEXT который не позволяет перетащить SME/MLME на сторону суппликанта. Иногда даже и суппликант или hostapd (если AP) не нужен, как у нас в софте например.

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

Вторая схема это использование NL802.11 интерфейса с переносом SME/MLME на сторону суппликанта (как в заметке моей рядом по интелам).

Из плюсов, можно заставить делать то, что драйвер не умеет. Единый код независимо от чипа на стороне суппликанта и т.д.

Минусы - если кто-то сожрал весь проц пиши пропало вплоть до отвала соединения.

Тут похоже используется третий подход.

SME/MLME на стороне драйвера, управление через суппликант, но часть MLME включая роаминг перетащена на сторону суппликанта. В драйвере храниться кэш PMK для станций на которых побывали, кэши сканов и т.д., но именно решение куда мигрировать и как принимает суппликант.

При этом используется "собственное расширение" активируемого по флагу читаемому через ioctl.

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

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

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

Пока разве что можно попробовать поиграться параметрами озвученными выше через CSC оно всяко через IOCTL их и дёргает.

Кому не лень - попробуйте.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

35. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от sfstudio email(ok) on 02-Мрт-18, 15:23 
>> Возможно проблема не на стороне клиента и никак не связано именно с
>> описанным.
> Возможно и что-то с согласованием обновления ключей, но это прям фича S7
> http://4pda.ru/forum/index.php?act=findpost&pid=48167500&anc...
> (2 пункт)

Не факт. А вот последствие фикса WPA2 CRACK запросто. Опять же у нас в софте учтено это дело. Если помогает выставить на стороне АП рекей интервал в 0, то это скорее всего оно самое, и вопросы к АП.

В хостапд даже ключик вроде добавили отключающий новое поведение. Я по другому решил проблему, долго расписывать как. Но у нас нет hostapd, а всё делает драйвер, потому не перенести куда-то ещё.

Или в суппликант ли ключик добавляли, не помню. Но помню что добавляли. =))

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

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

36. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от pavlinux (ok) on 03-Мрт-18, 13:54 
Это все прекрасно, но в реальности все AP требуют авторизации через SMS или посещение сайта с рекламой.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

37. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от sfstudio email(ok) on 03-Мрт-18, 16:10 
> Это все прекрасно, но в реальности все AP требуют авторизации через SMS
> или посещение сайта с рекламой.

У вас в офисе? Сочувствую. Где вы нашли упоминание публичных хотспотов я ХЗ. Речь как раз о так называемых сетях выской плотности, т.е. офисные сети множеством АП например. На кой там авторизации через SMS я хз.

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

40. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  –1 +/
Сообщение от Аноним (??) on 05-Мрт-18, 08:58 
В таких сетях используют железо типа Ubiquiti UniFi и не занимаются колхозным кулхацкерством.
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

41. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +1 +/
Сообщение от sfstudio email(ok) on 05-Мрт-18, 12:25 
> В таких сетях используют железо типа Ubiquiti UniFi и не занимаются колхозным
> кулхацкерством.

И имеют ровно те же проблемы. Внезапно? Проблема лежит на стороне клиента, именно клиент в 802.11 решает куда и как ему мигрировать.

Убики вообще додумались крыжик хотя бы 802.11r вынести в рожу совсем недавно. Только вот он ничем не поможет.

У меня на ресурсе есть ссылки в т.ч. на циску с исследованием поведения клиентов. Изучайте.

Единственное что было у убиков и у мераки решающее эту проблему на корню это реализация ZH (как у мераки называлось не помню). Но похоронено обоими ибо не масштабируется от слова совсем.

Так же проблема обусловлена отсутствием нормальных механизмов управления миграцией со стороны АП. А то куцее "ничто" в виде RRM/FT, что есть, не является обязательным к реализации для прохождения сертификации у альянса на получение крыжика очередного новомодного "стандарта"" wi-fi. В итоге производители клиентских (да и не только) устройств хором на это забивают. Нет так же и чётких требований к процедуре миграции и критериям, потому реализация у каждого чипмейкера своя, а каждый вендор ещё туда палочкой потычет иногда до слома логики.

И никакая золотая АП не решит проблему кривого или куцего клиента. Логика на клиенте не меняется от крутости АП.

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

42. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от Nicknnn (ok) on 06-Мрт-18, 09:51 
> bgscan="simple:30:60:200"

А разве не bgscan="simple:30:-60:200" ?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

43. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от sfstudio email(ok) on 06-Мрт-18, 09:52 
>> bgscan="simple:30:60:200"
> А разве не bgscan="simple:30:-60:200" ?

Да сорь, минус потерял при копировании строчки, надо поправить

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

44. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от Аноним (??) on 17-Мрт-18, 16:35 
Зачем оно надо? Даже на винде этого нет.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

45. "Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android"  +/
Сообщение от sfstudio email(ok) on 18-Мрт-18, 14:13 
> Зачем оно надо? Даже на винде этого нет.

Чего нет? В винде как раз с этим более менее пристойно. QCA/Intel и даже риалтэк даже позволяют крутить агрессивность роуминга. Интел так вообще мигрирует спокойно, даже в сетях собранных из палок с применением чёрной (не синей, с синей все могут =)) изоленты.

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру