The OpenNET Project / Index page

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

Бесшовная миграция (роуминг) Wi-Fi для клиентов Linux и Android
С 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.src.rpm 

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

   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 системе (т.е. о том, что его выпнули (kickout), знает только драйвер, и
сразу пытается мигрировать, если не получается, то тогда уже сообщает системе,
что всё, связи с этой сетью больше нет, надо выбрать другой 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 и перезагрузиться.
 
26.02.2018 , Автор: sfstudio , Источник: https://wi-cat.ru/2018/02/17/bessho... (доп. ссылка 1)
Раздел:    Корень / Пользователю / Мобильные телефоны

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, LeNiN (ok), 12:59, 26/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    @sfstudio, спасибо большое!
    А если сделать настройки из вашей статьи только на роутерах — как будут вести себя клиенты?
     
     
  • 2.2, sfstudio (ok), 14:29, 26/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Процедуру хэндовера в 802.11 инициирует клиент. Со стороны АП его разве что сбить можно послав deauth. Что почти всегда будет приводить к потери соединений приложениями на клиентах (такова уж реализация).

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

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

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

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

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

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

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

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

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

     
     
  • 3.11, Аноним (-), 03:36, 28/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Так же (в самом конце) разберу такую штуку как безроуминговая сеть, аля ZeroHandoff.

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

     
     
  • 4.13, sfstudio (ok), 04:15, 28/02/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Так же (в самом конце) разберу такую штуку как безроуминговая сеть, аля ZeroHandoff.
    > С такими аппетитами напрашивается сразу что-то типа mesh, но в батарейных устройствах
    > батарейка таки долго не протянет...

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

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

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

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

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

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

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

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

     

  • 1.3, sfstudio (ok), 14:35, 26/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Редактор зачем-то поправил текст так что, смысл несколько съехал.

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

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

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

     
     
  • 2.4, Maxim Chirkov (ok), 18:31, 26/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    "Пинки" я не трогал, на первый взгляд все на месте. Заменил только "прилетит по голове" на "отсоединит".
     
     
  • 3.5, sfstudio (ok), 18:36, 26/02/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ок, ок Но в данном случае именно прилетит по голове Ибо отсоединит это зе... текст свёрнут, показать
     
     
  • 4.6, Maxim Chirkov (ok), 18:52, 26/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Но в данном случае именно прилетит по голове. Ибо отсоединит это зело мягко. Там натурально выпнет с АП, нагло и безжалостно и будь что будет. В этом и соль.

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

     
     
  • 5.7, sfstudio (ok), 18:57, 26/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну скорее не для целостности. Просто придумать чем заменить длииинное объяснение на простое, наглядное и красочное словосочетание не очень просто... =)

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

     

  • 1.8, Аноним (-), 21:18, 27/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И если все сделать как описано тут, то
    1) Будет работать с полутора прошивками полутора устройств. После дикой камасутры.
    2) Работать будет очень так себе, потому что -60 Дб мобильные устройств видят только если их на роутер положить. Можно конечно прыгать как белка с базы на базу, но результатом станут лаги в передаче данных и жор батарейки.
    3) Приваси отправляется в пешее эротическое и сливается до уровня хуже чем у эппловских зондов в ипхоне.
    4) Агрессивно сватается какая-то убогая прошивка вместо удобного и фичастого openwrt. Нет бы туда запилить.

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

     
     
  • 2.9, sfstudio (ok), 21:38, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Работать будет прекрасно, не для всех да Эт что у вас за то такое в роли АП... текст свёрнут, показать
     
     
  • 3.10, Аноним (-), 03:26, 28/02/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вот я и пытаюсь прикинуть на сколько инсталляций вас хватит до того как вы забод... текст свёрнут, показать
     
     
  • 4.12, sfstudio (ok), 03:58, 28/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Я не занимаюсь инсталляциями Я занимаюсь разработкой софта для АП И волей не в... текст свёрнут, показать
     

  • 1.14, Andrey (??), 12:37, 01/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А на SGS 7 на snapdragon (американец) нет такого файла WCNSS_qcom_cfg.ini по указанному пути /system/etc/wifi
     
     
  • 2.15, sfstudio (ok), 14:48, 01/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > А на SGS 7 на snapdragon (американец) нет такого файла WCNSS_qcom_cfg.ini по
    > указанному пути /system/etc/wifi

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

     
     
  • 3.16, Andrey (??), 15:32, 01/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Samsung 1316S7 Wi-Fi Module
     
     
  • 4.17, sfstudio (ok), 15:38, 01/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Samsung 1316S7 Wi-Fi Module

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

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

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

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

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

     
     
  • 5.18, Andrey (??), 15:43, 01/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> Samsung 1316S7 Wi-Fi Module
    > Ну так и я умею. =))) Вот только это ни о чём
    > не говорит.

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

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

    Вот исходники ядра http://opensource.samsung.com/reception/receptionSub.do?method=sub&sub=F&sear

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

     
     
  • 6.19, sfstudio (ok), 15:46, 01/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Samsung 1316S7 Wi-Fi Module
    >> Ну так и я умею. =))) Вот только это ни о чём
    >> не говорит.
    > Подскажите как выяснить?
    > В Edge такой модуль Murata KM5D17074 Wi-Fi module

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


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

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

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

     
     
  • 7.22, Andrey (??), 16:05, 01/03/2018 [^] [^^] [^^^] [ответить]  
  • +/

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

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

     
     
  • 8.23, sfstudio (ok), 16:08, 01/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Скиньте мне на мыло sfstudio at wi-cat ru что бы все сырцы не качать, освобожусь... текст свёрнут, показать
     
  • 5.20, Andrey (??), 15:52, 01/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В папке /system/etc/wifi куча файлов начинающихся с bcm и nvram.

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



     
     
  • 6.21, sfstudio (ok), 16:04, 01/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > В папке /system/etc/wifi куча файлов начинающихся с bcm и nvram.
    > Судя по некоторым текстовым файлам там BCM4359 WLCSPSS Module

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

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

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

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

     
     
  • 7.24, Andrey (??), 16:11, 01/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > В  makefile оного есть стопка параметров задающие пороги
    > и т.д.

    Вот файл https://drive.google.com/file/d/17HoEtFkr23YGMNeB7fqPdRVJ-L7TRsAN/view?usp=sha

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

     
     
  • 8.25, sfstudio (ok), 17:30, 01/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ок щас гляну по быстрому Вы думаете я на память всё это помню ... текст свёрнут, показать
     
     
  • 9.26, sfstudio (ok), 17:40, 01/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хэндовер включен DHDCFLAGS -DDHD_LOSSLESS_ROAMING Смотрю какой-то API организ... текст свёрнут, показать
     
     
  • 10.27, Andrey (??), 06:55, 02/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Я не исключаю, что как минимум часть из них конфигурируются через механизм CSC, ... текст свёрнут, показать
     
     
  • 11.28, sfstudio (ok), 14:36, 02/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Всё может быть Сейчас не на чем проверить Глянул мельком код В общем тут ещё ... текст свёрнут, показать
     
     
  • 12.31, Andrey (??), 15:04, 02/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Если вдруг заметите как одну проблему решить видимо связанную вот с этим Было б... текст свёрнут, показать
     
     
  • 13.32, sfstudio (ok), 15:09, 02/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это чисто для QCA У BCM тоже есть типа MCAST BCAST filter in suspend, но оно ра... текст свёрнут, показать
     
     
  • 14.33, Andrey (??), 15:18, 02/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Возможно и что-то с согласованием обновления ключей, но это прям фича S7 http ... текст свёрнут, показать
     
     
  • 15.35, sfstudio (ok), 15:23, 02/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не факт А вот последствие фикса WPA2 CRACK запросто Опять же у нас в софте учт... текст свёрнут, показать
     
  • 12.34, sfstudio (ok), 15:19, 02/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё интересность Тут сделано всё несколько хитрее Обычно практикуется 2 подохо... текст свёрнут, показать
     
  • 10.29, Andrey (??), 14:38, 02/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Забыл поблагодарить, спасибо за потраченное время и полезную информацию ... текст свёрнут, показать
     
     
  • 11.30, sfstudio (ok), 14:40, 02/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не за что, как бы часть работы, а публикации это побочный продукт Жалко просто ... текст свёрнут, показать
     

  • 1.36, pavlinux (ok), 13:54, 03/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Это все прекрасно, но в реальности все AP требуют авторизации через SMS или посещение сайта с рекламой.
     
     
  • 2.37, sfstudio (ok), 16:10, 03/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Это все прекрасно, но в реальности все AP требуют авторизации через SMS
    > или посещение сайта с рекламой.

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

     
     
  • 3.40, Аноним (-), 08:58, 05/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В таких сетях используют железо типа Ubiquiti UniFi и не занимаются колхозным кулхацкерством.
     
     
  • 4.41, sfstudio (ok), 12:25, 05/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В таких сетях используют железо типа Ubiquiti UniFi и не занимаются колхозным
    > кулхацкерством.

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

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

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

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

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

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

     

  • 1.42, Nicknnn (ok), 09:51, 06/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > bgscan="simple:30:60:200"

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

     
     
  • 2.43, sfstudio (ok), 09:52, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> bgscan="simple:30:60:200"
    > А разве не bgscan="simple:30:-60:200" ?

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

     

  • 1.44, Аноним (-), 16:35, 17/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Зачем оно надо? Даже на винде этого нет.
     
     
  • 2.45, sfstudio (ok), 14:13, 18/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Зачем оно надо? Даже на винде этого нет.

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

     


     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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