[Ferdin]

http://wiki.openwrt.org/doc/uci/wireless#fast_bss_transition_options

Конфиг:

http://lists.shmoo.com/pipermail/hostap/2008-May/017762.html

Ну и hostapd.conf курите, там, например, можно 802.11f включить.

По настройки 802.11r там тоже всё расписано.

https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf

Вы сами это (курили), я же говорю без танцев с бубном роуминг на openwrt настроить не возможно.

[NewUse]

Вы сами это (курили), я же говорю без танцев с бубном роуминг на openwrt настроить не возможно.

Какие танцы, конфиг из примера рабочий. Я юзал конфиг из http://yuantl.cafe24.com/wp/wp-content/uploads/2014/04/Hostapd_Configuration.pptx и ftp://www.linux-magazine.com/pub/listings/rasp-pi-geek.com/04/AccessPoint/Listing04.txt, кажись, но суть одна, настраивается не сложно, другой вопрос, нужно ли это на самом деле...

Изменено 23 октября, 2015 пользователем NewUse

[Saab95]

На самом деле нужно что бы точки были подешевле и их можно было поставить побольше.

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

[Tonchi]

Что из себя представляют эти контроллеры.

Также интересно, что из себя представляет контроллер Микротика? где о нем можно почитать?

 

На микротике не нужен никакой капсман, просто ставите точки, настраиваете один SSID и шифрование, распределяете по каналам, настраиваете ограничение по уровню сигналов, что бы тока откидывала клиента. Тогда клиент понимает, что связи нет и сразу же начинает подключение ко всем доступным точкам. В этом случае самое минимальное время простоя и ничего не обрывается.

 

Вторая проблема, это сетевая модель по которой работает сеть. Если абонент переключился от одной точки на другую, то он на ней должен иметь такой же доступ до шлюза, что и на первой. Тогда опять же не будет никаких обрывов.

 

Все другие вендоры стоят в разы дороже.

А что делать в случае с настроенным хотспотом? не вариант скидывать клиента с точки 1 на точку 2 и повторно проходить аутентификацию.

 

У меня время простое меньше полсекунды, а порой и быстрее, даже пинги не теряются.

Каким способом? тем что вы описали выше? очень заинтересовал именно ваш метод и вариант реализации.

P.S. А что если все точки объединить Cloude Core серверов?

[sfstudio]

просто ставите точки, настраиваете один SSID и шифрование, распределяете по каналам, настраиваете ограничение по уровню сигналов, что бы тока откидывала клиента. Тогда клиент понимает, что связи нет и сразу же начинает подключение ко всем доступным точкам. В этом случае самое минимальное время простоя и ничего не обрывается.

Я выше разжовывал почему это работает раз через раз в части обрывов. Всё зависит от конкретной реализации на клиенте и повлиять на это вы никак не можете. Дропает ip у себя на ифэйсе и/или контрак клиент по link down - будут обрывы, не дропает - не будет. А реализация оного в андроиде например зависит от чипмэйкера который писал драйвер и логику со стороны wpa_supplicant. Плюс при этом с большой долей вероятности клиент решит заново получить адрес и инициирует полную процедуру перезапроса оного у dhcp.

 

Более того, без поддержки FT нужна полная фаза реаутентификации при каждой миграции, что само достаточно накладно.

 

Далее ещё ошибка, клиент не начинает подключения ко всем доступным точкам, это шизофрения. Клиент делает ap_scan (тоже время) либо использует данные фонового сканирования (что быстро, но далеко не везде реализовано + для того же интела фоновое сканирование например приходиться отрубать иначе в нормальном режиме затыки раз в несколько секунд лезут), сортирует эти данные по RSSI и выбрав точку с более высоким уровнем пытается инициировать соединение с ней.

 

Вторая проблема, это сетевая модель по которой работает сеть. Если абонент переключился от одной точки на другую, то он на ней должен иметь такой же доступ до шлюза, что и на первой. Тогда опять же не будет никаких обрывов.

 

А вот хрен. Минимум должно кроме этого соблюдаться ещё и условие неизменности IP адреса иначе в трэкинге на клиенте все соединения умрут. Т.е. самый простой вариант это плоская L2 сеть с выделенным dhcp сервером.

 

Все другие вендоры стоят в разы дороже.

 

Ну да. Однозначно 20 баксовый SNR дороже. =) И в отличии от вашего микротика имеет не одну крутилку, а возможность покрутить даже ограничения когда точка вообще будет игнорировать те или иные типы запросов от клиентов, или число неудачных перепосылок фрэймов клиенту.

 

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

