[Sergey M.]

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

Желателен более-менее приличный внешний вид и отсутствие проблем с устройствами Apple. Обязательна поддержка стандарта AC.

Смотрел на uni-fi, но непонятно на сколько все это качественно работает. Микротик страшненький и вечные проблемы с айфонами.

Всякие асусы и зиксели не умеют роуминг на бытовых точках, как я понял.

Так поглядишь на это и хочется просто купить пару цисковских точек с ебея и не мучаться. :-)

 

Но вдруг есть простое, проверенное и более-менее бюджетное решение?

[slv700]

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

Желателен более-менее приличный внешний вид и отсутствие проблем с устройствами Apple. Обязательна поддержка стандарта AC.

Смотрел на uni-fi, но непонятно на сколько все это качественно работает. Микротик страшненький и вечные проблемы с айфонами.

Всякие асусы и зиксели не умеют роуминг на бытовых точках, как я понял.

Так поглядишь на это и хочется просто купить пару цисковских точек с ебея и не мучаться. :-)

 

Но вдруг есть простое, проверенное и более-менее бюджетное решение?

Cambium E400 2.4 и 5 ГГц( АС). MSRP $199. Роуминг без контролера.

[DRiVen]

Не хотите проблем с огрызками? Гарантированное решение - AirPort, Time Capsule, etc. Остальные варианты, так или иначе, зависят от правильности геометрии рук и кривизны прошивки, примерно 80/20.

 

P.S>slv700, ты реально задрал уже, коробейник блин.

[Sergey M.]

Не хотите проблем с огрызками? Гарантированное решение - AirPort, Time Capsule, etc. Остальные варианты, так или иначе, зависят от правильности геометрии рук и кривизны прошивки, примерно 80/20.

 

P.S>slv700, ты реально задрал уже, коробейник блин.

с циской огрызки работают на ура. Дома на кинетике гига тоже проблем ни разу не было, а вот первые вариации кинетиков огрызки не любили.

AirPort прекрасен, но вопроса роуминга не закрывает.

[DRiVen]

Наверное удивлю, но у меня и на МТ (не сочтите за рекламу) с огрызками проблем нет, были некоторые, не очевидные моменты с настройкой, да и то с копролитами, типа окаменелостей 2-ой - 3-ей моделей. С роумингом на wifi все печально, это должны уметь в первую очередь сами клиенты, чего в основном не наблюдается. Напишите sfstudio, он вплотную этим занимается.

Изменено 5 апреля, 2016 пользователем DRiVen

[rdc]

я клиентам с большими квартирами ставлю нанку M2.

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

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

 

но это не про AC, конечно…

[nemo]

Тоже буду не оригинален, порекомендую Моторолу экспресс. Как раз для данного случая. По ценнику очень близко к убиквити.

[Sergey M.]

Тоже буду не оригинален, порекомендую Моторолу экспресс. Как раз для данного случая. По ценнику очень близко к убиквити.

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

Хочется один раз настроить и забыть на года.

[nemo]

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

Хочется один раз настроить и забыть на года.

Это профессиональное решение до которого многим вендорам еще расти. Болячек не знаю. Производительность на промышленном уровне.

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

[slv700]

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

Чего, чего ? Роуминг 802.11r согласен, клиенты должны поддерживать,но по ВСЕМ остальным типам роуминга(handover)- нет такого требования к клиентам.

ЗЫ

Не владеешь темой, так помолчи, реально задрала уже пионерия :-).

 

Моторолу экспресс.

Нет такой фирмы и оборудования с таким брендом, не вводите людей в заблуждение. Есть Zebra и ценник у нее далеко не ubnt.

 

упрощеннос сказать, точка управляет сетью и ведет клиента, как только видит что он в зоне другой точки где сигнал хороший, переключает туда.

Не надо упрощенно. Скажите конкретно, какие из стандартных методов роуминга ( handover) поддерживает Zebra: Pre-Authentification, OKC, 802.11r? Нужен ли для роуминга Зебре отдельный контроллер?

[sfstudio]

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

 

Подробнее расскажите фармакинетику, тьфу, механику процесса. А ещё со ссылками на спеки расскажите как вы скажете клиенту перейти на вот эту конкретную AP. Конкретно что ему нужно послать? Конкретно линк.

 

А то одни бла бла бла. Проф уровень, промышленная производительность. Оно промышленно производительно шлёт клиенту DEAUTH? =)

 

