С 6.2.4 (доступна в тесте https://sourceforge.net/projects/wive-ng/files/wive-ng-mt/test-only/) добавили возможность отключать анонсы неиспользуемых подиапазонов. Т.е. например если ваша сеть работает только на 36м канале и имеет полосу в 80МГц (т.е. занимает весь поддиапазон) то стоит убрать галочки с остальных диапазонов. Если клиент ориентируется на то что анонсит АП, а не плюёт на это (поддержка RRM на стороне клиента для этого не требуется, как бы штатная процедура, но далеко не везде реализовано) то клиент должен сначала просканировать анонсируемый диапазон и если там нет кандидата то только тогда сканировать все суббэнды.

 

Если например используем каналы 36 и 64 в 80МГц то разрешаем 2 диапазона.

 

Тут весь вопрос в радиопланировании, что будет эффективнее использовать схему 36 80MHz only, 36+64 80MHz или 36+48 40MHz.

 

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

 

А если сюда добавить тягу всегда посканить 2.4 то это ещё почти секунда времени.

 

Анонсировать меньше 4х каналов в поддиапазоне увы низя т.к. 80МГц полоса должна полностью укладываться в анонсируемые каналы иначе некоторые клиенты просто дуреют. Потому ограничение сделано по поддиапазонам.

 

Для 2.4 ограничение не актуально там всего один поддиапазон в который укладываются все доступные каналы.

rrm.jpg

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


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

Едем дальше. С этой же версии АП полноценно поддерживает neighbor_rep_request. Т.е. может сообщать о своих соседях клиенту без выполнения клиентом сканирования.

 

Данные AP берёт:

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

2) переодическими сканированиями когда на АП нет клиентов с интервалом 120с

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

 

Т.е. правильному клиенту поддерживающему RRM теперь что бы узнать кто есть вокруг достаточно спросить у AP.

 

Например свежий wpa_supplicant с драйвером nl80211 и картой его поддерживающей (i7260 например) может запросить инфу по команде wpa_cli neighbor_rep_request после чего в логе можно созерцать записи вида:

 

1499942892.508208: wlan0: RRM-NEIGHBOR-REP-RECEIVED bssid=f8:f0:82:60:6c:7a info=0x1cd3 op_class=0 chan=44 phy_type=9

 

Apple из RRM выбирает первые 6ть записей и сканирует первым заходом только каналы на которых работают соседние (по данным RRM) AP. Это сокращает время сканирования с 3с до ~60мс при сети работающей на 2х разных каналах независимо от диапазона и поддиапазона (2.4 будет сканироваться если кандидата в 5ке подходящего нет, т.е. нет вовсе или уровни ниже плинтуса).

 

К сожалению в самом суппликанте дело дальше умения запросить данные от RRM не пошло, и они нигде не используется. Потому чистые Linux системы в пролёте.

 

Но там можно использовать bg_scan в режиме learn. Т.е. будет сканировать только тот канал на котором работает с текущей АП. Но всё это крайне коряво. ;(

 

Кроме этого реализация RRM у нас умеет добавлять к анонсам данные о загруженности АП (QLOAD). Данные о текущей выходной мощности и необходимости её ограничить TPC/Power Constraint. Поддерживается и RRM Quiet.

 

Всё это можно увидеть с любой линукс машины заглянув в вывод iw wlan0 scan.

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


Ссылка на сообщение
Поделиться на другие сайты
К сожалению в самом суппликанте дело дальше умения запросить данные от RRM не пошло, и они нигде не используется. Потому истые Linux системы в пролёте.

я понимаю, что в своём софте ты wpa_supplicant не юзаешь, но может запостишь им патч? И тебе проще тестить и вдруг до андройда докачует....

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


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

Какой я им патч должен запостить? Оно у них не реализовано, и кто и когда должен это реализовывать? У меня работы по своим железкам на несколько месяцев уже отстаёт т.к. то КРОС, то другая золотуха... Сидеть придумывать как заюзать это дело в пределах суппликанта, переписывать логику миграции, потом месяц в списках рассылки доказывать что не баран? =))) Пинал бы я воздух - может и родил бы. Но всё упирается во время. Личного времени у меня уже вообще нет. На 2 часа на природу раз в неделю вот и всё свободное время. Так что имейте совесть. Как-нить самостоятельно. ;)

 