[Дегтярев Илья]

sfstudio, а добавь в своих прошивках модуль vxlan в сборку ядра. Он в ядре есть с 3.13

Соответственно в конфиге задается ip хаба и id.

Интерфейс поднимается с ip link add vxlan0 type vxlan id _id_ remote _ip_ dstport 0

С vxlan0 интерфейсом в бридж объединяется wifi (либо отдельные вланы созданные над vxlan0).

 

Со стороны хаба ip link add vxlan0 type vxlan id _id_ remote 0.0.0.0

и bridge dev vxlan0 hairpin on дают возможность коммутации между собой всех точек внутри этого l2 туннеля.

 

Получаем полноценный L2 между всеми WiFi сегментами без необходимости по внешней сети тянуть эти VLANы.

Хаб сам динамически изучает за каким хостом в туннели находится определенный mac и туда отправляет пакеты к нему.

[sfstudio]

Не представляю какую проблему предлагается решать. Загнать всех в L2 поверх L3?

 

Но я пока не планирую уходить с 3.4 (начиная с 3.5 в апстриме принят ряд крайне неприятных с точки зрения производительности на мелких железках патчей, на которые уже завязали тонну другого кода). Уж больно длинный квест на новых ядрах что бы производительность на не SMP системах без L2 кэша дотянуть до приемлемого уровня по сети проходить придётся. Проще бэкпортить то что действительно нужно. Собсно наша ветка 3.4 очень сильно отличается от 3.4.110, отслеживаю все фиксы в апстриме включая дырки безопасности и каждое изменение проверяю как на предмет стабильности так и на предмет производительности. Пока особой нужды в переходе на совсем новые ядра нет, 3.4 всё ещё поддерживается, а значит пока будем на нём, дальше посмотрим. На 4.1 ситуация с провалом производительности больше чем в 2 раза по сравнению с голым 3.4 на 7620 практически не сдвинулась с мёртвой точки, подождём в какую сторону дальше будет ветер дуть, там решим.

 

Тут недавно народ L2TPv3 для этого (для бриджевания на L2 сетей поверх L3 сети) приюзывал на wive, по дефолту тоже не собирается но поправить одну опцию.

 

Да и смысла не видно т.к. время отклика будет явно не то что и при плоской L2 проводом, а тут каждая мс на счету.

[Дегтярев Илья]

Небольшая кампусная сеть.

Роутеры используются как неуправляемые 5-портовые коммутаторы на комнату и включаются в управляемые этажные с настроенным

first-hop security, т.е. с ip source guard. Для проводной сети авторизация по мак+порту управляемого коммутатора.

 

Просто сбриджевать WiFi клиентов в такую сеть нельзя - им придется каждый раз переполучать ip при переходе на другую точку.

Поэтому трафик со всех WiFi отдается в vxlan туннели, которые коммутируются уже на сервере.

 

Сейчас все сделано на openwrt и точках на атеросе+hostapd

[sfstudio]

Т.е. опять предлагается решать административные проблемы техническими средствами. Т.е. вместо того что бы разобраться с сетью предлагается нагородить странных зверушек поверх. Я даже допускаю что это как-то будет работать.

 

Как минимум пока не буду смотреть в эту сторону, нет физически времени на реализацию и отладку извращений (из запланированного сделано 10%, не до чего-то редкого) для 1,5 сетей в мире. Как будет нечем заняться обязательно посмотрю что можно сделать. Ну и по дефолту включать такие вещи не вижу смысла, место жрёт, лишнюю логику так или иначе в ядре добавит с прогнозируемым падением производительности, было бы ради чего. Юзкей-то крайне редкий и не целевой. Не стремимся мы объять необъятное. Хотя никто не мешает обнимать оное самостоятельно, конфигурация и сборка прошивки дело не сложное если чуть чуть голову приложить, для этого всё сделано, дальше упрощать не куда.

[Дегтярев Илья]

И, кстати, для WPA2 preauth не так важны задержки.

Если все wlan интерфейсы в одном L2 сегменте, то клиент не отключаясь от текущей точки через нее обращается на MAC точки с большим сигналом и выполняет WPA преавторизацию. После этого без разрыва переключается на нее.

[sfstudio]

