Jump to content
Калькуляторы

SNR-CPE поддержка, опыт эксплуатации, регрессии, результаты тестирования, общие вопросы

Можно ещё и таймауты закрутить что бы уж точно не туда не падал (по дефолту всё очень мягко).

закрутить - в смысле поднять?

а в том, чтобы повысить BndStrgRssiDiff, никакого криминала нет?

 

кстати, раз существует такой параметр - точка видит не только подключенных клиентов? нельзя ли добавить (опционально) в "Station List" видимых, но не подключенных клиентов?

 

и ещё про про band steering, я правильно понимаю, что он работает только при первоначальном подключении клиента к точке?

вот поэкспериментировал со своим телефоном (xiaomi на qualcomm), если он зацепился за точку в 2.4 (ну не видел 5 за углом), то он так и сидит в 2.4, хоть уровень в 5 и отличный.

 

нет ли мягких способов сказать клиенту "посмотри, вокруг же полно других сетей"? только kick?

 

Для подконтрольной сети, в случае необходимости именно бесшовного и максимально быстрого переключения, я бы разнёс 5GHz и 2.4GHz сети по разным SSID если это возможно, и не использовал бы band steering вовсе рассаживая клиентов в 2.4 или 5ГГц диапазоны административными методами (например с помощью терморектального криптоанализа =) )

начинаю понимать )

 

ещё вот ситуация:

одиночная точка, телефон вышел из зоны 5ГГц, в логах вижу:

Jun  5 23:38:31 kernel: 5GHz AP Disonnect STA 38:a4:ed:52:fa:e3 , RSSI Kickout Thres[-84] at last [6] seconds

телефон взял и потерял wifi вовсе, хотя уровень сигнала на 2.4ГГц неплохой. это потому, что ему сделали кик, а на 2.4 его band steering не пустил? (там стоял дефолтный BndStrgRssiLow в -88)

 

Ради интереса можете сделать nvram_set IAPPDebug 4 && reboot и посмотреть в логах

а какие ещё интересные параметры для дебага есть?

Share this post


Link to post
Share on other sites

Такого варианта нет и точно не предвидиться. Слишком дофига архитектурно менять придётся, ради кейза который нужен в 99% только WISP куда мы даже не планируем метить. У нас indoor однако. И если и будет outdoor то до массового прихода 802.11ax мы не будем планировать лезть в WISP.

В hostapd данный функционал встроен, да и это же l2 делается на уровне бриджа...

Share this post


Link to post
Share on other sites

configs/all/config-busybox:CONFIG_FEATURE_LESS_MAXLINES=0

 

Ну эт дефолт однако. Я вот не в курсе сколько там max liness верно/нужно. =)

Share this post


Link to post
Share on other sites

а в том, чтобы повысить BndStrgRssiDiff, никакого криминала нет?

 

Да нет никакого криминала. Просто эксперементально 15Дб получился максимально подходящим.

 

кстати, раз существует такой параметр - точка видит не только подключенных клиентов? нельзя ли добавить (опционально) в "Station List" видимых, но не подключенных клиентов?

 

Точка слушает в т.ч. probe req что бы ещё до подключения знать что может клиент и например сразу не отвечать дуалбэндам на probe req. Проблема в том, что новые андроиды и яблоки подменяют маки на почти рандомные при сканировании и эта инфа становиться бесполезной.

 

Сделать вывод таблицы band steering думал, но там зело геморройно будет это сделать, потому пока отложил. Но можно скомандовать iwpriv <имя нужного ифэйса радио> show BndStrgList и заглянуть в лог.

 

 

и ещё про про band steering, я правильно понимаю, что он работает только при первоначальном подключении клиента к точке?

вот поэкспериментировал со своим телефоном (xiaomi на qualcomm), если он зацепился за точку в 2.4 (ну не видел 5 за углом), то он так и сидит в 2.4, хоть уровень в 5 и отличный.

 

Принудительный отстрел отключен т.к. вызывает больше проблем чем решает. Подбирайте значения hold time что бы на стадии соединения вынудить подключиться в нужный диапазон. Разрешения куда коннектиться band steering рулит динамически исходя из данных о клиенте. В т.ч. разрешает fallback в 2.4 если то требуется, но выпинывать работающего клиента из одного диапазона сразу с запретом коннектиться в него же чревато тем что он вообще напроч теряет связь и даже не пытается коннектиться назад. А если не запрещать то лупанётся туда же. Поведение отличается от клиента к клиенту, кто-то нормально переваривает, но часто (особено безродные аппараты) такого не переносят. Потому работаем только на стадии соединения. Ну и зачастую даже если не туда цепанулись рано или поздно клиент решит поспать и со следующего пробуждения получит запрет на коннект в 2.4 если хотя бы один запрос с него был в 5ке.

 

 

