С 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 мало кто умеет (даже яблоки не используют) и у той же циски так же по дефолту отключено.

 

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

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


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

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

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

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

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


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

Войти

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


Войти