[NewUse]

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

 

Как посмотреть параметры конфигурации на нерутнотом деваисе я пока не нашёл....

 

 

В общем жду ваших мыслей, предложений и информации...

[slv700]

Следует иметь в виду, что поддержка роуминга ( 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 в защищенной сети?

[sfstudio]

Вот абсолютно по барабану защищённая там 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. Т.е. сеть открытая по определению.

[sfstudio]

В общем жду ваших мыслей, предложений и информации...

 

На сайте wifi альянса есть база сертифицированного ими железа. Там можно в общем-то достаточно точно увидеть кто и что по факту умеет. Однако остаётся нюанс. Тот же Galaxy S5 до обновления на 6.0.1 не имел проблем с роумингом, т.е. соединения оставались на месте, и мигрировал сам. На 6.0.1 его то болтает самостоятельно по AP почти не предсказуемо (лечиться ребутом телефона примерно на час), то наоборот залипает пока его не выпнут. При этом при миграции дропает адрес и как следствие стэйты, в результате обрыв соединений приложение. При этом он точно умеет как минимум FT и весь из себя сертифицирован.

 

Откатываемся на 5ку - вауля... Но с 5кой у него свои тараканы.

 

В общем раздолбайство.

 

Яблоки в этом смысле (из массовых девайсов) оказались самыми предсказуемыми, хотя поведение их сильно отличается от поколения к поколению как устройства так и iOS. Опять же см линк выше.