нет ли мягких способов сказать клиенту "посмотри, вокруг же полно других сетей"? только kick?

 

Это 802.11 тут нет мягких способов. Даже просто сказать клиенту что бы он выполнил фоновое сканирование для выбора кандидата, или передать preffered диапазон нельзя. А вы о каких-то мягких способах.

 

ещё вот ситуация:

одиночная точка, телефон вышел из зоны 5ГГц, в логах вижу:

Jun  5 23:38:31 kernel: 5GHz AP Disonnect STA 38:a4:ed:52:fa:e3 , RSSI Kickout Thres[-84] at last [6] seconds

телефон взял и потерял wifi вовсе, хотя уровень сигнала на 2.4ГГц неплохой. это потому, что ему сделали кик, а на 2.4 его band steering не пустил? (там стоял дефолтный BndStrgRssiLow в -88)

 

Сеть с роумингом планируется так что бы при Kick с одной АП клиента обязательно могла подхватить (проходила по разрешениям) соседняя АП в том же диапазоне. Т.е. если запихали клиента в 5ГГц будьте добры его там всю дорогу сопровождать нормальным сигналом.

 

Если точка одиночная то нефиг его кикать вообще. Современные аппараты при падении уровня ниже -75 сами пытаются слезть в 2.4, сложнее их назад засунуть. Порог в BndStr так же выше сделать никто не мешает.

 

Но всегда логика хэндофа будет выше по приоритету чем логика band steering. И надо понимать когда и что применять.

 

а какие ещё интересные параметры для дебага есть?

 

Код открыт. Я не в курсе какие вам ещё интересные параметры посоветовать. =))

Share this post


Link to post
Share on other sites

Я рад за hostapd. У нас его нет, может вы уже перестаните с ним носиться? Нет у нас ни hostpapd ни wpa_supplicant. Вся логика на уровне драйверов ТЧК. В каждой бочке затычка, ей богу, со своим hostapd, буд-то без него жизни нет.

 

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

 

P.S. Пойдёт в оффтоп по надеюсь понятным причинам?

Share this post


Link to post
Share on other sites

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

то есть в процессе роуминга клиенты не пытаются поменять диапазон?

 

у меня не получается покрыть всё на 5ГГц, 5ГГц точек мало купили )))

да и смысла пока не видно покрывать всю территорию 5ГГц

 

впрочем, 5ГГц для нас пока игрушка, как я понимаю, оно актуально когда устройств много и им всем тесно в эфире.

Share this post


Link to post
Share on other sites

Зачастую пытаются свалиться в 2.4 хотя уровня и в 5ке как грязи.

 

Ну опустите лимиты хэндофа почти до упора и вырубите band steering и пусть кто хочет тот в 5ГГц и работает. Ну если вам повезло что 2.4 не стоит колом от соседского флуда.

Share this post


Link to post
Share on other sites

Код открыт. Я не в курсе какие вам ещё интересные параметры посоветовать. =))

ну проект большой, за пару минут не разберёшься

 

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

BandSteeringDebug нашёл

 

Ну эт дефолт однако. Я вот не в курсе сколько там max liness верно/нужно. =)

дефолт 9999999 обычно, почему некоторые проекты ставят 0 - непонятно, уж проще тогда less вообще выкинуть, всё равно он работать не будет.

Share this post


Link to post
Share on other sites

дефолт 9999999 обычно, почему некоторые проекты ставят 0 - непонятно, уж проще тогда less вообще выкинуть, всё равно он работать не будет.

 

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

 

Короче да. =))) Сейчас дефолт 9999999. Однако в их примерах конфигов до сих пор местами осталось 0. Что как бы намекает, что видимо когда-то дефолт таки был 0. =)))

 

Ладно, поставил 9999999 в 6.1.11 будет.

Share this post


Link to post
Share on other sites

Ну опустите лимиты хэндофа почти до упора

может лучше задрать BandDeltaRssi?

 

вырубите band steering

а если таймауты поставить маленькие-маленькие?

Share this post


Link to post
Share on other sites

1) может и лучше

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

Share this post


Link to post
Share on other sites

да, начал играться - и понял, что насильное выбрасывание клиентов, что band steering - зло.

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

 

