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

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

 

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

 

 

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

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

 

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

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


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

да, начал играться - и понял, что насильное выбрасывание клиентов, что 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, это ж их изначальный костыль). И с клиентами которые так не поступает сеть быстро обучается (ессно если не ребутить) и далее всё прекрасно себя чувствует. А вот если подмена во все поля, то мы не можем никак идентифицировать клиента пока он уже не решит попробовать ассоциироваться.

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


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

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

 

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

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


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

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

 

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

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


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

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

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

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

 

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

 

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

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

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


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

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

кстати, на складе (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 в его настройках? Иначе он будет пару секунд проверять не занят ли адрес арпингом прежде чем выдать новый адрес/продлить лизу.

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


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

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

 

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

 

Убрал в 6.1.13.

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


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

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

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

 

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

 

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

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

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


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

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

 

Ничего. Увы и ах. Тут как написана логика на клиенте так и будет. Даже ведроиды одного времени выпуска и на одних и тех же чипах могут вести себя по разному. Со стороны сети ничего не сделать, ну максимум обеспечить что бы даже в случае полного перезапроса выдавался тот же 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

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


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

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

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

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

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


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

Войти

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


Войти
Подписчики 0