Перейти к содержимому
Калькуляторы
2 минуты назад, alibek сказал:

У меня контроллер хотспота сейчас находится на сервере. На точках доступа UniFi используется редирект — поскольку контроллер хотспота не пропускает через себя клиентский трафик, а только авторизует клиентов.

А в скором времени всю логику авторизации я планирую вообще переместить на аппаратный BRAS (Ericsson SE100). И тогда Captive Portal в беспроводной сети я вообще отключу, в нем не будет смысла.

Так нормальное решение. Но вот только одна проблема- когда клиент переходит на новую ТД , то ваш UniFi  каждый раз  редиректит его на внешний сервер. Этому потому что  UniFi не поддерживает handover 

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


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

6 минут назад, slv700 сказал:

Ну конечно, вы в таких порталах  реализуете функции handover. Я так и знал. Но обычный  web сервер это не умеет, и делать это самому - опять самописы самосборы...

при чём здесь хэндовер, или ТД: портал о них вообще ничего не знает, портал работает с l2 запросами, а ТД просто предоставляют L2 среду, и пофиг, свитчи ли это, адсл, досис или беспроводная ТД.

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


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

4 минуты назад, NewUse сказал:

И порог ставится не на ТД, а на клиенте,

И где же вы на cамом клиенте типа Apple ставите порог дисконекта ? 

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


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

2 минуты назад, slv700 сказал:

Так нормальное решение. Но вот только одна проблема- когда клиент переходит на новую ТД , то ваш UniFi  каждый раз  редиректит его на внешний сервер. Этому потому что  UniFi не поддерживает handover 

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

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


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

Только что, slv700 сказал:

Но вот только одна проблема- когда клиент переходит на новую ТД , то ваш UniFi  каждый раз  редиректит его на внешний сервер.

Конкурентов нужно изучать, чтобы не говорить некрасивые глупости.

Вранье это.

В контроллере UniFi есть определенные недостатки, о которых я напишу чуть ниже.

Но уже авторизованные на портале клиенты никогда не редиректятся, они сразу получают сервисы.

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

А если функцию Captive Portal с беспроводной сети убрать вообще и переместить ее на отдельное устройство (BRAS), то эта проблема исключается в принципе.

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


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

Только что, slv700 сказал:

И где же вы на cамом клиенте типа Apple ставите порог дисконекта ? 

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

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


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

15 минут назад, NewUse сказал:

портал работает с l2 запросами,

   Ваша проблема - вы на сервер авторизации или   web -сервер  HotSpot возлагаете задачу обработки каких то L2 запросов. Этот сервер вообще может быть в L3 сети и находиться за тысячи км от ТД.

 

10 минут назад, NewUse сказал:

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

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

 

13 минут назад, alibek сказал:

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

Это следствие того, что UBNT не поддерживает handover. Если  в сети  WPA2 то костыль - загрузка ACL не работает, и проблема никак не решается

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


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

3 минуты назад, slv700 сказал:

   Ваша проблема - вы на сервер авторизации или   web -сервер  HotSpot возлагаете задачу обработки каких то L2 запросов. Этот сервер вообще может быть в L3 сети и находиться за тысячи км от ТД.

это не проблема, а одна из самых понятных и наглядных для обывателя реализаций, у нас есть и реализация через radius, и через специализированные протоколы, для конкретных устройств, но это не столь наглядно.

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


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

10 минут назад, NewUse сказал:

В случае использования встроенного портала unifi также при переключении никуда не редиректит.

Ну так коню ясно. Речь идет о как раз внешнем портале- одном на всю сеть. Вот туда и идет постояннный редирект при каждой смене клиентом ТД,

 

1 минуту назад, NewUse сказал:

это не проблема, а одна из самых понятных и наглядных для обывателя реализаций, у нас есть и реализация через radius, и через специализированные протоколы, для конкретных устройств, но это не столь наглядно.

У вас явная проблема с постановкой задачи на разработку ПО. Лепите какую то самописную аматорскую херню.

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


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

10 минут назад, slv700 сказал:

Ваша проблема - вы на сервер авторизации или   web -сервер  HotSpot возлагаете задачу обработки каких то L2 запросов. Этот сервер вообще может быть в L3 сети и находиться за тысячи км от ТД.

Продать клиенту Камбиум с избыточными и ненужными функциями вдвое-втрое дороже, чем Ubiquiti/Mikrotik, а затем еще уговорить его подписаться на облако — для вендора это очень хорошо и правильно.

А для пользователя не очень.

Пользователю гораздо правильнее будет авторизовывать клиентов на месте и тут не будет никакой проблемы с L2.