любопытно, xiaomi уверенно переключается между 2.4/5 (отошёл подальше - ушёл на 2.4, вернулся к точке - и телефон вернулся на 5). а вот у айфона работает лишь в одну сторону, уйдя с 5 он так и остаётся на 2.4 навечно, печально.

 

 

Диапазоны это вообще по сути отдельные АП. Просто в одном корпусе и на один host cpu навешаны.

клиент вообще не знает, что это одна точка?

 

и ещё вопрос: переключение между 2.4/5 обрабатывается как обычный роуминг? настройки 802.11k/r влияют? как посмотреть - использует клиент их или нет?

Share this post


Link to post
Share on other sites

да, начал играться - и понял, что насильное выбрасывание клиентов, что band steering - зло.

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

 

любопытно, xiaomi уверенно переключается между 2.4/5 (отошёл подальше - ушёл на 2.4, вернулся к точке - и телефон вернулся на 5). а вот у айфона работает лишь в одну сторону, уйдя с 5 он так и остаётся на 2.4 навечно, печально.

 

Ну я сотни раз грил что всё зависит от корректности реализации на клиенте. Хотя яблоки разные по разному тут себя ведут. Однако при значительной дельте в уровнях пытаются валиться в 2.4 как не крути, не смотря на очень хороший запас на 5ке.

 

А работу band steering они и гугл в новых версиях сами себе осложнили начав подменять маки в probe req.

 

клиент вообще не знает, что это одна точка?

 

и ещё вопрос: переключение между 2.4/5 обрабатывается как обычный роуминг? настройки 802.11k/r влияют? как посмотреть - использует клиент их или нет?

 

1) Клиент ориентируется на SSID + MDIE (если умеет последнее, для чего он должен как минимум уметь FT). При этом что бы перемещаться между диапазонами он должен выполнить один фиг полное активное сканирование обоих диапазонов, иначе он вообще сидя на 2.4 о 5ГГц ничего знать не будет (там какраз модуль один, а не 2 как в АП).

2) Посмотреть пока только на стороне клиента (как руки дойдут вынесу в рожу). Тот же самсунг сразу выводит при подключении например WPA2-FT-PSK вместо WPA2-AES в инфо (ну при использовании PSK).

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

 

Короче гря. 802.11K/R не панацея. FT решает только проблему ускорения аутентификации при миграции, плюс добавляет MobileDomain что бы клиент был в курсе что это "одна сеть". RRM решает проблему управления эфиром (ну например может сказать клиенту как его "видит" АП, или анонсить лимиты). Но если клиент сам не умеет корректно мигрировать, и его надо пинать - ну ....

 

Кстати принудительное выпинывание на части клиентах приводит до кучи к бесполезности FT впринципе. И каждый раз вновь выпнутый клиент будет проходить полную фазу аутентификации. Хоть убейся. Такова логика на стороне клиентов.

 

Роуминг в 802.11 в общем случае можно рассматривать ровно как балансировку между АП, и на довольно редких клиентах можно видеть хоть что-то похожее на тот же DECT или GSM. Сколько бы муркетологи не пели (ну посмотрите форумы арубы, увидите всё ровно тоже самое).

 

Реализации аля ZH или аналога от мираки к роумингу отношения не имеют. И ограничения там на уровне масштабируемости по сути сводятся к томч то вся сеть имеет ёмкость как одна АП.

 

Без изменения подхода к этому делу со стороны wifi aliance ничего не выйдет. Благо сейчас уже трёхбэндовые железки на подходе, а в 60ГГц без относительно прозрачной авто миграции вообще будет Ж***А.... Ну вынуждены они будут обязать производителей в т.ч. клиентов хотя бы номинально поддерживать миграцию с человеческим лицом. Может голову включат и хотя бы пару полей в IE добавят на тему preffered band или preffered aplist...

 

А BandSteering, ну да, всю жизнь с рождения был и есть костылём для клиентов которые не умеют нормально preffered band, а таких большинство. И оно даже не особое и бы и зло бы было, если бы гугл и яблоки ради "анонимности" подменять маки клиента при сканировании. Т.е. всё решалось бы на уровне ответа или не ответа на probe в нужном диапазоне (как это изначально реализовал miraki, это ж их изначальный костыль). И с клиентами которые так не поступает сеть быстро обучается (ессно если не ребутить) и далее всё прекрасно себя чувствует. А вот если подмена во все поля, то мы не можем никак идентифицировать клиента пока он уже не решит попробовать ассоциироваться.

Share this post


Link to post
Share on other sites

айфон попросил пароль от сети - похоже, что так он отреагировал на то, что точка его сбросила.

 

