[nemo]

 

Опять бла бла бла.

Все очень субьективно, кому-то одно важно кому-то другое.

Я несколько примеров приведу, хотя уверен, вы их знаете

Это и надичие Air time fairness

Это качество изготовления и процент выхода их строя

И поддерживаемое кол-во клиентов без деградации скорости

И пакетная производительность и т.д. и т.п.

 

 

Грамотный специалист не будет использовать высеры типа "порвёт". Для меня что циска что убики параллельно, когда они мне будут интересны я обязательно поинтересуюсь вашего технически аргументированного мнения.

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

 

 

Теперь хотелось бы ответа на http://forum.nag.ru/forum/index.php?showtopic=115889&view=findpost&p=1269028

 

P.S. Вы себя даже с Саабом-то не сравнивайте, и уж точно не с slv, они хотя бы аргументацию предоставляют, а не орут "это ж бубльгум". Т.е. их посты в отличии от ваших смысл имеют со старта (какой вопрос десятый).

Не люблю повторяться, на многие вопросы уже были ответы.

Как вы правильно заметили - вендоры применяют разные алгоритмы чтобы обойти ограничение механизма переключения в стандарте и на клиентах. Я не разработчик, чтобы оперировать всеми алгоритмами которые изготовить реализовал. Но часть рассмотреть можно - базово описал как происходит переключение абонента, и кажется уже не один раз. Зачем повторяться? Вы конкретный вопрос задавайте что непонятно, будем дальше смотреть.

[sfstudio]

Все очень субьективно, кому-то одно важно кому-то другое.

 

Конкретнее что субъективно? Субъективно это на уровне "люблю не люблю".

 

Я несколько примеров приведу, хотя уверен, вы их знаете

Это и надичие Air time fairness

 

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

 

Это качество изготовления и процент выхода их строя

 

Тоже показатель такой сомнительный, по личному опыту.

 

И поддерживаемое кол-во клиентов без деградации скорости

 

Тоже весьма спорно и больше чем есть времени в эфире не впихнёшь, уж без деградации вообще не впихнёшь. Увы время оно такое. Вот за счёт Airtime раздать хоть как-то равномерно это время уже можно.

 

И пакетная производительность и т.д. и т.п.

 

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

 

 

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

 

Вы не поверите, вы вот точно их не знаете. =) То что написано в проспектах это вершина айсберга, и зачастую очень и очень преукрашено.

 

Не люблю повторяться, на многие вопросы уже были ответы.

Как вы правильно заметили - вендоры применяют разные алгоритмы чтобы обойти ограничение механизма переключения в стандарте и на клиентах. Я не разработчик, чтобы оперировать всеми алгоритмами которые изготовить реализовал. Но часть рассмотреть можно - базово описал как происходит переключение абонента, и кажется уже не один раз. Зачем повторяться? Вы конкретный вопрос задавайте что непонятно, будем дальше смотреть.

 

Вы думаете я бы стал бы задавать вам вопрос без подвоха? Ниже в споре с slv даже ответ на вопрос есть. Ещё раз 10ть перечитайте почему вам был задан этот вопрос и какой на него верный ответ. А логика переключения зебра вполне честно описала в доке на которую ссылку дал представитель выше. Не без преукрашивания...

 

Ну и ещё раз, мы на техническом форуме, тут именно, что важны нюансы, а иначе базово можно и микротики в кастрюльках по стенам развешивать.

 

А вопрос там кстати вполне конкретный. Осильте его понять, и дать технически грамотный ответ на него.

[nemo]

Кстати порадовала картинка. Всё то же спинывание и никаких гвоздей.

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

У вас так реализовано?

[sfstudio]

Мама какая каша. Перечитайте вчерашнюю тему пожалуйста. И найдите 3 ошибки в своём посте http://forum.nag.ru/forum/index.php?showtopic=115929&st=0&p=1269540entry1269540

 

Давайте вы до завтра подготовитесь, а я прокоментирую? Не торопитесь пожалуйста с ответом. Почитайте попутно техническую документацию именно касательно 802.11.

 

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

 

Вы замешали в кучу спинывание и fast roaming. Эти все нюансы и когда они работают обсосаны от и до. Почитайте.

 

А вопрос не о том был. Вообще не в том. Будьте добры на вопрос ответить, а не рассказывать мне о том как осуществляется быстрая миграция между AP.

 

На сегодня прошу меня простить, свой лимит времени на форумные споры я исчерпал.

[Vladimir-nag.ru]

форумах.

И судя по этой доке реализация ооооооочень близкая к нашей, детальней надо видеть код что бы понять что будет "лучше" в зависимости от условий. Эту доку кстати я не встречал.

 

Так а у Вас какая реализация? При роуминге клиента из всех Ваших точек только одна клиенту на запрос отвечает? На какой запрос, Probe Request?

[sfstudio]

На null пробе ответят все которые слышат, на direct только те коме адресовано. См RFC.

[Vladimir-nag.ru]

На null пробе ответят все которые слышат, на direct только те коме адресовано. См RFC.

 

Ну т.е. при direct probe request ответят только те точки доступа, которые поддерживают SSID, заявленный в direct запросе. Но в чем реализация-то? По тексту зебры, как мне кажется, говорится, что в рамках direct запроса не все точки с данным SSID ответят, а только одна. Не?

 

only the access point with the

minimum load and a minimum signal strength threshold will

respond to the client. R

Изменено 6 апреля, 2016 пользователем Vladimir-nag.ru

[sfstudio]

А, вот вы о чём, ну тут как зададите http://forum.nag.ru/forum/index.php?app=core&module=attach&section=attach&attach_rel_module=post&attach_id=28358 в зависимости от уровня можно либо заигнорить пробы, либо послать назад INVALID.

Qload да, хорошая идея сюда же заюзать. Добавлю, это я упустил. В общем-то не проблема.

 

P.S. Я просто расставлю чуток точки над i. Моё присутствие на форуме никак не связано с продажами. И то что я въедчиво докапываюсь до технической стороны закономерно. Форум технически, раздел тоже технический (продажи есть рядом). А мой интерес в подобных спорах живёт в ключе понимания, что я упускаю занимаясь реализацией у себя. ;) Разработка как бы подразумевает хождение по граблям, но изучение как это сделано у кого-то ещё, приводит к пониманию на какие ещё грабли придётся наступить на пути к максимально корректному обходу проблем созданных wifi альянсом из-за безобразного подхода к сертификации и как следствию невозможности гарантировать совместимость клиента с тем или иным "расширением" 802.11. Так же эта информация крайне полезна и подготовленным технарям выбирающим решение (понимание именно разницы подходов). ИМХО это и есть цель любого технического форума - обмен технической инфой с изучением нюансов.

[nemo]

Мама какая каша. Перечитайте вчерашнюю тему пожалуйста. И найдите 3 ошибки в своём посте http://forum.nag.ru/forum/index.php?showtopic=115929&st=0&p=1269540entry1269540

 

Давайте вы до завтра подготовитесь, а я прокоментирую? Не торопитесь пожалуйста с ответом. Почитайте попутно техническую документацию именно касательно 802.11.

 

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

 

Вы замешали в кучу спинывание и fast roaming. Эти все нюансы и когда они работают обсосаны от и до. Почитайте.

 

А вопрос не о том был. Вообще не в том. Будьте добры на вопрос ответить, а не рассказывать мне о том как осуществляется быстрая миграция между AP.

 

На сегодня прошу меня простить, свой лимит времени на форумные споры я исчерпал.

Я разве писал о 802.11r+k? Мог ошибиться за давностью лет только в том по какому событию происходит переключение и кто инициатор и только.

Изучите IEEE 802.1X Pre-Authentication. Со старой точки клиента не вышибет, тут вы не правы (вот пруф как вы просили - Fast/Secure Roam-Back).

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

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

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

[slv700]

ТС для решения задачи и по 1-му и 2-му варианту подойдет cnPilot E400 Cambium. Роуминг он умеет - поддерживает Pre-authentification, OKC и 802.11r при защищенном доступе и проприетарный handover при открытом доступе. Все делает без контролера. Класс устройства- SME, двухдиапазонный 2.4 ГГц и 5 Ггц -АС. 256 клиентов на интерфейс, цена MSRP $199. Что еще надо для решения задачи ТС?

ЗЫ

ubnt АС роуминг не поддерживает, а старые устройства требуют работы всех точек доступа на одной частоте- это будет каша, жить не будет.

[sfstudio]

Я разве писал о 802.11r+k? Мог ошибиться за давностью лет только в том по какому событию происходит переключение и кто инициатор и только.

Изучите IEEE 802.1X Pre-Authentication.

 

Я логику реализации оного правил. Вы чуток не въезжаете, там фаза аутентификации сокращается но она есть. Ровно как и в схеме с фаст роумингом, логика иная (в силу разницы подходов) но по сути это лишь ускорение фазы аутентификации без полной её исключения и ессно клиент на этот момент уже деассоциирован от предыдущей АП и выполняет подключение к новой (именно поэтому хоть и 50-100мс,но перерыв при переходе имеется). На этом этапе уже не важно кто принял решения, важно быстро пустить на новую точку и если клиент залип то так же быстро пустить на старую т.к. именно в этот крошечный момент времени у клиента по сути ещё нет коннекта с новой, но уже нет со старой (даже если старая его ещё не вычистила из "структур").

 

Со старой точки клиента не вышибет, тут вы не правы (вот пруф как вы просили - Fast/Secure Roam-Back).

 

Ок, давайте определяться с терминологией. Что значит не вышибает? Логика самого 802.11 такова, что штатно клиент не может ассоциироваться с другой АП пока не деассоциируется от текущей (ну вот так оно устроено, есть хаки типа multiple connection, но они выходят за границы стандарта). Да, пруфа я не вижу, линк конкретный. Вываливается дофига мусора в т.ч. от циско где нет опровержения моих слов впринципе.

 

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

 

Мне не надо запретить, мне надо сказать куда коннектиться конкретно (а вот этого в 802.11 не моги, нет такого в стандарте, остаётся идти от противного и надеяться, что клиент не совсем кривой), иначе от дурости клиента зависит куда он упадёт, может вообще в марсианскую сеть которая орёт громче и/или не зашифрована. И никакие 802.1х тут не помогут. Перечитайте вчерашний разбор полётов, я даже примеры таких устройств приводил и платформ, и на руках их сотни тысяч у простого люда.

 

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

 

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

 

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

 

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

 

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

[nemo]

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

Вот информация вам более детальная, найти не сложно было. Пусть и к циско относится, но можно найти и в других источниках - "This method is sometimes known as “fast secure roam-back” because client station is able to roam-back to original AP & skip the 802.1X/EAP Process.Drawback of this method is there are no way to make a roam fast, if client station is associate to a new AP." http://mrncciew.com/2014/09/11/cwsp-pmk-caching-preauthentication/

Я к счастью не теряю время на разработку аутентификации Wi-fi и не реализацию костылей. Пользуюсь готовыми и остается время заниматься практическими исследованиями. Поэтому не считаю, что железо у которого можно править исходники лучшее (уж с openwrt наигрался в свое время :) ).

Более того, могу на Моторолу поставить (некоторые модели) openwrt. Вполне себе исходники :), правда не пробовал и не знаю заведется ли полностью, но вполне возможно.

Самые популярные продукты у Apple - потому что они просто работают не требуя ковыряний в исходниках.

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

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

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

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

[nemo]

Мне не надо запретить, мне надо сказать куда коннектиться конкретно (а вот этого в 802.11 не моги, нет такого в стандарте, остаётся идти от противного и надеяться, что клиент не совсем кривой), иначе от дурости клиента зависит куда он упадёт, может вообще в марсианскую сеть которая орёт громче и/или не зашифрована. И никакие 802.1х тут не помогут. Перечитайте вчерашний разбор полётов, я даже примеры таких устройств приводил и платформ, и на руках их сотни тысяч у простого люда.

 

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

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

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

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

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

[sfstudio]

Вот информация вам более детальная, найти не сложно было. Пусть и к циско относится, но можно найти и в других источниках - "This method is sometimes known as “fast secure roam-back” because client station is able to roam-back to original AP & skip the 802.1X/EAP Process.Drawback of this method is there are no way to make a roam fast, if client station is associate to a new AP." http://mrncciew.com/2014/09/11/cwsp-pmk-caching-preauthentication/

 

Всё верно, там если дальше пройдёте какраз будет разжовано что именно пропускается. Т.е. по сути не удаляется кэш ключа и endpoint может вернуться на родину. Где тут сказано что нет отключения клиента-то? Сносит с клиента с базы, но кэш храниться потому можно львиную долю фазы аутентификации пропустить. Более того там же разжовано было (если склероз не изменяет) почему если клиент уже ассоциировался с новой АП, но что-то пошло не так и его вынесло (ну уровень упал) быстро назад уже вернуться не выйдет. И т.д. и т.п. Я не вижу противоречия в моих словах. Потому и грю, физически клиента на старой АП как только он начал общаться на тему ассоциации с новой АП уже нет. Но он может туда вернуться быстро как при использовании 802.1x preauth/PMK cache так и при использовании fast roaming. Хэндшейк меняется, но не исчезает вовсе. Т.е. пока клиент "летит" коннекта у него уже нет со старой (его выпнуло или сам выпнулся не суть), ни с новой.

 