Мои изыскания на тему нормального поддержки роуминга тут http://forum.nag.ru/forum/index.php?showtopic=108990&view=findpost&p=1194503 В кратце - хрен вам, а не нормальный роуминг в силу того, что современные клиенты либо вообще ничего из роуминговых расширений не умеют, либо умеют криво, либо совместимы только внутри вендорспецифик решений (apple->apple).

 

Универсально можно только по уровню выпинывать и ждать что оно законнектиться к более "близкой" АП, ну попутно запрещать коннект на AP с клинтов с низким уровнем. Сказать клиенту - мигрируй ка по возможности туда, на конкретную АП, в 802.11 низя никаким образом. Выбор куда будет долбиться клиент увы лежит на клиенте и встречаются напрочь тупые клиенты которые не то что в фоне не ведут базу доступных для миграции АП, но даже когда их нагло выпнули рескан не делают а сразу лупятся на ту же АП.

 

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

 

А весь контроллер это зачастую общий DHCP сервер местами с радиусом для авторизации по 802.1x c precache (то что хоть кто-то нормально умеет) + собиралка статистики которая не особо в квартире упёрлась. Поддержка 802.11K/R полноценная и совместимая до сих пор практически отсутствует в мобильных клиентах. И даже заявления гугла о поддержке в ведроиде увы не гарантия, что оно там есть, всё сильно зависит от железа, вендора и т.д.

 

Нормальной схемы роуминга в wifi как не было так и нет.

 

А вариант с распиныванием клиента по уровню прекрасно строиться на тех же SNR-CPE-W4N revM или SNR-CPE-MD1 (второй предпочтительней за счёт 2х диапазонов), поддержка band steering на MD1 так же included как и 802.1x если ну очень надо. Поддержка K/R в процессе разработки, какраз чую допилим и хоть сколько-то клиентов из коробки его будет уметь. Пока даже специально найти ни одного клиента из доступных на руках у друзей (перебрано почти сотня устройств) с поддержкой K/R кроме одного яблока не удалось.

 

P.S. Ждём распространения WiGyg там обещают из коробки заложить логику миграции, оно и ясно ибо чуть за преграду и сигнала нема.

PP.S. Для ведроида проще использовать костыль https://play.google.com/store/apps/details?id=com.heleron.wifiroamingfix&hl=ru будет работаь с любой AP и сама при низком уровне принимать решение и реконнектиться. Для ябла тоже есть нечто подобное. Отдавать конские деньги за домашние АП ради роуминга который один фиг будет работать с большинством клиентов исключительно на уровне "я тебя пну, а ты там как-нить сам", полная дурь.

[sfstudio]

но по ВСЕМ остальным типам роуминга(handover)- нет такого требования к клиентам.

 

Вы даже меня убедили что пинок это тоже роуминг, потому в роже SNR я с вашего позволения это именно так и назвал =))) Хотя на мой взгляд эт пародия на роуминг (выкинуть клиента и не пущать с низким уровнем играя в рулетку и надеятся на вменяемость клиента).

[slv700]

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

В правильном handover делается не так. Если у клиента понизился уровень UL SNR ( UL RSSI)ниже порога, то база сразу его не дисконнектит ( типа дальше сам), а тянет его до последнего, пока клиент не найдет новую базу с допустимым уровнем UL сигнала. Старая база узнает о том, что клиент нашел новую базу ( и только тогда дисконектит его) путем обмена роуминговыми сообщениями между базами ( в одном броадкаст домене- домене мобильности). Так работает роуминг Камбиум. И это не 802.11r/k ( там где умный клиент еще и выбирает базу), хотя у Камбиум роуминг 802.11r over DS и Over the Air тоже реализован, полноценно работает на клиентах Apple и Samsung S5. Если задать роуминг 802.11r и пришел клиент, который 802.11r не поддерживает, то handover идет по тому же сценарию ( без диконекта, без скана частот с поиском новой базы и получения нового ip адреса), но c полным циклом аутентификации 4-way handshaking, то есть только увеличивается время переключения handoff на 450-600 мс.

[sfstudio]

В правильном handover делается не так. Если у клиента понизился уровень UL SNR ( UL RSSI)ниже порога, то база сразу его не дисконнектит ( типа дальше сам), а тянет его до последнего, пока клиент не найдет новую базу с допустимым уровнем UL сигнала. Старая база узнает о том, что клиент нашел новую базу ( и только тогда дисконектит его) путем обмена роуминговыми сообщениями между базами ( в одном броадкаст домене- домене мобильности). Так работает роуминг Камбиум.

 

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

 