Ну эт нифига. Скорее что-то у клиента взглючило. В офисе несколько 10тко яблок регулярно получают по рогам от handoff и ноу проблем.BandSteering на данный момент занимается только разрешениями и никого не сбрасывает принудительно вовсе.

Share this post


Link to post
Share on other sites

клиент вообще не знает, что это одна точка?

 

Ну дык это не одна точка, а 2 точки, причём в разных диапазонах. =))) Вот физически это даже 2 разных чипа. И по логике 2 разных сущности. То что оно в одном корпусе и сидят на одном CPU не делает их единым целым. А клиент дык и вообще вися на одной о второй до скана в обоих диапазонах ничего и не узнает.

Share this post


Link to post
Share on other sites

Скорее что-то у клиента взглючило. В офисе несколько 10тко яблок регулярно получают по рогам от handoff и ноу проблем.BandSteering на данный момент занимается только разрешениями и никого не сбрасывает принудительно вовсе.

это было "на краю" покрытия - айфон отключился (был сброшен), сеть видел, при попытке подключиться запросил пароль.

кстати, на складе (4 точки 2.4ГГц) тоже было подобное

 

сейчас получилось воспроизвести установив в -5 "Ignore auth req due to weak signal", но вроде бы нигде не трогал этот параметр.

 

И каждый раз вновь выпнутый клиент будет проходить полную фазу аутентификации. Хоть убейся. Такова логика на стороне клиентов.

а как принимается решение о необходимости получение нового адреса через dhcp? (то есть как избежать запросов к dhcp-серверу при переключении на новую точку)

Share this post


Link to post
Share on other sites

это было "на краю" покрытия - айфон отключился (был сброшен), сеть видел, при попытке подключиться запросил пароль.

кстати, на складе (4 точки 2.4ГГц) тоже было подобное

 

сейчас получилось воспроизвести установив в -5 "Ignore auth req due to weak signal", но вроде бы нигде не трогал этот параметр.

 

Скорее всего таки трогали. Или когда-то подключались к сети с таким же SSID но открытой (или с другим паролем) и не "забыли" её. Терь оно будет регулярно всплывать на этом клиенте. А если REJ при AUTH послать то с большой долей вероятности будет перезапрос ключа. Потому ограничениями в AUTH нужно пользоваться только когда и требуется подобное поведение. Например ограничение зоны покрытия (вышел из офиса, получил по рогам, попытался переподключиться, а те грят пароль не верный, в таком случае часть клиентов сразу "забудет" такую сеть, но есть и не мало исключений).

 

а как принимается решение о необходимости получение нового адреса через dhcp? (то есть как избежать запросов к dhcp-серверу при переключении на новую точку)

 

Ну а по чему у меня спрашиваете? =) Ну спросите у вендора своих клиентов как принимается решение. =))) Мной оно никак не принимается (ну не могу я влиять на поведение клиента, нет механизмов для этого). И нормальный клиент видя даже одинаковый SSID не то что MDIE не просит занова адреса, т.е. он не сбрасывает старый адрес с интерфейса, а лишь на всякий при link beat посылает запрос на продление лизы. При этом т.к. адрес остался на интерфейсе не тронутым и стэйты на месте то даже до ответа dhcp всё уже будет работать. Задача не устраивать JAM с адресами это уже задача DHCP. У нас например это решается за счёт использования хэша MAC при генерации IP.

 

Избегать запросов к DHCP не надо. Надо что бы клиент не сбрасывал адрес на интерфейсе при link beat, тогда не сбросятся и стэйты соединений на его стороне и всё будет гуд. Но тут опять таки всё исключительно клиентозависимо.

 

P.S. Если используете встроенный в точку DHCP надеюсь выключили arp ping check в его настройках? Иначе он будет пару секунд проверять не занят ли адрес арпингом прежде чем выдать новый адрес/продлить лизу.

Share this post


Link to post
Share on other sites

Я время от времени ещё эксперементирую с разными клиентами в попытках смягить последствия как band steering так и принудительного пинка. Так что ситуация будет ещё несколько улучшена (по band steering точно, тут есть несколько идей).

 

Да, там есть ещё момент когда BandSteering может на запрос AUTH послать REJ (что конечно почти исключено т.к. оно уже на стадии ассоциации отлуп получит), я уже забыл о нём. Надо убрать. Достаточно на стадии peer_assoc_req_action проверки. В тот момент уже реальный MAC клиента известен и не заменён затычкой. Если бы не яблоки с гуглом не надумали бы играть в прятки мак адреса то достаточно было бы работы исключительно на уровне PeerProbeReqAction и это бы не вызывало бы никаких проблем (собсно так оно изначально и было). Но увы...

 