Причём тут preauth? Я вроде о нём речи вообще не вёл. Да и грю кто-бы вендорам всяких мобильных телефонов рассказал бы лучше о всех этих плюшках. А то вот на руках тонна планшетов от разных китайцев, телефоны от лыжи, и прочие железяки, и никто не умеет FT совсем, как и о preauth на 802.1x (не смотря на то что юзается банальный wpa_supplicant). Вот такая бяда.

 

Так что не ломайте если работает.

[sfstudio]

Поcмотрел я что там с vxlan... В общем добавлено оно давно 2012-10-01 vxlan: virtual extensible lan. Но до сих пор активно пилиться. И судя по коммитам для нормальной работы потребовалось внести изменения по всей net подсистеме. Логика до конца не устаканилась до сих пор. Так что бэкпортить я его точно не буду. Если когда-нить для текущих девайсов перейдём на 4.х ядра то можно будет посмотреть пристальней. Но пока точно нет. Если уж так надо L2 over L3 стоит глянуть в строну L2TPv3, народ проверял работает.

[NewUse]

Да хоть обычный GRE-tun или упрощённый EoIP(есть ядерный вариант), ну нужен этот сыр-бор полуторам калекам....

[XuHT]

Как я понял, бесшовного как такового, нет. Есть полумеры, типо таких, как сбрасывания клиента по уровню сигнала чтобы тот сам переключился к наилучшей ап. И тут уже зависит от клиента.

И выходит, что контроллер у микротика нужен всего лишь для единой настройки для нескольких ап. К тому же косяк в том, что если проподант связь до контроллера, то ап просто перестает работать. В убнт, получается, даже полезней будет. Там хоть графики коасивые рисует, статистика.

Все таки интересно знать всю процедуру подключения к ап. Только не гоните читать стандарт :)

[sfstudio]

1) Всё именно так (выкинуть и не пущать под благовидным предлогом пока опять уровни не подтянуться), тем более МТ не умеет 802.11K/R ни в каком виде. А из конфигурации роуминга в части радио доступна аж одна крутилка.

2) Бесшовный в полном смысле этого слова это выше обсуждаемые варианты когда вся сеть прикидывается одной АП, но это дикий хак со всеми вытекающими.

3) Ну дык гугл поможет, есть и разжованное на русском, а пересказы написанного нынче не дёшевы.

[nemo]

Как я понял, бесшовного как такового, нет. Есть полумеры, типо таких, как сбрасывания клиента по уровню сигнала чтобы тот сам переключился к наилучшей ап. И тут уже зависит от клиента.

И выходит, что контроллер у микротика нужен всего лишь для единой настройки для нескольких ап. К тому же косяк в том, что если проподант связь до контроллера, то ап просто перестает работать. В убнт, получается, даже полезней будет. Там хоть графики коасивые рисует, статистика.

Все таки интересно знать всю процедуру подключения к ап. Только не гоните читать стандарт :)

Если нет поддержки спец протоколов, как у большинства клиентов, то очень многое зависит как клиент отрабатывает.

В принципе у нас перекидывает на определенную точку контроллер, не тупо по уровню сигнала, а наблюдая историю перемещений клиента. Потом посылается либо деасоциация, либо требование переключиться на другую точку.

[sfstudio]

В принципе у нас перекидывает на определенную точку контроллер

Как перекидывает если куда перецепиться решает клиент? Блокирует нафиг клиента на остальных на время пока не ассоциируется ибо других механизмов нет?

 

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

Что за требование такое? =)

 

Ну нет никаких требований. Есть возможность деассоциировать клиента с разными reason но это один фиг деассоциация. Обратная ассоциация может быть полной или с использованием одного из обсуждаемых выше механизмов.

 

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

 

Именно поэтому и городят всякие ZH что бы обойти куцость клиентов да и вообще всего 802.11 при этом оставаясь совместимым.

 

Контроллер это конечно прекрасно, и обходными путями можно даже рулить куда пересадить клиента (см пример выше), но всё это опять таки костылины... Отстрелы по рэйту/уровню/числу ошибок не требуют контроллера как такового. Как и ограничения что бы клиент не падал куда попало. Максимум можно именно эти моменты сделать несколько гибче, но проблему оно не решает.

 

К сожалению в 802.11 везде так, куда не коснись сплошные костыли.

 