Я к счастью не теряю время на разработку аутентификации Wi-fi и не реализацию костылей. Пользуюсь готовыми и остается время заниматься практическими исследованиями. Поэтому не считаю, что железо у которого можно править исходники лучшее (уж с openwrt наигрался в свое время :) ).

 

1) будьте внимательнее, практика и видимость не всегда критерий истины, если вам не показывают всю фазу в роже/мониторилке, то это не значит что её нет

2) и ещё раз внимательнее будьте, я сказал при прочих равных

 

Более того, могу на Моторолу поставить (некоторые модели) openwrt. Вполне себе исходники :), правда не пробовал и не знаю заведется ли полностью, но вполне возможно.

 

Ставьте кто вам мешает? Ну раз можете. Тут вопрос шёл о модификации на ходу того что вдруг оказалось не так, а не переезд на ВРТ с целью с нуля себе мозг изнасиловать.

 

Самые популярные продукты у Apple - потому что они просто работают не требуя ковыряний в исходниках.

 

Где ж это они популярные-то? =)))) Линуха в мире больше, куда не плюнь одни линухи. Да и требовать они ничего не требуют, но дают возможность. Это тема другого спора.

 

Остальное пропущу, вот это уже действительно полная нетехническая субъективщина. О ней спорить вон в раздел "популярные продажи". Попросить создать для вас? Хотя выше есть флейм, там самое место рассуждениям популярности, нужности или не нужности исходников, наковыривания или расковыривания. Ок? Вернулись в техническое русло?

 

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

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

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

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

 

Очень много допущений. Представляете вы со своим мобильником с включенным роумингом падаете в сеть зимбабвы потому что она пускает всех? Ну вот попался вам такой вот клиент и срать ему на то что вы ему сказали юзать МТС с шифрованием, он лезет настырно в зимбабвийское королевство.

 

Вопросы залипающих клиентов вы только со стороны не решите увы. Некоторых клиентов так залипает что они вообще начинают ждать действий юзверя. Грю я их навидался вдоволь. Но если вас только яблоки интересуют - там такой проблемы нет. Но вот как раз их-то можно сказать и мизер в реальной жизни даже в пределах мкада. И чем дальше от мкада тем больше всевозможных китайских перемаркированных клонов.

 

Осильте диалоги пожалуйста, вдумчиво, а то опять 25 буду объяснять. Сами кричите, что повторяться не любите - меня заставляете. Поэтому я повторяться не буду, там уже всё сказано.

[nemo]

История с одного мероприятия, практически более 80% клиентов юзали мобильные девайсы в диапазоне 5Ггц, и большая часть из них AC. Зависит еще от среза общества :)

А теперь расскажите как клиент приконектится к чужой сети, если у него четко прописан SSID и пароли доступа к сети?

Имеете ввиду, что он раньше в эту сеть подключался? Понял, это не мой случай, но проблему увидел.

Решается довольно просто, если территория своя - просто говорим точкам доступа что rogue чужие точки доступа убивать (и он деассоциирует всех клиентов в своей зоне видимости от не своих точек). И телефон больше не сможет приконектится к другим точкам (не нашим) в зоне действия сети. Тоже кстати штатная фича Зебры, очень впечатляет при демонстрации :).

[sfstudio]

История с одного мероприятия, практически более 80% клиентов юзали мобильные девайсы в диапазоне 5Ггц, и большая часть из них AC. Зависит еще от среза общества :)

 

Ну вот когда так будет везде, а пока это крайне редкое явление.

 

А теперь расскажите как клиент приконектится к чужой сети, если у него четко прописан SSID и пароли доступа к сети?

 

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

 

Имеете ввиду, что он раньше в эту сеть подключался? Понял, это не мой случай, но проблему увидел.

 

В т.ч.

 

