[NewUse]

47 минут назад, straus сказал:

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

и много вы терминалов с поддержкой роуминга видели, или хотяб 802.11n? и, не поверите, они и в 802.11g без всякого роуминга прекрасно работают... а на складах там расстояние поболее Ашановских будет и точек дофига стоит, а оно работает...

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

[Saab95]

Многие компании делают беспроводную сеть, а потом переделывают на проводную, потому что печать на принтерах через радио превращается в интересный квест - дойдет или не дойдет =)

 

При создании сети надо сначала кабели проложить до каждой точки, потом грамотно на L2 разделить, что бы не превратить сеть в большую помойку (ARP трафик, всякие левые запросы и т.п.), все должно быть заблокировано - только доступ в интернет или на нужные ресурсы локалки.

 

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

[slv700]

4 часа назад, NewUse сказал:

терминалов с поддержкой роуминга видели, или хотяб 802.11n? и, не поверите, они и в 802.11g без всякого роуминга прекрасно работаю

Терминалу не надо поддерживать роуминг. И не имеет значения  802.11n или 802.11g.

 

4 часа назад, NewUse сказал:

нет задачь гонять по терминалу онлайн видео или хотяб голос ..

Вам уже 100 раз  сказали, что роуминг нужен не видео и голос гонять. Изучите матчасть.

[NewUse]

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

Терминалу не надо поддерживать роуминг. И не имеет значения  802.11n или 802.11g.

Для корректной работы терминала никакого роуминга не нужно, просто 802.11r появился сильно позже терминалов.

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

Вам уже 100 раз  сказали, что роуминг нужен не видео и голос гонять. Изучите матчасть.

Боюсь, я тут с Вами никак не могу согласиться; в точности наоборот: в wifi роуминг нужен ТОЛЬКО для того, чтоб обеспечить возможность бесперебойной работы при перемещении от точки к точке критичных к задержкам приложений, и потоковое видео и звук это тот немногий пример таковых приложений, особенно он критичен в voip, где отсутствует буфер загрузки.

А мат. часть, я считаю, что знаю достаточно неплохо, хотя всегда найдётся то, что ещё можно изучить.

[straus]

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

в wifi роуминг нужен ТОЛЬКО для того, чтоб обеспечить возможность бесперебойной работы при перемещении от точки к точке критичных к задержкам приложений, и потоковое видео и звук это тот немногий пример таковых приложений, особенно он критичен в voip, где отсутствует буфер загрузки.

Вот когда в торговом зале будет некто носиться с терминалом проверки ценников (а их надо проверить тысячи, и очень быстро, иначе зарплату ампутируют), и его терминал будет постоянно переподключаться - он тебе весь мозг вынесет. Потому что это его зарплата. Ты когда-нибудь видел, как они носятся со своими терминалами с лазерными сканерами, проверяя все ценники на полках? Я ещё цифру не успел увидеть, а он уже к следующему ценнику.
 

 

Кстати в современном городе "сделай нормально работающий Wi-Fi" - тоже квест ещё тот.
 

[NewUse]

33 минуты назад, straus сказал:

Вот когда в торговом зале будет некто носиться с терминалом проверки ценников (а их надо проверить тысячи, и очень быстро, иначе зарплату ампутируют), и его терминал будет постоянно переподключаться - он тебе весь мозг вынесет. Потому что это его зарплата. Ты когда-нибудь видел, как они носятся со своими терминалами с лазерными сканерами, проверяя все ценники на полках?

20м за 2с? именно такое максимальное время переключения в стандарте 802.11g(без всякого роуминга или недороуминговых ускорителей, правда без учёта времени ответа от radius, вот только я не видел терминалов с поддержкой Eneterprise, типичное, же, около 100мс.

Время сканирования(наведения на штрих-код), тоже не нулевое.

 

Ещё раз -- роуминг нужен только в вышеописанных мной случаях, а из реальной практики это только voip при чём 3-5мс, которые даёт по проводу типичный radius-сервер ситуацию не сильно портят.

 

[straus]

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

именно такое максимальное время переключения в стандарте 802.11g

Ок. А вот какое реальное время первичного подключения или переподключения у реального оборудования? Как выясняется 15 секунд - не предел. Когда делали служебную Wi-Fi сеть в киевском метрополитене, то поезд за время стоянки на станции не всегда успевал подключиться и обновить некоторую информацию.
 

[NewUse]

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

Ок. А вот какое реальное время первичного подключения или переподключения у реального оборудования? Как выясняется 15 секунд - не предел. Когда делали служебную Wi-Fi сеть в киевском метрополитене, то поезд за время стоянки на станции не всегда успевал подключиться и обновить некоторую информацию.

Ну так не надо путать тёплое со сладким...

Можете, за подробностями обратиться к статьям того же @sfstudio , но если в кратце: переключение состоит из нескольких фаз:

1)Скан маяков, в зависимости от реализации КЛИЕНТА(никак не зависит от ТД) может занимать от 0.1 до нескольких сотен секунд, может проводиться как в бэкграунде, так и только на живую(тоже зависит ТОЛЬКО от реализации КЛИЕНТА)