А если использовать не открытую сеть, а WPA-EAP, и держать в сети RADIUS-сервер, то и с L3 никаких проблем не будет.

 

4 минуты назад, slv700 сказал:

Вот туда и идет постояннный редирект при каждой смене клиентом ТД,

Не идет, читайте внимательнее.

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

После этого любая точка доступа хотспота этого клиента сразу пускает в сеть, никуда не перенаправляя.

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


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

1 минуту назад, alibek сказал:

будет авторизовывать клиентов на месте и тут не будет никакой проблемы с L2.

А если использовать не открытую сеть, а WPA-EAP, и держать в сети RADIUS-сервер, то и с L3 никаких проблем не будет.

Так в том то и дело, что без роуминга вы каждый раз при смене клиентом ТД  будете по новому авторизовывать клиента через Радиус.  Или редиректить его на внешний веб сервер в случае Hotspot.

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


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

Это уже напоминает заклинания секты Микротик.

Все конструктивное я уже написал, не вижу необходимости повторяться.

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


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

3 минуты назад, alibek сказал:

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

Облачный NMS -бесплатен. Если угодно то можно NMS разместить на своем сервере  или одной из точек доступа ( AutoPilot). Все бесплатно.

 

5 минут назад, alibek сказал:

с избыточными и ненужными функциями

Все функции соответствуют уровню и требованиям Enterprise.  

 

2 минуты назад, alibek сказал:

Это уже напоминает заклинания секты Микротик.

Все конструктивное я уже написал, не вижу необходимости повторяться.

Так я не вижу у вас конструктивного решения. По любому у вас при смене клиентом ТД нужно обращение к внешнему серверу ( для авторизации или на splash page).  В этом и есть проблема.

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


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

1 минуту назад, slv700 сказал:

Все функции соответствуют уровню и требованиям Enterprise.

Это просто слово, любой вендор вкладывает в него что-то свое.

У меня сейчас на столе лежит точка доступа TP-Link EAP225, соответствующая уровню и требованиям Enterprise.

Не без достоинств, кстати, мне она скорее понравилась, и при это значительно дешевле любого Камбиума.

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


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

38 минут назад, alibek сказал:

требованиям Enterprise.

Тплинк -enterprise ? Все понятно. 

Вот и стройте на тплинке  говносеть в торговом центре. Аматоры! 

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


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

1 час назад, slv700 сказал:

У вас явная проблема с постановкой задачи на разработку ПО. Лепите какую то самописную аматорскую херню.

Ещё раз наше решение появилось задолго до какого-нибудь Cova-Chill и прочих порталов авторизации, изначально это вообще не портал web-авторизации, а портал управления сервисами, но он может быть использован как портал web-авторизации. Назвать это решение любительским сложно: cisco признала его официально соответствующим её спецификации и единственным, на тот момент решением такого рода. Повторюсь это не портал авторизации в текущем смысле, а куда более сложная система. Но она может выполнять функции портала авторизации и не требует от сети wifi какого-либо роуминга.

 

Касаемо uni-fi у него аж минимум 4 разных способа подключения к порталу:

1)встроенный портал со встроенным вебсервером

2)апи для работы с внешним сервером

3)Радиус

4)отдельно стоящий портал, на подобии вышеописанного.

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


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

7 минут назад, NewUse сказал:

щё раз наше решение появилось задолго до какого-нибудь Cova-Chill и прочих порталов авторизации, изначально это вообще не портал web-авторизации, а портал управления сервисами, но он может быть использован как портал web-авторизации. Назвать это решение любительским сложно: cisco признала его официально соответствующим её спецификации и единственным, на тот момент решением такого рода. Повторюсь это не портал авторизации в текущем смысле, а куда более сложная система. Но она может выполнять функции портала авторизации и не требует от сети wifi какого-либо роуминга.

 

Касаемо uni-fi у него аж минимум 4 разных способа подключения к порталу:

1)встроенный портал со встроенным вебсервером

2)апи для работы с внешним сервером

3)Радиус

4)отдельно стоящий портал, на подобии вышеописанного.

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

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

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


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

В 10.09.2018 в 12:24, slv700 сказал:

   Ваша проблема - вы на сервер авторизации или   web -сервер  HotSpot возлагаете задачу обработки каких то L2 запросов. Этот сервер вообще может быть в L3 сети и находиться за тысячи км от ТД.

 