Кстати Band Steering работает по той же логике. ;( Но там хоть внутри одной железки быстрое переключение предусмотрено без полной фазы. И опять таки что бы полноценно работало клиент должен знать о его существовании. В общем мрак. Я когда брался не думал что всё так грустно, а сейчас когда уже разочарование, боль и ужас пережиты ничему не удивлюсь.

 

Вот все reason`ы возможные в 802.11:

#define REASON_RESERVED                 0
#define REASON_UNSPECIFY                1
#define REASON_NO_LONGER_VALID          2
#define REASON_DEAUTH_STA_LEAVING       3
#define REASON_DISASSOC_INACTIVE        4
#define REASON_DISASSPC_AP_UNABLE       5
#define REASON_CLS2ERR                  6
#define REASON_CLS3ERR                  7
#define REASON_DISASSOC_STA_LEAVING     8
#define REASON_STA_REQ_ASSOC_NOT_AUTH   9
#define REASON_INVALID_IE               13
#define REASON_MIC_FAILURE              14
#define REASON_4_WAY_TIMEOUT            15
#define REASON_GROUP_KEY_HS_TIMEOUT     16
#define REASON_IE_DIFFERENT             17
#define REASON_MCIPHER_NOT_VALID        18
#define REASON_UCIPHER_NOT_VALID        19
#define REASON_AKMP_NOT_VALID           20
#define REASON_UNSUPPORT_RSNE_VER       21
#define REASON_INVALID_RSNE_CAP         22
#define REASON_8021X_AUTH_FAIL          23
#define REASON_CIPHER_SUITE_REJECTED    24
#define REASON_DECLINED                 37
#define REASON_QOS_UNSPECIFY              32
#define REASON_QOS_LACK_BANDWIDTH         33
#define REASON_POOR_CHANNEL_CONDITION     34
#define REASON_QOS_OUTSIDE_TXOP_LIMITION  35
#define REASON_QOS_QSTA_LEAVING_QBSS      36
#define REASON_QOS_UNWANTED_MECHANISM     37
#define REASON_QOS_MECH_SETUP_REQUIRED    38
#define REASON_QOS_REQUEST_TIMEOUT        39
#define REASON_QOS_CIPHER_NOT_SUPPORT     45
#define REASON_DISASSOC_DUE_TO_BSS_TRANSITION_MANAGEMENT        12
#define REASON_FT_INVALID_FTIE                          55

 

Скажете какой говорит клиенту пересесть на соседа? =)

[NewUse]

А мне кажется что-то то ли в r,то ли в k , то ли v то ли w похожее попадалось, передаётся bssid новой точки клиенту но в любом случае требуется поддержка со стороны клиента...

 

может оно:

#define REASON_DISASSOC_DUE_TO_BSS_TRANSITION_MANAGEMENT 12

[sfstudio]

Это для 802.11v. Более того это один фиг деассоциация по полной, только при выборе новой AP будут использованы не данные сканирования, а данные о топологии сети летающие собсно в этой сети. Т.е. исключается необходимость пассивного или активного сканирования и только. Решение опять принимает клиент. Ну и поддержку опять таки в живую на клиентах ещё поискать надо, сущность ещё более редкая чем K/R.

 

Опять таки просматривая код по поддержке 802.11v складывается впечатление что это дикая наркомания с проксированием арпов и прочей фигнёй. Может я конечно не верно понимаю как это работает, да и из кода там не совсем ясно. Но в любом случае так и так это деассоциация ;(

 

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

[sfstudio]

В общем-то 802.11K+R+V даст практически искомое, и уверен что именно оно в моторашках с определёнными хаками и юзается, но у меня один чёрт язык не повернётся назвать это прозрачным и прям быстрым. Хотя при должном уровне поддержки со стороны клиента возможно будет близко к GSM.

 

Однако всё это у меня ни с чем кроме как с костылями не ассоциируется ;(

[nemo]

В общем-то 802.11K+R+V даст практически искомое, и уверен что именно оно в моторашках с определёнными хаками и юзается, но у меня один чёрт язык не повернётся назвать это прозрачным и прям быстрым. Хотя при должном уровне поддержки со стороны клиента возможно будет близко к GSM.

 

Однако всё это у меня ни с чем кроме как с костылями не ассоциируется ;(

На память не помню - что-то было с Roaming, через 2 недели могу глянуть если будет актуально. Сейчас в дороге.

Вообще верно, все это костыли, потому как стандарт на это плевал. Ну и конечно каждый выкручивается как может. Потому как задача стоит, а стандарта нет. Собственно все крупные вендоры каждый по своему ее решил. Везде свои плюсы и минусы. Но самый неправильный подход это рубить клиента по уровню сигнала. Потому как у нас клиент отошел далеко, и рядом с ним нет точек - так его рубят. Отошел не очень далеко, но под другую точку - так он все равно завязан на дальнюю точку. Это вообще ужас - так ни одна более менее крупная или серьезная сеть работать нормально не будет.

[sfstudio]

Вообще верно, все это костыли, потому как стандарт на это плевал. Ну и конечно каждый выкручивается как может. Потому как задача стоит, а стандарта нет.

 

Ну вообще типа есть аж стопка, только толку нету.

 

Собственно все крупные вендоры каждый по своему ее решил.

 

Именно поэтому и нету толку.

 

Везде свои плюсы и минусы.

 

Везде сплошные минусы. =))

 

Но самый неправильный подход это рубить клиента по уровню сигнала. Потому как у нас клиент отошел далеко, и рядом с ним нет точек - так его рубят. Отошел не очень далеко, но под другую точку - так он все равно завязан на дальнюю точку. Это вообще ужас - так ни одна более менее крупная или серьезная сеть работать нормально не будет.

 

Не поверите, но все именно так и работают включая вашу. Ибо опять таки клиент это не AP и маяки не рассылает, т.е. планировать его перемещение можно только косвенно. Обрубание при выходе из зоны это вообще плюс а не минус. Держать полумёртвого клиента в ущерб остальным только потому что нет дальше АП редкая тупость. Либо ставь ещё АП и расширяй зону, либо нефиг выдумывать. Логика отстрела и непускания должна быть комбинированная, такая она у нас и есть. С ней как раз проблем нет, как и с миграцией между зонами обслуживаемыми разными АП (даже с омни неплохо вышло, но нужны сектора). Вся проблема в том что требуется так и так пройти процедуру ассоциации с новой АП клиенту и с момента отстрела клиента и до нового его коннекта клиент сам по себе и никак не управляется. И ничего с этим в рамках 802.11 не ломая совместимости не сделать. Остаётся полагаться что на клиенте миграция реализована не как попало. Было бы это везде так то и 802.11K+R+V было бы достаточно. Но увы.

 

Ваши моторы работают ровно в тех же и ровно с теми же условиями. Контроллер чуть расширяет возможности принятия решений, но не решает проблемы. Как было это набором костылей так увы и останется.

 

Вариации на тему ZH решают проблему с миграцией целиком и полностью, но несут другие менее очевидные проблемы даже если забить на ёмкость такой сети.

[nemo]

Не поверите, но все именно так и работают включая вашу. Ибо опять таки клиент это не AP и маяки не рассылает, т.е. планировать его перемещение можно только косвенно. Обрубание при выходе из зоны это вообще плюс а не минус. Держать полумёртвого клиента в ущерб остальным только потому что нет дальше АП редкая тупость. Либо ставь ещё АП и расширяй зону, либо нефиг выдумывать. Логика отстрела и непускания должна быть комбинированная, такая она у нас и есть. С ней как раз проблем нет, как и с миграцией между зонами обслуживаемыми разными АП (даже с омни неплохо вышло, но нужны сектора). Вся проблема в том что требуется так и так пройти процедуру ассоциации с новой АП клиенту и с момента отстрела клиента и до нового его коннекта клиент сам по себе и никак не управляется. И ничего с этим в рамках 802.11 не ломая совместимости не сделать. Остаётся полагаться что на клиенте миграция реализована не как попало. Было бы это везде так то и 802.11K+R+V было бы достаточно. Но увы.

Не поверите, но таки ведется клиент по точкам. И отрубается он когда есть точка лучше.

[sfstudio]

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

[Saab95]

Далее ещё ошибка, клиент не начинает подключения ко всем доступным точкам, это шизофрения. Клиент делает ap_scan (тоже время) либо использует данные фонового сканирования (что быстро, но далеко не везде реализовано + для того же интела фоновое сканирование например приходиться отрубать иначе в нормальном режиме затыки раз в несколько секунд лезут), сортирует эти данные по RSSI и выбрав точку с более высоким уровнем пытается инициировать соединение с ней.

 

Когда я вижу в логах 3-4 соседних точек, что к ним в одно и то же время приходит запрос на подключение, а потом все, кроме той, куда подключился клиент, получают в логах что-то вроде ("клиент подключился к другой AP"), то очень сложно поверить, что клиент делает что-то другое.