2)авторизация/переавторизация  -- вот именно это ускоряет роуминг (до 2с.)

3)Получение сетевых настроек -- в зависимости от настроек КЛИЕНТА и сети(например DHCP сервера) от 0 до бесконечности

4)Переустановка tcp-сессий приложений, по сути это то же что и из п.3, только для мобильных устройств из-за кривости сборок ПРИЛОЖЕНИЙ под ios и android я вынес его в отдельный пункт, время также как и в предыдущем от 0 до полного перезапуска приложения, или что ещё хуже -- передёргивания интерфейса полностью.

 

Всё это ОЧЕНЬ подробно расписано в цикле статей @sfstudio:

https://wi-cat.ru/category/wi-fi/wi-fi-roaming/

 

[straus]

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

авторизация/переавторизация  -- вот именно это ускоряет роуминг (до 2с.)

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

 

[slv700]

8 часов назад, straus сказал:

то теоретически при роуминге ускоряется только авторизация.

Это отчасти верно. При роуминге  с WPA2- EAP ( PEAP, EAP TTLS) пропускается этап 4wayhandshaking , который длится 400 мс. То есть нет обмена ключами между ТД и клиентом, потому что ТД уже имеет свою часть ключа - получила от других ТД ( или контролера), к которому впервые подключился клиент. Но неверно, что ускоряется только авторизация. И вообще само по себе ускорения на 400 мс вещь полезная но  не всегда критически востребована. 

Давайте рассмотрим открытый доступ в сети вайфай без роуминга.

Точки доступа не знают ничего о клиентах своих соседей и подключают всех кто к ним просится.

1) Допустим клиент подключился к одной из ТД  сети. Если не установлен порог  RSSI по дисконекту клиента, то ТД будет держать клиента при его перемещении  до последнего , пока сигнал не упадет ниже порога чувствительности приемника ТД или клиента. И это несмотря на то что рядом могут быть ТД с хорошим сигналом. Клиенту чтобы переключиться на новую ТД с хорошим сигнал надо вручную отключиться от ТД и тогда произойдет переход на новую ТД. Нормальная работа ?

2)На ТД установлен порог дисконекта, скажем -80 dBm.  Клиент при достижении такого сигнала дисконектится и ищет новую точку. Во-первых, он ее может не найти ( такое планирование), во вторых , сигнал то плавает+- 5 дБ и через 1-2 сек поиска клиент может вернуться на свою же ТД, или подключиться к другой, а потом та его тоже может дисконектнуть и клиент вернется к старой ТД или переключится к третьей ТД. Такое метание клиента между ТД в сети без роуминга  с плотным размещением ТД -обычное явление, перерывы в связи могут достигать 1-2 сек. Эту проблему не решить частоным планированием и подбором мощностей ТД, поскольку клиентские устройства все разные.  Нормальная работа ?

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

Если сеть в роуминге, то клиент

1) никогда не дисконектится от старой ТД пока не найдет новую

2) никогда ( сразу ) не вернется на старую ТД при переходе на новую ТД

3) не проходит повторную авторизацию, редирект на стартовую страницу при смене ТД.

4) при дисконекте от  одной ТД не переключится на левую ( ТД не своей сети) , даже если у той сильнее сигнал чем от ТД своей сети.

и другое.

И конечно при роуминге ускоряется переключение клиента между ТД от 700-2-5 сек ( нет handover) до менее 50 мс при handover OKC, <12ms  при 802.11r. Но это востребовано редко, только для VoIP ( скайа,вайбер и др). Видео имеет большой буфер и например YouTube держит связь ( не дисконектит сессию) несколько ДЕСЯТКОВ секунд.

[alibek]

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

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

Надуманная проблема

Это проблема тех систем, в которых из точки доступа пытаются сделать комбайн, который занимается всем подряд. Как Камбиум или Микротик.

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

Даже на UniFi такой проблемы нет, хотя архитектура там не самая оптимальная и Captive Portal там встроен в каждую точку.

 

А пункты 1 и 2 давно уже решены даже в SOHO-решениях типа SNR-CPE, не говоря уж о других.

[slv700]

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

Даже на UniFi такой проблемы нет, хотя архитектура там не самая оптимальная и Captive Portal там встроен в каждую точку.

Зачем Каптив портал на каждой ТД? ТД должна иметь возможность редиректить клинта на внешний  web сервер- каптив портал. Она это и делает для каждого подключившегося клиента, если его не знает ( а без роуминга она о клиенте ничего не знает)

 

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

точки доступа пытаются сделать комбайн, который занимается всем подряд. Как Камбиум или Микротик.

Никаких комбайнов там нет.  Правильная ТД должна иметь возможность сделать у себя  простейший Каптив портал ( если она будет одна в сети) или редиректить на внешний сервер.  Часто  редирект делает контроллер. В этом случае ТД работает как прозрачный бридж. Но функция контроллера в этом случае не должна ограничиваться редиректом, или handover, это в современных сетях- сервер цифрового маркетинга.

 

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

портал авторизации это отдельное логическое устройство,

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

[slv700]

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

Решены даже в SOHO-решениях типа SNR-CPE

Зачем SOHO  ТД handover ? Это никому не нужно и странно. Но это вопрос к разработчикам, зачем они нагружают ТД не нужной в работе функциональностью.

Если же ТД поддерживает только дисконект по RSSI ( как Микротик или UBNT) без handover,   то проблема метания клиента между ТД никак ( в том числе  микротиковскими костылями) не решается . Если решается, то будьте любезны, опишите решение.

[alibek]

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

ТД должна иметь возможность редиректить клинта на внешний  web сервер- каптив портал.

Это я и называю Captive Portal. Если называю ошибочно — значит я имею ввиду возможность переадресации клиента на портал авторизации.

 

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

Она это и делает для каждого подключившегося клиента, если его не знает

Зачем ей это знать?

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

 

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

Правильная ТД должна иметь возможность сделать у себя  простейший Каптив портал ( если она будет одна в сети) или редиректить на внешний сервер.

Зачем? Какой в этом практический смысл?

 

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

это в современных сетях- сервер цифрового маркетинга

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

 

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

никаких проблем  ( с помощью всяких костылей) связанных с роумингом

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

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

[slv700]

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

ачем ей это знать?

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

Вам как клиенту будет нормально, если при каждой смене ТД вас будут редиректить на каптив портал? 

 

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

Зачем? Какой в этом практический смысл?

Ну стоит где то HotSpot из одной ТД. Чтобы не ставить отдельний внешний веб сервер для Каптив портала, на ТД можно сделать встроенный splash page ( обычно простейший).

[NewUse]

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

Вам как клиенту будет нормально, если при каждой смене ТД вас будут редиректить на каптив портал? 

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

[alibek]

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

Зачем SOHO  ТД handover ? Это никому не нужно и странно

Это не нужно только вендору, который эту функцию объявляет своим конкурентным преимуществом.

А вот конечному пользователю эта функция очень удобна и полезна.

 

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

то проблема метания клиента между ТД никак ( в том числе  микротиковскими костылями) не решается . Если решается, то будьте любезны, опишите решение.

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

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

Ну а когда в SNR-CPE появился нормальный роуминг, то такой костыль тем более стал не нужен.

[slv700]

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

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

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

 Какие еще посторонние задачи? Зачем каждую ТД делать контролером? Я вижу вы не владеете темой.Несете какую то ахинею.

[Saab95]

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

 

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

[alibek]

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

Вам как клиенту будет нормально, если при каждой смене ТД вас будут редиректить на каптив портал?

Вы перечитайте, что я написал.

Это в вашем подходе у вас будет такая проблема.

В моем подходе этой проблемы нет в принципе.

[slv700]

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

через портал он проходит прозрачно. Я работаю в одной фирме, в частности,занимавшейся разработкой таких порталов за долго до появления и массового применения беспроводных хотспотов.

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

[alibek]

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

Ну стоит где то HotSpot из одной ТД.

Опять за рыбу гроши.

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

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

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

[slv700]

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

В моем подходе этой проблемы

Не надо никаких своих подходов. Решение должно быть типовое, основанное на промышленных стандартах, без костылей, самописов, самосборов .

[alibek]

Я поправил так, как должно было прозвучать:

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

Решение должно быть типовое, основанное на промышленных стандартах Cambium, без Ubiquiti, Mikrotik и серверов.

 

[NewUse]

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

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

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