Почитайте о архитектуре того же чиллиспота. Он внезапно из 2х частей состоит, одна крутиться на AP ходит до радиуса, она же dhcp сервер + может туннелировать трафик. Для клиента сеть остаётся плоской, а где находиться страница авторизации не имеет значения. И никаких перередиректов с переавторизациями не будет от слова совсем.

 

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

 

У человека выше ещё проще. Он тупо для всех неизученных MAC (ну как я думаю) редиректит прямо на шлюзе сети на страничку. Как только чел авторизовался, прямо на том же шлюзе убралось правило редиректа и трафик полился во внешку. Больше ничего для клиента не поменялось. А т.к. всё делает шлюз, то и при миграции никаких перезапросов не будет, т.к. ему сугубо пофигу с какой АП пришёл клиент, для него он один фиг пришёл с LAN интерфейса с коммутатора или протащен вместе с L2 туннелем.

 

И эти схемы не единственные беспроблемные. Скорее я могу только одну схему придумать когда описанная проблема будет проявляться. Но напуркуа создавать самому себе проблемы?

 

Если вы не понимаете как это работает, это не значит, что все остальные идиоты. Это значит, что вам пора разобраться в вопросе и переcтать пороть чушь повторяя её как мантру.

 

Цитата

 

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

У яблок он жёстко зашит, обычно это -70Дб у ведроидов тех что сертифицированы по VoIP Enterprise у альянса порог -75 по дефолту (как пример SGS A5 2017), и может регулироваться через проприретарные API либо в конфиге драйвера.

 

И не порог дисконнекта. А именно процедуры хэндовера (да да так оно прям в дровах тех же QCA и обзывается). Т.е. при падении ниже клиент не оборвёт связь до того как не выберет кандидата для миграции. Либо используя RRM либо тупо с помощью сканирования. Опять таки да, можно даже активное сканирование выполнять по всему (и даже обоим) диапазонам не обрывая соединения с текущей АП. Так же нормальный клиент ещё попробует и преаутентифицироваться на кандидате, и только потом послать прощальный фрэйм текущей АП (в случае если удалось уже можно сказать мигрировать).

 

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

 

1) как править на андроид на квалкоме тут https://wi-cat.ru/wi-fi/besshovnaya-migraciya-rouming-wi-fi-dlya-android-klientov/
2) программа сертификации от альянса https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-voice-programs

3) пороги при которых инициируется процедура миграции в зависимости от девайса (автор циско) https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/device_classification_guide.html

4) другая полезная информация https://wi-cat.ru/forums/topic/podborka-literaturyi/

 

Ну и прямо процитирую альянс.

How does a client roam?

The decision to roam from a connected access point to a new access point is generally the responsibility of the wireless client device. The roaming algorithms used by wireless client devices vary from vendor to vendor, but almost always involve the evaluation of the received signal strength indicator (RSSI). As a user moves away from the connected AP, the signal degrades. The client compares the received signal strength to a pre-defined threshold and determines if a roam is required. Once the signal drops below this threshold, the wireless client performs an off-channel scan, scanning all available channels for a candidate AP, selects one with acceptable signal strength, and completes the roaming process by connecting or associating to the new AP. Some more sophisticated clients utilize additional parameters such as AP neighbor lists or capacity load on an AP to help optimize the roaming process.

 

По поводу ускорения. Самая важная часть это 802.11K особенно в 5ГГц https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/iPhone_roam/b_iPhone-roaming.html#concept_EA3AF8F14F244478804B2D36C25F44C4

 

802.11R в схеме с хотспот вообще ничего не даёт ибо нет шифрования на уровне клиент<=>ap, собсно ускорять нечего. Ессно если говорим о публичных хотспотах.

 

Даже в случае с WPA2 Enterprise при локальном размещении радиуса толку с 802.11R в части ускорения около нуля (на фоне на полный рескан диапазона при отсутствии 802.11k). 

 

А учитывая, что по прежнему большинство клиентов как не умело FT так и не умеет, в лучшем случае будет заюзан OKC.

 

Польза от 802.11R чаще выражается в наличии поля MDID (mobile domain id) который по сути во первых позволяет устроить роуминг внутри сети со скрытым броадкаст SSID и/или при поддержке АП и клиентом позволяет хоть как-то гарантировать что клиент не мигрирует на левак, хотя опять таки понимает это только часть устройств, во вторых никто не мешает подделать это поле т.к. это по сути тупо текст.

 

А вот 802.11K даёт возможность чётко выяснить кто у нас рядом работает и сканировать не весь диапазон (перед переключением, или после обрыва связи и/или по другому какому-то событию), а просто спросить кто рядом у текущей АП к которой подключен клиент. Т.е. исключается полное сканирование диапазона которое может занимать до 7 секунд в случае с 5ГГц.

 