Как новая база узнает, что клиент готов на неё перепрыгнуть?

 

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

 

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

 

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

 

Я это в лабе за пол года перепроверил тонну раз. На бумаге всё хорошо, в реальности...

 

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

 

Всё было бы сильно проще буть в 802.11 передать клиенту MAC станции для миграции или сказать ему сделать рескан при падении уровня.

[slv700]

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

Я таких клиентов на Andoid и тем более Apple не встречал, за виндовс и др. -не знаю.

 

Как новая база узнает, что клиент готов на неё перепрыгнуть?

 

Association Request.

[sfstudio]

хотя у Камбиум роуминг 802.11r over DS и Over the Air тоже реализован, полноценно работает на клиентах Apple и Samsung S5. Если задать роуминг 802.11r и пришел клиент, который 802.11r не поддерживает, то handover идет по тому же сценарию ( без диконекта, без скана частот с поиском новой базы и получения нового ip адреса), но c полным циклом аутентификации 4-way handshaking, то есть только увеличивается время переключения handoff на 450-600 мс.

 

1) не на всех apple и не на всех версиях IOS (на сайте ябла есть таблички даже) + там (со стороны АП) требуется ещё костыль для R что бы яблочная продукция полноценно его поняла, благо костыль уже включен чипмэйкерами в SDK (как минимум у MTK/Atheros включен)

2) не на всех ревизиях S5

 

S5 я хорошо изучил с точки щрения R.

 

802.11r и пришел клиент, который 802.11r не поддерживает, то handover идет по тому же сценарию ( без диконекта, без скана частот с поиском новой базы и получения нового ip адреса), но c полным циклом аутентификации 4-way handshaking, то есть только увеличивается время переключения handoff на 450-600 мс.

 

Эт вы с чего взяли что без рескана? И как он должен выбрать куда коннектиться? Другое дело что S5 и Apple это редкие представители которые постоянно в пассивном режиме сканят эфир и на момент дисконнекта они уже знают куда мигрировать. Но увы на них мир не заканчивается.

 

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

 

Без перезапроса IP да, для этого и R не нужен, у меня DHCP ip привязывает к хэшу мака и если клиент не придуривается то при миграции никакого перезапроса адреса не происходит (какраз Apple и S5 в этом плане ведут себя верно, планшеты на MTK все опять по полной перезапрашивают адрес и флушат контрак, и так поступает вообще большинство клиентов).

[slv700]

прекрасно если он может сам принять правильное решение куда коннектиться.

Да ничего клиент сам ( окромя как в 802.11K - Radio Resorce Management) не знает , он туп и никаких решений не принимает. Дисконектят его и принимают базы по согласованию между собой.

[sfstudio]

Я таких клиентов на Andoid и тем более Apple не встречал, за виндовс и др. -не знаю.

 

Зато я встречал тонну, и в кладовке валяется стопка планшетов и все они...

 

Association Request.

 

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

 

Да ничего клиент сам ( окромя как в 802.11K - Radio Resorce Management) не знает , он туп и никаких решений не принимает. Дисконектят его и принимают базы по согласованию между собой.

 

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

 

Грю вы в своём мире топовых самсунгов и Apple забываете, что в более приземлённом мире всевозможных DIGMA,DNS,HIGHSCREEN/etc и прочих ни о каких 802.11K и речи не идёт, ни о каких R не идёт и вообще оно даже базовые вещи без полного дисконнекта не умеет.

 

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

[sfstudio]

Ну и я просто оставлю это здесь:

https://code.google.com/p/android/issues/detail?id=17972#c18

 

#17 adegi...@gmail.com 
Simple question. Does Android Support both 802.11k and 802.11r?
Jan 27, 2015 
#18 mobileme...@gmail.com 
From what I can tell, 802.11r - Yes, in lollipop. 802.11k - No.
I'd like to know if it's available too, or when it might be available.

 

Даже расширю, сильно зависит от конкретного вендора и чипа используемого радио, прямости рук программеров и т.д. С тех пор мало что изменилось, хотя хоть гугл сподвигся для нексусов сделать для новых нормальную поддержку R, чую придётся его купить для отладки этого дела у нас в ПО.

[slv700]

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

[sfstudio]

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

 

Это вполне реализуется через 802.11 recache у нас.

 

Даже если при handover произощел дисконект cо всеми базами по причине древности клиента, то фиг с ним, и есть еще главное -втрое , чтобы клиент не переключился к базам с другим SSID и более мощным сигналам.

 