Решается довольно просто, если территория своя - просто говорим точкам доступа что rogue чужие точки доступа убивать (и он деассоциирует всех клиентов в своей зоне видимости от не своих точек). И телефон больше не сможет приконектится к другим точкам (не нашим) в зоне действия сети. Тоже кстати штатная фича Зебры, очень впечатляет при демонстрации :).

 

Ага, насри соседу это так прекрасно. Может лучше сразу в бункер (хотя в любом случае в бункер, но если выявят кто шалит придётся этому шалуну ещё самому себе и бункер выкопать и закопаться)? Ну а впечатляет она тех кто не понимает насколько не защищён от такого вот 802.11 и почему оно убого by design.

[nemo]

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

Кстати а как клиент выбирает сеть к которой коннектится при прочих равных? Есть инфа? Или каждый аппарат по своему?

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

А если мы сделаем 802.1x EAP? То получается не нужно диасоциировать клиента, он сам даст команду и реасоциации и переключится на точку с которой уже будет иметь ключи. Это решение проблемы?

 

Ну а впечатляет она тех кто не понимает насколько не защищён от такого вот 802.11 и почему оно убого by design.

А что му ругаем 802.11, это ведь по сути технология 80х, просто у ethernet отобрали провод и пустили по воздуху. А потом грабельками грабельками пытались его модернизировать при этом не забыв про обратную совместимость. Вот и чего от него можно еще ожидать? В AC эти проблемы кстати тоже не решены.

Никто не хочет революции и изобретать формат с нуля (был кстати в свое время, но проиграл и ушел в небытие)

[sfstudio]

Вы описываете проблему не точек доступа, а клиентов.

 

Я описываю комплексную проблему роуминга, и грю что только со стороны AP на это никак не повлиять ибо в 802.11 не заложили и не сделали обязательным нужный функционал.

 

 

Кстати а как клиент выбирает сеть к которой коннектится при прочих равных? Есть инфа? Или каждый аппарат по своему?

 

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

 

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

А если мы сделаем 802.1x EAP? То получается не нужно диасоциировать клиента, он сам даст команду и реасоциации и переключится на точку с которой уже будет иметь ключи. Это решение проблемы?

 

Неа. Решение проблемы заложить в 802.11 хотя бы на уровне расширения механизмы для того что бы можно было точно сказать куда и как мигрировать и выдавать под это спец ключик, при этом следать это частью обязательной на получение ready 802.11ЗЮ логотипа.

 

А что му ругаем 802.11, это ведь по сути технология 80х, просто у ethernet отобрали провод и пустили по воздуху. А потом грабельками грабельками пытались его модернизировать при этом не забыв про обратную совместимость. Вот и чего от него можно еще ожидать? В AC эти проблемы кстати тоже не решены.

 

А GSM ещё старее, и внезапно в нём проблемы подобные решены на стадии проектирования. Что мешало альянсу обязать хотя бы те плюшки что есть по роумингу исполнять хотя бы чипмэйкеров я ХЗ. Там половина набора плюшек для сертификации необязательны, в итоге кто в лес кто по дрова.

 

Никто не хочет революции и изобретать формат с нуля (был кстати в свое время, но проиграл и ушел в небытие)

 

Тут проблема не в революции, а в банальном раздолбайстве и тупой жажды бабла и только бабла со стороны альянса и не только. Грю в WiGyg вроде как обещают быструю миграцию сделать обязательной, оно и ясно 60ГГц таки. Но вот чует моё сердце всё будет как обычно.

[nemo]

Неа. Решение проблемы заложить в 802.11 хотя бы на уровне расширения механизмы для того что бы можно было точно сказать куда и как мигрировать и выдавать под это спец ключик, при этом следать это частью обязательной на получение ready 802.11ЗЮ логотипа.

Чем EAP не решение? будет цепляться пока физически точку не потеряет последнюю.

Кстати можно создавать 2 сети - одну для правильного оборудования с поддержкой R+K. А вторую для остальных.

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

Вывод - во всем виноваты потребители :)

[sfstudio]

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

 

Потребителям насрать, как и вендорам клиенстких железок насрать, потому такие вещи спускаются сверху и никак иначе. Если альянс решил что можно например драфт1 N девайсы в итоге лэйбой не драфтовой наградить, а они даже 40МГц полосу не умели многие, а некоторые и WPA2... Ну о чём тут говорить? Тупо бабло стрегут, вот и вся проблема.

 

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

 

Бэнд стиринг тоже ещё тот знатный костыль. Пока отлаживал логику сначала ржал, потом плакал, потом опять ржал, а терь вот думаю,а блин какого хрена альянс не заложил в стандарт обязательность обработки qload и preffered. Да они даже в Capabilitis не требуют от клиента указывать чего он по факту умеет, там половина полей пустые зачастую... Полнейший бардак.

 

Офисно-сортирная технология для подглядывания из-за угла в интернет. Ну или замена шланга от стола до дивана. Вот удел подхода альянса к развитию 802.11.

[nemo]

Я еще не видел клиента, который будучи подключенный к одной сети, переподключался к другой. Такие существуют?

Ну наверное у них коррупция в стране, раз раздают лейблы направо и налево :)

[sfstudio]

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

 

Чаще проблема в другом, кинули в карман, оно там 5ть минут полежало и ведроид выключил радио (и прально чего батарею жрать), а при включении... =)

 

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

 

Более-менее на эту тему хорошо у топов самсунга, лыж и Nexus. И то никто из них полноценно не умеет связку K+R (ну как пример). А некоторые S5 цепляясь к AP с поддержкой 80МГц канала (причём не всех) начинают разогреваться в руках и вырубаются по перегреву, при этом ни на что почти не реагируя (баг в драйвере).

 

И с яблоками тоже чудес хватает на самом деле. Там вообще местами свои приблуды к 802.11 имеются со своими тараканами. Но хотя бы манагер соединений там везде одинаковый и более-менее лишённый тараканов.

 

Андроиды тоже когда-нить к этому придут, но чую ой не скоро это будет.

 

Ну наверное у них коррупция в стране, раз раздают лейблы направо и налево :)

 

Шутка хорошая, но вот тут на коррупцию не спишешь. Всё с обоюдного согласия всех со всеми ибо цель единая - БАБЛО. Другой цели нет вообще. Но почему зарабатывая бабло надо это делать на от*()сь. Мне непонятно.

[nemo]

А да была проблема на ведровере. Засыпал, просыпался и уже вообще никуда не хотел конектится.

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

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

[sfstudio]

Проблем немеряно. И не переключение после выпинывания, и переключение куда попало, и хаотичные дисконнекты, и флуд, и полная неработоспособность 802.1x к примеру, или залипания оного и т.д. и т.п.

 

Поэтому и грю на бумаге всё хорошо, в реальности сильно зависит от класса устройства, вендора, версии ПО и даже набора пользовательских приложений. =)))

 

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

[slv700]

Позвольте сделать несколько уточнений, которые возможно повернут дискуссию в конструктивное русло.

1) Роуминг -он же handover это процедура перехода клиента от одной точки доступа к другой при защищенной аутентификации 802.11x/EAP клиента. То есть если нет защищенной аутентификации по стандарту 802.11x- нет и handover по стандарту 802.11-2007 ( Pre-Authentification и OKC- расширение стандартного PMK-Caching, он же Roaming-back), а также по стандарту 802.11-2008 ( 802.11r).

На точках доступа обычно включаются ( так происходит на Камбиум) все методы роуминга ( Pre-Auth, OKC и 802.11r) , если клиент продвинутый, он идет по роумигу 802.11r ( время переключения handoff <50 мс, если нет - то по OKC и Pre-Authentication ( handoff <100 мс).

Есть несколько принципиальных моментов реализации handover при 802.11x/EAP доступе ( EAP handover).

a) клиент при переходе между точками доступа не проходит повторно полную аутентификацию,потому что зашифрованные PMK ключи каждого конкретного клиента имеет каждая точка доступа - точки доступа обмениваются роуминговой информацией непосредственно друг с другом ( Cambium) или через контроллер( например Aruba или Сisco. Полная процедура включает самый длительный этап 4-Way Handshaking ( 450 мс), так вот при сокращенной процедуре этот этап пропускается и занимает вместо 450 мс всего несколько мс.

б)Все клиентские устройства должны иметь драйвер вайфай с поддержкой EAP. Нет супликанта EAP- нет аутентификации , нет и роуминга.

Некоторые китайские устройства глючат или некорректно работают с ключами PMK. В этом случае роуминг все равно работает, но 4-Way Handshaking проходит по полной. В этом случае время handoff увеличивается на 450 мс и более ( если Radius далеко) и составляет в худшем случае < 600-700 мс.