Так же 802.11K предоставляет возможность запросить клиенту Link  Measure, т.е. спросить у текущей АП с какими уровнями она слышит вопрощающего, дабы скорректировать порог форсирования миграции.

 

Так же именно в 802.11k передаются параметры рассказывающие клиенту о том совпадает ли тип авторизации и т.д. и т.п. Всё это (при условии поддержки клиентом) существенно сокращает время миграции.

 

И это ещё не всё,  например QCA/BCM для андроид после всех запросов и прочего считают для каждого кандидата score в котором учитывается куча факторов, включая поддержку WNM и прочего. Может учитываться QLOAD и ещё дофига чего.

 

Что ещё есть со стороны АП? 

 

Ну например есть WNM частью которого является BTM, но я так и не нашёл ни одного клиента который бы его поддерживал. Даже яблоки с заявленной поддержкой 802.11v на данный момент игнорируют BTM фрэймы.

 

Остальное всё чистокровный фуфел и очковтирательство. Уж простите, но наболело.

 

P.S. Что бы при этом миграция оставалась бесшовной не только с точки зрения индикатора подключения wifi на клиенте, но и для приложений, нужно сделать несколько доп телодвижений что бы для клиента после миграции на L2 и выше по сути ничего не менялось. Т.е. один DHCP сервер который если что продлит лизу, один адрес до и после мигарции, один шлюз. Для этого чаще всего либо тянут туннелями L2 до шлюза, либо просто делают плоскую L2 сеть куда воткнуты все АП + шлюз в мир + dhcp + dns сервер и если надо радиус сервер. Если к этому ещё привернуть красивую морду для управления слабоподготовленным персоналом + запустить мониторинг с красивыми графиками + обеспечить какую-то худо бедную конфигурилку уже можно смело говорить, о том что у вас суперпупер контроллер. =)))

 

PP.S. Ну и да. Wive (а значит и SNR) традиционно уже умеют как 802.11K/R/OKC, могут быть сами радиусом, сами DHCP и прочим. И мониторинг с управлялкой так же доступен. И всё без очковтирательства, бесплатно и без SMS. =))))

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


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

PP.SS. Уж прошу прощения. Но кой-кто мне тут палочкой натыкал на тему. =)) Как бы я тут не бываю, и у нас (ну если у кого будут вопросы) есть свой форум https://wi-cat.ru ;) 

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


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

10 минут назад, sfstudio сказал:

И мониторинг с управлялкой так же доступен. И всё без очковтирательства, бесплатно и без SMS. =))))

И без web, чистый CLI? :)
 

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


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

Мониторилка? Ну дык wive-ng-control и читаем. Кому хочется может вообще по ssh бегать сам руками опрашивать. Скриптовать свою логику на тру BASH диалекте ASH и т.д. =)) Вариантов дофига. Вот в 4ре утра я точно не готов рассказывать. Тем более всё есть в соответствующем разделе на этом форуме + на wi-cat.ru и вопросы можно задать там же. Соррь. Но я бы таки поспал бы наверное. =)))

 

По мониторилке лучше сразу на wifi@nag.ru написать, дадут линк, подскажут как развернуть, можно даже не имея АП на пробу. По тому что касается роутерно-апшной части это уже к нам на Wi-CAT.

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


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

Если ТД поддерживают роуминг -handover ( любой, не обязательно 802.11r, достаточно обычный OKC) , но ничего из вышеперечисленного -всякие чили, размещаемые на ТД ( частично) , на шлюзе, хитрые настройки радиуса, туннели до радиуса, dhcp , dns, изменение порогов дисконектов у клиента ( в публичной сети hotspot ?) , другие телодвижения -  ничего этого делать не надо. В этом случае каждая ТД сети знает  клиента, впервые  защедшего на любую ТД сети и обеспечивает его подключение к себе ( без редиректов и ненужных обращений на внешние сервера  к чему либо и для чего либо).  При этом ничего ( доп софт) на ТД ставить  не надо. Все работает просто и эффективно при любом открытом или защищенном WPA2-enterprise доступе. Не требует поддержки со стороны высококвалифицированного персонала.

А вот если ТД не поддерживает роуминг ( например ubnt UniFi или Микротик) , вот тогда и приходится делать костыли и  массу телодвижений, которые нередко работает  через пень колоду или которые  в той или иной задаче ( архитектуре)  могут быть вообще неприменимы.

Не надо морочить себе голову и создавать проблемы.. Если есть сеть из нескольких точек доступа, то лучше сразу ставить ТД с handover. Есть много задач где поддержка роуминга востребована ( и это необязательно бесшовный VoIP)  . И  даже если сейчас можно обойтись без него, то завтра изменится задача и handover будет нужен.

 

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


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

Перестаньте нести херню. Вы сами придумываете себе проблему. Вам уже 300 раз сказали, что её нет, вы продолжаете рассказывать о хэндоверах в вакууме. 

 

Цитата

Если ТД поддерживают роуминг -handover ( любой, не обязательно 802.11r, достаточно обычный OKC)

...

Все работает просто и эффективно при любом открытом или защищенном WPA2-enterprise доступе. Не требует поддержки со стороны высококвалифицированного персонала.

 

OKC как и 802.11R это сущности ускорящие миграцию в сетях с шифрованием и только. Причём мегакритичны только в сетях где радиус утащили в жопу мира или развернули на кофейнике. OKC вообще так и кричит своими 3мя буквами что это кэширование ключей и только. Своеобразное, но таки тупо кэш ключей коих в открытых сетях нет вовсе. А больше ничего OKC и не даёт. И если 802.11R можно с трудом за счёт MDIE за уши притянуть к решаемой задаче, то OKC вообще никак не притягивается, ни в каком виде. Хоть застрелись.

 

Они (OKC/R) ничего не дают в открытых сетях коими являются хотспоты (кроме поля MDIE в R). В hotspot 2.0 там другая система, и тоже никакие FT/OKC не упились для миграции и их отсутсвие тоже никак не ведёт к переаутентификации. Это просто сущности из другой задачи от слова совсем.

 

Хватит уже из людей идиотов делать... Не смешно уже нифига

 

Да и на психа внедряющего hotspot 2.0 сейчас (года через 2 может и будет смысл, если не сдохнет в муках) я бы посмотрел.....

 

А вот отсутствие поддержки RRM для дуалбэнда запросто может сделать бесполезным всё остальное, т.к. клиент будет болтаться как говно в проруби сканя весь эфир что вплоть до 7с может занять, ещё и с обрывом. Правда и в этом случае повторной реаутентификации на хотспоте не потребуется в любом случае, т.к. он (хотспот) о физике вообще ничего не знает обычно. А соединениям пользовательских приложений станет дурно.

 

P.S. Кстати убики нынче умеют и R и OKC, так что ваши условия на них тоже выполняются. Пора придумывать другую мантру. Текущая в любом случае не работает. Не говоря уже о сказанном выше (о бесполезности R/OKC в контексте обсуждаемой темы от слова совсем).

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


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

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

Подскажите если я живу не в Москве и не в Питере, где лучше брать оборудование, потому что у меня в городе уже 2 дня катаюсь не могу найти нигде Ubiquiti LiteBeam AP 5AC-16-120

Unifi без проблем нашёл, а вот для другой задачи не могу найти  LiteBeam .Подскажите где на просторах нашего интернета лучше заказывать

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


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

22 часа назад, slv700 сказал:

Если ТД поддерживают роуминг -handover ( любой, не обязательно 802.11r, достаточно обычный OKC) , но ничего из вышеперечисленного -всякие чили, размещаемые на ТД ( частично) , на шлюзе, хитрые настройки радиуса, туннели до радиуса, dhcp , dns, изменение порогов дисконектов у клиента ( в публичной сети hotspot ?) , другие телодвижения -  ничего этого делать не надо. В этом случае каждая ТД сети знает  клиента, впервые  защедшего на любую ТД сети и обеспечивает его подключение к себе ( без редиректов и ненужных обращений на внешние сервера  к чему либо и для чего либо).  При этом ничего ( доп софт) на ТД ставить  не надо. Все работает просто и эффективно при любом открытом или защищенном WPA2-enterprise доступе. Не требует поддержки со стороны высококвалифицированного персонала.

А вот если ТД не поддерживает роуминг ( например ubnt UniFi или Микротик) , вот тогда и приходится делать костыли и  массу телодвижений, которые нередко работает  через пень колоду или которые  в той или иной задаче ( архитектуре)  могут быть вообще неприменимы.

Не надо морочить себе голову и создавать проблемы.. Если есть сеть из нескольких точек доступа, то лучше сразу ставить ТД с handover. Есть много задач где поддержка роуминга востребована ( и это необязательно бесшовный VoIP)  . И  даже если сейчас можно обойтись без него, то завтра изменится задача и handover будет нужен.

 

«Поздравляю вас, гражданин соврамши!»

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


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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.