Убрал в 6.1.13.

Share this post


Link to post
Share on other sites

Ну а по чему у меня спрашиваете? =)

ну так вы точно с этим разбирались ;)

 

понятное дело, что больше зависит от клиента, вопрос звучит так: что мы можем сделать, чтобы снизить вероятность получения адреса "с нуля"?

 

Задача не устраивать JAM с адресами это уже задача DHCP. У нас например это решается за счёт использования хэша MAC при генерации IP.

а какой сервер dhcp используется?

Share this post


Link to post
Share on other sites

понятное дело, что больше зависит от клиента, вопрос звучит так: что мы можем сделать, чтобы снизить вероятность получения адреса "с нуля"?

 

Ничего. Увы и ах. Тут как написана логика на клиенте так и будет. Даже ведроиды одного времени выпуска и на одних и тех же чипах могут вести себя по разному. Со стороны сети ничего не сделать, ну максимум обеспечить что бы даже в случае полного перезапроса выдавался тот же ip адрес для уже известного мака, тогда даже в ситуации когда клиент просит адрес с нуля, но не сбрасывает его на свойм интерфейсе (и такое бывает) тоже проблем не будет.

 

Просто если клиент нормальный, то он и так не чудит. А если кривой то вероятно и анонсы MobileDomain и прочее ему что мёртвому припарки. В идеале если клиент видит одинаковые MDIE+SSID+ему таки удалось мигрировать с тем же ключём это для него должно означать что вообще не надо dhcp клиента трогать, как и переконфигурить сетевой интерфейс. Плюнул пару арпов в сторону шлюза что бы ARP Table по всей DS обновились и продолжай работать... Но вот беда... "Всем срать." (с) =))

 

а какой сервер dhcp используется?

 

Да я про тот что в прошивке. А такую фишку умеет штатный бизибоксовый udhcp и dnsmasq. BIND вроде не умеет, но он не склонен генерить новый адрес если для мака уже есть лиза даже если клиент через чур настойчив.

 

 

P.S. Схемка для понимания логики как работал BandSteering до рандомизации маков яблоками и гуглом. Там хотя бы не каждый бы запрос новый мак бы был... В итоге эта схема стала бесполезна. Пришлось городить отказ в ассоциации вместо работы только на уровне probe. В итоге до момента уже непосредственного подключения мы о таком клиенте вообще нифига не знаем.

 

Плюс работа только на уровне probe req не решает проблемы с клиентами использующими passive scan, который не использует probe req а ориентируется по маякам и/или ответам АП соседям. Именно такой режим часто использутеся при background scan.

1111.png

Share this post


Link to post
Share on other sites

В продолжение темы сканера... Попал мне в руки наконец W4N rev.M, сразу же прошил его на 6.1.20(со сбросом rwfs) и сбросил кнопкой после этого. Во всех случаях в сканере пусто(пробовал даже разные обозреватели, AdBlock отключен).

post-107486-083325700 1500031126_thumb.gif

Share this post


Link to post
Share on other sites

Только что проделал все то же самое, результат в IE и firefox положительный.

При обновлении галку Replace (update) RWFS не снимали? кнопку со сбросом точно дожали? выполните сброс через веб

В каком браузере(и версию браузера) проверяете? маловероятно, но может быть эфир ваш чист от AP?)

Share this post


Link to post
Share on other sites

Выше писал, что со сбросом rwfs. Кнопку дожал(10 секунд и перезагрузка). Через web сбрасывал. Потом ещё раз кнопкой, чтобы наверняка.

Проверял в последних версиях Firefox и Chrome(и даже в старом IE).

Share this post


Link to post
Share on other sites

Выше писал, что со сбросом rwfs. Кнопку дожал(10 секунд и перезагрузка). Через web сбрасывал. Потом ещё раз кнопкой, чтобы наверняка.

Проверял в последних версиях Firefox и Chrome(и даже в старом IE).

Для диагностики, запустите в Chrome консоль (F12/Ctrl-Shift-I) и покажите вывод (как показано на скриншоте)

post-135592-028269300 1500036257_thumb.png

Share this post


Link to post
Share on other sites

В Chrome внезапно заработало. А вот в Firefox нет. Все расширения отключены, настройки по умолчанию. Причём видно, что ответ пришёл, но не отображает:

post-107486-010614200 1500038370_thumb.gif

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now