Это опять таки исключительно прироготива клиента. Объясните моей DIGMA IDS что надо коннектиться к базе SSID=123 если рядом есть SSID=234 с более высоким уровнем и к ней уже коннектились когда-то (т.е. она запомнена). Никакие ухищрения со стороны AP решить эту проблему не помогут. Тут поможет только правка логики ведроида в connection manager и wpa_supplicant который при рескане сначала выберет AP с тем же SSID в который пнул клиент, и если только она не пустит будет или не будет пытаться коннектиться к другим "знакомым" ему АП. Некотоые ведроиды при включении WIFI вообще не спрашивая юзверя коннектятся к чему попало лишь бы открытому, и открытые сети у них вообще в приоритете даже если есть сохранённое соединение с вашей личной сетью, и никак вы на это без колупания в кишках клиента не повлияете.

 

А роуминг этот вопрос решает.

 

Увы нифига он не решает.

 

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

[slv700]

Это вполне реализуется через 802.11 recache у нас.

По науке это называется PMK caching.

[sfstudio]

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

 

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

 

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

 

Это вполне реализуется через 802.11 recache у нас.

По науке это называется PMK caching.

 

Угу, и по науке должно работать везде и одинаково, но даже тут есть проблемы. Как прмер LG G2 mini временами клинит ;( А на этой платформе что и L2 G2 построена тонна распространённых устройств и никто лечить это не будет. Пришлось лепить костыль со стороны AP.

[slv700]

оннектятся к чему попало лишь бы открытому, и открытые сети у них вообще в приоритете

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

Роуминг -это вообще то Secure Roaming, то есть неразрывно связан с 802.11x/EAP аутентификацией. Ключи PMK и не дают выйти клиенту из роуминговой сети дисконнектом и переключением на другой SSID. Но если сеть открытая, то там есть эта проблема. Вы ее решаете какими то костылями, но в реальных сетях актуальность решения этой задачи мизерная.

[sfstudio]

В общем моё мнение с роумингом всё тухло, и большей частью по причине того, что не угадаешь что умеет клиент и насколько он прям. В тепличных условиях с контроллируемыми типами клиентов (например для сотрудников раздать яблофоны и S5е конкретной ревизии с конкретной версией ПО проверенной) это одно, а когда ХЗ что там из клиентов сегодня будет, и уж тем более не ясно что будет завтра сразу картина меняется.

 

И как я уже говорил проблема в том, что WiFi Alliance при сертификации не требует обязательной реализации поддержки роуминговых расширений 802.11. Да и вообще вся эта сертификация больше на цирк похожа.

 

Роуминг -это вообще то Secure Roaming, то есть неразрывно связан с 802.11x/EAP аутентификацией. Ключи PMK и не дают выйти клиенту из роуминговой сети на другой SSID. Но если сеть открытая, то там есть эта проблема.

 

1) Роуминг это вообще-то роуминг. Секурный он или не секурный дело 9999е.

2) Ещё раз грю, увидит кривой клиент описанный выше рядом сеть с высоким уровнем к которой уже когда-то коннектились и при засыпании/просыпании ведроида упадёт на неё, опять же попросите в салоне каком-нить DIGMA HIT на погонять, мы с Андреем там хотя и исключили некорректное поведение в некоторых случаях, но проблема там всё ещё существует ибо я ушёл с подряда DIGMA (поступило более вкусное предложение), а Андрею оно нафиг не надо было с этим заморачиваться. Вот так и живёт. А учитывая что 90% вендоров лепящих планшеты на MTK вообще не заглядывают в эту часть логики ведроида... Мне даже страшно предположить сколько устройств подвержено такой проблеме.

 

P.S. Вы не забывайте, я 3 года параллельно занимался планшетами на ведроиде. Как минимум повидал Allwinner/MTK/Amlogic/Intel SDK под ведроид. Плохо там всё как с секурностью так и просто со здравым смыслом. Это не говоря уже что обычно даже дрова, даже если в них есть поддержка чего-то из K/R то собираются без неё и никому до этого дела нет. А 802.1х из коробки на риалтэковых чипах в андроидах не пахал до недавнего времени вообще (не смотря на наличие в UI). Вот такие вот дела. Как бы мне не хотелось согласиться с вами на тему что вот она панацея, но это нифига не так.

 

Прошу прощения, надо ещё кой чего доделать да спать.