b)при EAP handover-роуминге клиент не выбрасывается старой точкой доступа при достижении роумингового порога, не дисконнектится по радио от старой точки до того, как не ассоциируется ( Associated)с новой точкой, поэтому нет преждевременного физического дисконекта с сетью ( на смартфоне не тухнет значок подключения по вайфай ) и процедуры поиска частоты новой точки , которая может занимать несколько секунд. Никакая соседняя точка доступа ( с другим SSID) с самым сильным сигналом не может оторвать клиента от его роуминговой сети. Даже если по какой либо причине произошел дисконект ( пробелы в покрытии ), то клиент всегда вернется ( в течении определенного времени- пока в его EAP кеше хранятся ключи PMK) к своей сети - ближайшей роуминговой точке доступа с самым сильным сигналом. В самом худшем случае, если все таки идет дисконнект даже при перекрытии покрытия ( древний клиент или глюк драйвера), то EAP handover все равно работает , только время переключения увеличивается до 1200 мс и больше ( если клиент сваливаеся в сканирование частот).

Так работает стандартный 802.11x/EAP hadover роуминг, он реализован на соответствующем оборудовании, его работа не зависит от клиента (кроме 802.11r) и ничего изобретать и писать софт, "улучшающий" его работу не надо.

Так реализован handover Cambium, Cisco, Aruba, Ruckus и др. Этого нет у Микротика, нет и у UBNT. У ubnt ( не АС) имеется проприетарный роуминг, наываемый Zero-handoff ( изобретенный Meru), когда все точки доступа должны быть на одной частоте, что невозможно при перекрытии зон покрытия.

2) Роуминг при открытом доступе - назовем его open handover. Он в стандарте не прописан, его реализация каждым вендором проприетарная и там можно писать софт, ставить костыли , что собстственно и делает уважаемый sfstudio, ну и на здоровье и пожелаем ему успехов!

У Камбиум реализован свой проприетарный open handover без контролера . На Микротике реализован свой пропритетарный open handover с контролером. У Сisco open handover похоже вообще нет с контролером или без оного. У ubnt -тоже этого нет.

Есть несколько принципиальных моментов реализации open handover при открытом доступе.

a) поскольку нет аутентификации ( open доступ), то и нет задачи избавления от необходимости повторной аутентификации. Но вот если есть Сaptive Portal, то при open handover клиент при переходе между точками доступа не редиректиться на Captive Portal.

б)при Open handover клиент не выбрасывается старой точкой доступа при достижении роумингового порога, не дисконнектится по радио от старой точки до того, как не ассоциируется ( Associated)с новой точкой, поэтому нет преждевременного физического дисконекта с сетью ( на смартфоне не тухнет значок подключения по вайфай ) и процедуры поиска частоты новой точки , которая может занимать несколько секунд. Никакая соседняя точка доступа ( с другим SSID) с самым сильным сигналом не может оторвать клиента от его роуминговой сети ПРИ ПРАВИЛЬНОЙ реализации Open handover.

в) Но вот если по какой либо причине произошел дисконект клиента ( пробел в покрытии или глюкнул драйвер или др), то при open handover клиент легко может переключится на любую точку доступа вне роумингвой сети.

Эта и есть главная проблема open handover. Собственно именно в этом поле и работает sfstudio и совершенно неправильно его изыскания противопоставлять стандартному EAP handover.

Камбиум с этой проблемой ( которая возникает только при непроизвольном дисконекте клиента при open handoever, что иногда случается ) борется механизмом Rogue detect ( пока в роадмар).

У микротика -это главная и системно нерешаемая проблема его open handover,поскольку его реализация подразумевает всегда при смене точки доступа обязательный дисконект по радио клиента, скан частот и получение нового IP адреса.

Исследования sfstudio представляют интерес для сетей с открытым доступом с наличием соседей с мощными сигналами. В офисе и дома редко кто использует открытые сети. В хотспотах публичного доступа с открытым доступом - да есть такая проблема. Но тогда самому клиенту, если он не хочет постоянно выталкиваться из своей сети, надо просто напросто "забыть" в своем смартфоне соседние сети и проблемы не будет.

Поэтому задача sfstudio как теория интересна , но вот ее практическая значимость, по науке это называется актуальность задачи- IMHO сомнительная.

PS

Уважаемые ценители Микротика. Прежде чем утверждать, что на Микротик можно сделать роуминг, внимательно изучите одну страницу вышесказанного текста. Если есть возражения,замечания, уточнения , высказывайтесь.