NewUse Опубликовано 24 мая, 2017 · Жалоба Собственно, во многих соседних темах поднимался вопрос роуминга, но как известно, за исключением крайне специфических кейсов поддержка роуминга лежит чуть ли не полностью на стороне клиента, предлагаю создать wiki или для начала просто табличку с названиями моделей смартфонов, версий прошивок, и опций включённых в wpa_supplicant.conf. А также методики получения данных. В рутованных андроид-деваисах данные получить достаточно просто: смотрим с помощью, например, es_file_explorer по адресу /data/misc/wifi/wpa_supplicant.conf на предмет строк начинающихся со слов: passive_scan fast_reauth driver_param dot11RSNAConfigPMKLifetime dot11RSNAConfigPMKReauthThreshold dot11RSNAConfigSATimeout bss_max_count autoscan filter_ssids okc dtim_period beacon_int interworking auto_interworking ftm_responder ftm_initiator max_bss_load req_conn_capab mbo_cell_capa bgscan proto mixed_cell proactive_key_caching wpa_ptk_rekey group_rekey erp ap_max_inactivity dtim_period beacon_int disable_ht disable_ht40 disable_sgi disable_ldpc ht40_intoleran disable_max_amsdu disable_vht fst_group_id Как посмотреть параметры конфигурации на нерутнотом деваисе я пока не нашёл.... В общем жду ваших мыслей, предложений и информации... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 26 мая, 2017 · Жалоба Следует иметь в виду, что поддержка роуминга ( handover) со стороны AP и клиента состоит, как минимум, из двух фаз. 1) поддержка поиска новой AP, дисконекта от старой AP и передача сетевого соединения по радио PHY - L1, MAC -L2 клиента к другой AP - Re-association. Важным в этой фазе роуминга является не только и не столько минимизация времени переключения , а главное при смене AP должно сохраняться логическое соединение Session L5 между клиентом и сетью ( но на другом AP) - нормально происходит Re-accociation с новой AP. Простой практический , часто встречающийся, пример. При первом подключении клиента к AP с функцией HotSpot при запросе http ( application L5) происходит редирект клиента на Captive portal ( страницу приглашения HotSpot splash pages). Очевидно, что при смене точки доступа, а также при кратковременном выходе клиента из зоны покрытия AP и возврата назад клиент НЕ ДОЛЖЕН снова редиректиться на Captive Portal. Для этого новая точка доступа AP при переходе к ней клиента от другой AP ( находящейся с новой AP в роуминге) должна знать что клиент-старый - ничего на L2, L3/L4 ( в частности IP адрес) не изменилось, а изменился только коннект по радио PHY от одной AP к другой AP и сессия на L5 осталась без изменений. И собственно вопрос состоит в том , а какой функционал должен поддерживать клиент, чтобы эта фаза роуминга ( реассоциация) проходила правильно, без пропусков необходимых этапов и отказа клиенту в handover? Что произойдет с соединением клиента с AP, если клиент что то не поддерживает? Есть ли критические требования к клиенту, без наличия которых handover в принципе НЕвозможен? 2) поддержка аутентификации (реаутентификации) при защищенном WPA2 доступе при переходе от одной AP к другой AP. То есть передача защищенной сессии соединения клиента на L5 сетевом уровне от одной AP к AP ( без повторной аутентификации). И собственно вопрос состоит в том , а какой функционал должен поддерживать клиент, чтобы эта фаза ( WPA2 Re-authentification ) роуминга проходила правильно, без пропусков необходимых этапов и отказа клиенту в handover в защищенной сети? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 28 июля, 2017 · Жалоба Вот абсолютно по барабану защищённая там WPA2 (а что WPA2 бывает не защищённая? =))) хоть вообще Open. Основная проблема не в аутентификации, её может вообще не быть. И проблема с каптив порталами притянута за уши ибо сети такие обычно "плоские" с изоляцией на L2. Основная проблема в дропе state`ов соединений на стороне клиентов при миграции (не важно сам он решил мигрировать или его выпнули). Как пример. i3160 не умеет ничего из K/R и даже не знает о них. При этом прекрасно мигрирует и соединения не дропаются, iperf продолжает спокойно бежать. Samsung Galaxy A5 знает и о K и о R и так же без проблем мигрирует. Более того i3160 под Linux при использовании WEXT при каждой миграции вызывает событие link beat со сбросом адреса на интерфейсе (привет соединениям от приложений т.к. стэйты в ядре тоже сразу сфлушаться), запросом нового у dhcp и т.д. Т.е. хоть защищённая, хоть открытая сеть будет обрыв соединений приложений. Терь просто переключаем его на использование NL80211 API, в итоге видим что при переходе между AP нет никаких link beat с вызовом ifplugd и повторных перезапросов. Нет обрывов соединений и т.д. В Android (в большинстве своём) на BCM и QCA радио миграцией заведует не суппликант, а драйвер. Т.е. SME (Station Management Entity) реализовано на стороне драйвера, а не суппликанта. Вот корректность хэндовера на 99% зависит от корректности реализации MLME+SME в драйвере. А суппликант вообще под андроид собирается с флагом NO_ROAMING (выкачайте сырцы суппликанта или всего ведроида и убедитесь). Нет никакого смысла составлять подобные таблички с просмотром конфига суппликанта. В лучшем случае там вы увидите что умеет сам суппликант (т.е. с какими опциями он собран и какие активированы по дефолту). А вот что именно умеет драйвер и с какими флагами его собрал вендор это уже вопрос более интересный. Я уже приводил линк, приведу ещё раз http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/device_classification_guide.html Ну и вторая проблема время затрачиваемое клиентом на поиск кандидата, читай сканирование (особенно при принудительном спинывании) если клиент не умеет RRM (который в андроидах так же реализуется на уровне драйвера, всё в том же SME) и background scan. Линки по проблеме в описании циски так же приводил. Там же и описание логики переключения от яблока, можно ещё у Арубы кой чего подсмотреть. Вот тут уже может быть отвал вообще тупо по таймауту ибо полное активное сканирование обоих диапазанов длиться вплоть до 5-6с. Просто упёрлись рогом в эту самую аутентификацию которая далеко не самое узкое место при миграции даже в случае с WPA Enterprise который сам по себе в 99% случаев не упился. А хотспоты все поголовно помнят клиента по MAC`у и никаких проблем миграция там не вызывает от слова совсем. И никакого повторного запроса аутентификации не будет. Нюансы реализации в данном случае слабо интересны. Там есть другие проблемы, не связанные с тем что используется на доступе. Хоть вообще провод. Более того, странное желание юзать captive portal поверх "защищённой" сети. Их юзают как раз там (в 99,9% случаев) где нет никакого WPA. Т.е. сеть открытая по определению. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 28 июля, 2017 · Жалоба В общем жду ваших мыслей, предложений и информации... На сайте wifi альянса есть база сертифицированного ими железа. Там можно в общем-то достаточно точно увидеть кто и что по факту умеет. Однако остаётся нюанс. Тот же Galaxy S5 до обновления на 6.0.1 не имел проблем с роумингом, т.е. соединения оставались на месте, и мигрировал сам. На 6.0.1 его то болтает самостоятельно по AP почти не предсказуемо (лечиться ребутом телефона примерно на час), то наоборот залипает пока его не выпнут. При этом при миграции дропает адрес и как следствие стэйты, в результате обрыв соединений приложение. При этом он точно умеет как минимум FT и весь из себя сертифицирован. Откатываемся на 5ку - вауля... Но с 5кой у него свои тараканы. В общем раздолбайство. Яблоки в этом смысле (из массовых девайсов) оказались самыми предсказуемыми, хотя поведение их сильно отличается от поколения к поколению как устройства так и iOS. Опять же см линк выше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...