Да и судя по гиту (https://w1.fi/cgit/hostap/log/?qt=grep&q=rrm) как раз сейчас по RRM там что-то активно пилиться. Последняя правка 4ре дня назад была. А первый коммит по нему в конце 2016. Так что ждёмс.

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


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

Собрал новый супликант из гита...

1499949159.887403: wlan0: BSS: Start scan result update 8
1499949159.887435: wlan0: BSS: Add new id 13 BSSID f8:f0:82:12:12:12 SSID 'Wive-NG-MT' freq 5220
1499949159.887479: wlan0: BSS: Add new id 14 BSSID f8:f0:82:09:74:cb SSID 'SF' freq 2412
1499949159.887505: wlan0: BSS: Add new id 15 BSSID f8:f0:82:01:01:03 SSID 'SF' freq 2412
1499949159.887521: BSS: last_scan_res_used=4/32
1499949159.887536: wlan0: New scan results available (own=1 ext=0)
1499949159.887548: bgscan simple: scan result notification
1499949159.887563: wlan0: Radio work 'scan'@0x75edf0 done in 6.509115 seconds
1499949159.887575: wlan0: radio_work_free('scan'@0x75edf0: num_active_works --> 0
1499949159.887587: wlan0: Scan results matching the currently selected network
1499949159.887612: wlan0: 1: f8:f0:82:9f:70:62 freq=5220 level=-45 snr=47 est_throughput=390001
1499949159.887635: wlan0: 2: f8:f0:82:09:74:cb freq=2412 level=-27 snr=62 est_throughput=135000
1499949159.887654: wlan0: 3: f8:f0:82:01:01:03 freq=2412 level=-58 snr=31 est_throughput=135000
1499949159.887666: wlan0: Selecting BSS from priority group 1
1499949159.887685: wlan0: 0: f8:f0:82:12:12:12 ssid='Wive-NG-MT' wpa_ie_len=0 rsn_ie_len=24 caps=0x1931 level=-25 freq=5220
1499949159.887696: wlan0:    skip - SSID mismatch
1499949159.887706: wlan0:    skip - SSID mismatch
1499949159.887717: wlan0:    skip - SSID mismatch
1499949159.887740: wlan0: 1: f8:f0:82:9f:70:62 ssid='SF' wpa_ie_len=0 rsn_ie_len=24 caps=0x1931 level=-45 freq=5220
1499949159.887752: wlan0:    skip - SSID mismatch
1499949159.887760: wlan0:    skip - SSID mismatch
1499949159.887768: wlan0:    selected based on RSN IE
1499949159.887780: wlan0:    selected BSS f8:f0:82:9f:70:62 ssid='SF'

 

Вот это праздник!!!! Оно наконец научилось по дефолту 5GHz preffered и не попыталось свалиться в 2.4 сразу после сканирования... Но пока эти изменения войдут в ведроид и в дистрибутивы скорее всего застрелиться проще будет.

 

И как не странно даже network monitoring заработал более менее... Но блин это всё не в продакшн... Но движение есть.

 

Данные RRM по прежнему не юзаются ;(

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


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

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

оно сообщает о соседях только в своём диапазоне?

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


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

Он сообщает о запрошенном SSID если данные есть в scantab. Т.е. если при сканировании были замечены AP с подходящим SSID на каналах 1-2-3-4 то все 4ре и ответит. Пассивно же обновляет инфу он только о АП на своём канале, иначе пришлось бы всех выкинуть с AP на почти 5 секунд и пересканировать всё.

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


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

я имел в виду 2.4/5

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


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

Радиомодули = физически разные АП. Ессно 5ГГц модуль сообщает о 5ГГц, 2.4ГГц о 2.4ГГц

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


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

Теперь хорошоая новость для Linux`оидов. С wpa_supplicant из GIT запросто настраивается "прозрачная" миграция. Т.е. iptv мультикастовое продолжает литься при миграции, iperf в большинстве случаев не умирает а лишь деградирует по скорости в момент миграции и т.д. При этом даже корректно отрабатывает вариант с несколькими АП в разных поддиапазонах 5ГГц. Что для этого надо (на примере mageia linux v5)

 

1) wpa_supplicant из гит (можно взять подготовленный мной src.rpm 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 хоть типа и умеют, но увы по факту даже сканирование не работает). Проверить что используется на данный момент можно посмотрев с какими опциями запущен суппликант (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: Background scanning
# wpa_supplicant behavior for background scanning can be specified by
# configuring a bgscan module. These modules are responsible for requesting
# background scans for the purpose of roaming within an ESS (i.e., within a
# single network block with all the APs using the same SSID). The bgscan
# parameter uses following format: "<bgscan module name>:<module parameters>"
# Following bgscan modules are available:
# simple - Periodic background scans based on signal strength
# bgscan="simple:<short bgscan interval in seconds>:<signal strength threshold>:
# <long interval>"

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

 

Т.е. при уровне ниже -50 будем начинать время от времени "щупать эфир" на предмет наличия кандидатов для миграции и по возможности мигрировать.

 

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

 

Вот вместо фонового сканирования можно было бы использовать данные из RRM, но этой логики в суппликанте пока нет.

 

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

Упс, не тот прикрепил, перезалил.

defconfig_new.zip

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


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

И дифф от оригинального defconfig для наглядности.

 

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

wpa_supplicant-2.2-mga-defconfig.patch.zip

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


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

Приобрёл тут на днях Samsung Galaxy A5 (версия 2017 года). И был приятно удивлён. Поддержка FT, нормальная миграция за некоторыми огрехами. Похоже поддержка RRM так же имеется.

a5_migration.png

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


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

А чё за утилита на скрине?

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


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

По данным тулзы сверху сама миграция (без сканирования) заняла меньше 10мс (на самом деле чуть больше). Т.е. преаутентификация работает в т.ч. в FT-PSK (описывал выше как это реализовано). iperf не обрывается, всё продолжает бегать.

 

Со сканированием (используется периодическое фоновое сканирование на том же канале без остановки передачи) получается 99мс. Но тут на самом деле вещи не особо связанные. Т.е. сканирование проводиться переодически всегда, при падении уровня ниже -75 выполнение скана на том же канале форсируется. И по результатам его и других данных либо выполняется миграция, либо полное сканирование диапазона или даже обоих диапазонов.

 

Из минусов:

1) порог начала миграции не регулируется и задан как -75дБ, хотелось бы иметь возможность крутить оный и начинать сканирование фоновое и опрос RRM уже где-то при -65дБ

2) какая-то странная трабла в планировщике TCP, если полезли задержки или потери то он сбрасывает скорость (если с него гнать траик на сервер iperf) и потом через раз её восстанавливает. Т.е. болтанка на уровне 10тка мегабить пока не вырубишь и снова не включишь iperf.

3) крайне редко но всё же пытается при миграции съехать в 2.4 со всеми вытекающими

 

Пока это аппарат из всех виденных мной с самой беспролблемной миграцией. Видимо при получении сертификата http://www.wi-fi.org/content/search-page?keys=%20SM-A520 им таки пришлось над этим делом изрядно поработать.

 

А чё за утилита на скрине?

 

https://play.google.com/store/apps/details?id=com.arubanetworks.arubautilities

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


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

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

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


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

Со сканированием (используется периодическое фоновое сканирование на том же канале без остановки передачи)

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

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


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

Да,что бы просканить диапазон нужно как минимум послушать маяки на каждом канале, а в случае с активным сканированием ещё и probe req послать. Можно конечно оставаться на своём канале и видеть маяки на смежных, но инфа о уровнях будет мягко сказать с погрешностью. Что бы получить актуальные данные мы должны перестроить RF часть на нужную частоту и послушать маяки или послать probe.

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


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

И так, история повторяется. После обновления Samsung Galaxy A5 до Android 7 + ещё какие-то там обновления были, он разучился использовать 802.11R. Т.е. в роже то он у себя показывает, что видит и юзает FT-PSK, но по факту поля относящиеся к FT не заполнят, и ессно FT не используется при этом.

 

Мигрировать "безшовно" он от этого не перестал, но время первого перехода (т.е. пока на АП нет кэшированных данных для быстрой реассоциации) выросло в несколько раз.

 

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

 

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

 

Что в итоге пришлось сделать:

1) по дефолту увеличить время наблюдения за клиентом до отстрела с 6 секунд до 10

2) добавить логику которая даёт фору в 3 секуды клиентам в сторону которых летит трафик >~30кбит (т.е. они явно какую-то активность проявляют, а не просто висят и не спят) + число ошибок передачи в их сторону далеко до предела после которого его отстрелит просто по сути по потери связи.

3) в логике временной блокировки клиента после отсрела, мы теперь не тупо игнорируем запросы от клиента, а сразу шлём REJECT, это сильно сокращает время залипания клиента на одной АП при срабатывании логики отстрела вынуждая его сразу (ну т.е. после уже считай второго пинка, т.к. после первого зачастую пытается лезть на ту же АП что ему не шли) начать активное сканирование для поиска кандидата (актуально для 7го андроида и видимо железоспецифично)

 

Эти меры позволили как минимум для SGS A5 избавиться от ложных отстрелов до самостоятельной миграции.

 

До кучи выяснилась ещё одна особенность реализации wifi от Samsung, если аппарат некоторое время не пускает ни одна АП (чёт около полуминуты), то модуль переходит в неактивное состояние (в логе андроида это прекрасно видно, видимо батарейку пытаются экономить) и перестаёт пытаться реконнектиться вообще до пинка пользователем. При этом в UI андроида с какого-то перепуга говорит "ошибка проверки подлинности", хотя там до этой самой проверки как до шанхая пешком. Лень похоже просто было отдельный статус для этой ситуации сделать. Черти.

 

Грозит это тем, что если есть дыры в покрытии аппарат будет вставать вот в такую позу. Ну или на границе зоны обслуживания сети может произойти тоже самое. Лечения нет, тоже буду репортить.

 

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

 

Правки доступны в тестовых версиях 6.5.х ветки начиная с 6.5.3.

 

А пока я буду рожать репорт самсунгу, чего делать-то.

 

Ещё одна правка по логике handoff не относящаяся к SGS коснулась вычисления уровня сигнала при котором начинает тикать счётчик отстрела. Т.е. порог при котором клиента застрелит теперь вычисляется не как среднее значение со всех стримов, а берётся максимальное значение. Это снижает риск ложно отстрелить клиента у которого по какой-либо причине имеется значительный перекос по уровням в каждом чейне. Актуально для >=2T2R AP (у нас это актуально для всех 2.4ГГц железок).

 

С 6.5.4 также по дефолту вырубим FT over distribution system и поддержку Resource Req из-за проблем с совместимостью с новыми интеловскими картами (временно пока не починят). Причём прикольно, что наличие этих флагов в анонсах достаточно что бы драйвер интела под винду начал дуреть вплоть до BSOD`а. Фееричнейший глюк от интела.

 

Как бы остальным это ни чем не грозит. Та же CISCO рекомендует отключать FT over DS при "плотном" размещении АП. Т.е. оставлять только OverAir, а ResourceReq мало кто умеет (даже яблоки не используют) и у той же циски так же по дефолту отключено.

 

Позже вытащим крутилки в морду.

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


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

Начиная с 6.6.6 в логику RRM внесено несколько изменений.

 

Во первых теперь АП не будет проверять соответствие канала своему при пассивном наблюдении за маяками от соседей. Т.е. если прилетевший маячок был декодирован и уровень его выше -85 запись о такой АП будет добавлена в scan tab и после сортировки будет задан соответствующий приоритет. Это позволяет иметь информацию о смежных АП работающих в том же диапазоне в пределах разрешённой полосы.

 

Во вторых, при сканировании (если включен RRM) в scantab попадут только АП с уровнми выше -85. Т.е. в список RRM попадут только те АП к которым хотя бы теоретечески прямо сейчас или через N время (если клиент движется) будет возможен коннект.

 

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

 

Так же, пока не забыл, замечу, что в дуалбэнд сетях с BandSteering если эфир относительно чистый, имеет смысл уменьшить мощность 2.4ГГц передатчика вплоть до 40-20%. Это позволит некоторым туповатым (но не совсем тупым) клиентам не пытаться съехать в 2.4 при миграции, т.е. не влетать в логику band steering теряя время на попытки подключения в 2.4.

 

В идеале нужно мониторя на клиенте выставить уровень такой что бы он в точке предполагаемого перехода был примерно на 5Дб ниже в 2.4ГГц диапазоне, чем в 5ГГц.

 

К сожалению в реальной жизни 2.4ГГц везде засран в усмерть, потому понизить уровень это далеко не всегда удачная мысль. Понижая уровень мы заведомо уменьшаем SNR на клиенте, увеличивается число ошибок и т.д. и т.п. Тут нужен баланс.

 

Если это сеть предприятия где критична "прозрачность" миграции всё же лучше разделить 2.4ГГц и 5ГГц сети по разным SSID и разрулить кому куда подключаться уже административными методами. Т.е. отказаться от использования BandSteering.

 

Если прозрачность миграции не критична, то проблем нет.

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


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

Внимание!!!

 

Исправление уязвимости в WPA2 https://forum.nag.ru/index.php?/topic/134872-wpa2-vzlomali/ к сожалению таки имеет побочные эффекты.

 

Например вчера обновился SGS A5 и снова начал использовать FT. Но после казалось бы корректной миграции имеем якобы нормально работающее подключение, и отсутствие трафика. ;( Как лечить пока не придумал. Буду разбираться.

 

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

 

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


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

Начиная с 6.6.10 добавлена логика для обратной совместимости с непатченными клиентами. В т.ч. с SGS A5. Т.е. теперь будет работать хоть с теми хоть с теми. Ессно если клиент не исправлен, то его трафик по прежнему можно будет прослушать. Правки со стороны АП на уязвимость самого клиента не влияют.

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


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

Ещё немного живой статистики с офиса NAG (после анализа логов).

 

Сегодня за день было:

всего клиентов поддерживающих 802.11R - 52
всего клиентов НЕ поддерживающих 802.11R - 149
 

из них самостоятельно (без пинка со стороны handoff) НЕ мигрировали:
19 клиентов поддерживающих 802.11R

62 клиента НЕ поддерживающих 802.11R

 

Стационарных клиентов поддерживающих 802.11R в офисе пара ноутов. Не поддерживающих около 30 ноутов (точнее не скажу, но для оценки хватит).

 

Т.е. из самостоятельно мигрирующих вычитаем этих товарищей:

 

52  - 19 - 2 = 31 клиент поддерживающий 802.11R нормально мигрировал не дожидаясь пинка под зад
149 - 62 - 30 = 57 клиентов НЕ поддерживающих 802.11R так же нормально мигрировали без пинка

 

Можно пойти дальше и посчитать процентное соотношение, но и так видно, что наличие 802.11R не гарантия того, что клиент норамльно роумиться и умеет нормально handover, как и наоборот, отсутствие поддержки 802.11R не является препятсвием для нормальной миграции.

 

Вот такая вот статистика на злобу дня. Всё зависит от реализации логики миграции на стороне клиента. Умеет 802.11K/R - хорошо, НЕТ - ну и не страшно. Важнее именно нормально работающая процедура handover на стороне клиента, что бы не приходилось к нему применять логику handoff. =) Но таки да, если клиент умеет 802.11K/R то и вероятность нормальной реализации handover в нём несколько выше.

 

Число 5ГГц при этом около 43% держалось стабильно весь день (при работающем band steering). При отключенном гарантированно упадёт до 25% и менее, проверено неоднократно.

 

P.S. Можно конечно прибрать уровни в 2.4ГГц, это даст прирост нормально мигрирующих ещё процентов 5-6, но в данном случае это офисцентр и эфир засран, существенно, опуская уровень мы просто портим себе SNR на RX у клиента и как следствие явно видно падение скорости. Благо тут важнее балансировка.

 

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

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


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

Как и обещал ранее, рассказываю как заставить Android устройства с радио на atheros/qualcomm нормально мигрировать (в большинстве случаев).

Нужно собсно устройство, обязательно рутованное.

 

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

 

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

 

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

 

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

 

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

 


# 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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

gNeighborLookupThreshold=65

 

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

 

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


# CCX Support and fast transition
CcxEnabled=0
FastTransitionEnabled=1
ImplicitQosIsEnabled=0
gNeighborScanTimerPeriod=200

 

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

 

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

 

ImplicitQosIsEnabled -  не догнал что это такое, в дровах какая-то муть на эту тему.
 

gNeighborScanTimerPeriod - безусловно полезная опция, задающая интервал фоновых сканирований в отсутствии передачи данных даже когда мы ещё далеки от срабатывания логики handover (т.е. порога о котоом говорил выше). По умолчанию 200 (попугаев???). По факту похоже что 200 = 20 секунд он будет выполнять сканирование для обновления списка соседей из которых если что будет выбран кандидат для миграции. Это очень дофига. Возьмём пример с самсунга и выставим его в 80.

 

gNeighborScanTimerPeriod=80

 

 

Не забываем так же отрубить 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 (сюрпрайз)... Ну а как вы хотели? =)

 

Надо же как-то продавать Enterprise AP, вот и вырубим хэндовер между обычными не анонсирующими поддержку 802.11R ни в каком виде. Муркетинг животворящий блин.

 

Такие клиенты зачастую даже в open сетях висят до последнего. =) Но благо всё больше вендоров отключают такое поведение установкой вот этой переменной в 1.

 

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

 


# Handoff Enable(1) Disable(0)

gEnableHandoff=0

 

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

 

Т.е. пользовательские соединения при этом остануться целыми (ну разве что 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 для выбора кандидата при миграции. Больше значение - меньше вероятность прилететь назад на ту же АП, но более отложенный старт миграции. 5дБ дефолтовых ИМХО маловато. Нужно иметь дельту около 8-10дБ. Для начала выставим 8.

 


RoamRssiDiff=8

 

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

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

 

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

 


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

 

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

 

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


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

 

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

 

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

 

Да и ещё:

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

 

По дефолту обычно 0. В таком режиме клиент при переходе в режим сна (часто просто при выключении экрана) полностью тушит RF часть временно просыпаясь только что бы АП его по таймауту не выпнула. При этом реализация такова что и роумингу становиться туго (зачастую). Следуюет установить его в 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ГГц АП на сяоми и некоторые One+ (как обычно намутили с анонсами в зависимости от региона, в итоге АП и клиент не могут договориться в какой полосе разговаривать).

 

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

 

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

 

PP.S. Ессно всё это будет работать только если вендор не нарукоблудил и не поотрубал поддержку этого счастья на стадии сборки драйвера. Так что тут как повезёт.

 

PP.SS. Кому не лень может наколупать прикладуху под ведроид для правки этих параметров из гуя.

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


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

Очень обидно что вся эта фигня так плохо работает из коробки и чтоб оно хоть как-то начало жить надо столько патчить.

Технологии WiFi  в обед 20 лет , а до сих пор не могут сделать все по человечески.

Массонский заговор, не иначе.

 

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


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

Раздолбайство + попытки выкружить побольше бабла из ничего. Отсюда все беды в wifi, и виноват в этом wifi альянс с его "требованиями" к сертификации. Иначе давно бы навели бы порядок просто включив многие фичи как обязательные для получения базового Logo. Но нет, будут отжимать бабло придумывая всякие программы сертификации аля VOIP Enterprise и ограничивая применимость.

 

Да, эти правки не решают проблемы band preffered, а возможно в какой-то мере усугубляют. Однако с ней можно бороться например переключив клиента в "только 5ГГц" режим (как например позволяет yotaphone). А лучше используя разные SSID для 2.4ГГц и 5ГГц сетей с полным отказом от band steering, т.к. он при попытке сваливания клиента в 2.4ГГц осложнит ему миграцию.

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


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

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

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

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

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


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

Войти

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


Войти