Перейти к содержимому
Калькуляторы

Wive-NG-MT роуминг примеры настроек для различных случаев/нюансы

С 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 секунд и пересканировать всё.

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


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

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

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


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

Как заставить Linux клиентов бесшовно мигрировать читаем тут https://wi-cat.ru/2018/02/17/besshovnaya-migraciya-rouming-wi-fi-dlya-linux-klientov/

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. В статистику так же попали клиенты которые выходили в течении дня из офиса с включенным радио. Т.к. им просто не куда было мигрировать, то гарантированно отхватывали пинка. Надо будет в следующих раз отфильтровать это дело. Т.е. в реальности ситуация несколько лучше.

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


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

Как заставить Andorid клиентов на чипах qualcomm бесшовно мигрировать в wi-fi https://wi-cat.ru/2018/02/17/besshovnaya-migraciya-rouming-wi-fi-dlya-android-klientov/

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


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

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

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

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

 

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


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

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

 

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

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


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

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас