gustas0617 Опубликовано 9 марта, 2017 · Жалоба Тут такой вапрос, как создать бесшовный Wi-Fi с поддержкой протоколов 802.11r, 802.11k без контроллера. Я знаю это можно сделать на оборудование Edimax, а можно на какое то другое оборудование? и есть ли инструкции? Про Cisco не говорю, там цена не подойдеть.ubnt не умеет, микротик тоже не очень верю что может. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ancient Опубликовано 9 марта, 2017 · Жалоба http://shop.nag.ru/catalog/00009.Besprovodnoe-oborudovanie/05935.Wifi-routery-SNR/17007.SNR-CPE-MD1 http://shop.nag.ru/catalog/00009.Besprovodnoe-oborudovanie/05935.Wifi-routery-SNR/16058.SNR-CPE-W4N-revM http://www.ebay.com/sch/i.html?_from=R40&_trksid=p2047675.m570.l1313.TR0.TRC0.H0.XAIR-CAP3502E-A-K9.TRS0&_nkw=AIR-CAP3502E-A-K9&_sacat=0 чем вас циска по цене не устаривает? От 900р точка двухдиапазонная N, c clean air и роумингом плюс блок питания вам обойдётся еще рублей в 500-800. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 9 марта, 2017 · Жалоба Edimax, Этот не поддерживает 802.11r/k. У него какой то свой проприетарный. 802.11r без контролера поддерживает Cambium cnPilot E400/E500. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gustas0617 Опубликовано 10 марта, 2017 · Жалоба на чет сылок на точки SNR там чипсеты MTK, на MTK нет поддержки 802.11r/k. А где в России можно купить Cisco по 900 рублей, там ebay из Америки? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 10 марта, 2017 · Жалоба на чет сылок на точки SNR там чипсеты MTK, на MTK нет поддержки 802.11r/k. А где в России можно купить Cisco по 900 рублей, там ebay из Америки? Cisco для роуминга нужен контроллер, который дороже точки доступа в несколько раз. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 10 марта, 2017 · Жалоба на чет сылок на точки SNR там чипсеты MTK, на MTK нет поддержки 802.11r/k. а разработчик прошивки пишет совсем другое В MT7620/MT7602/MT7612 поддержка 802.11K/R встроена в драйвер Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gustas0617 Опубликовано 10 марта, 2017 · Жалоба Edimax, Этот не поддерживает 802.11r/k. У него какой то свой проприетарный. 802.11r без контролера поддерживает Cambium cnPilot E400/E500. Cambium поддерживает только 802.11r, там нет протокола k. Edimax поддерживает обе протокола 802.11r/k, я сам тестировал и везде на сайте про это у них написано. Но только если без контроллера там настройки много времени занимает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 12 марта, 2017 · Жалоба на чет сылок на точки SNR там чипсеты MTK, на MTK нет поддержки 802.11r/k. Кто вам такое сказал? В нашем ПО поддержка 802.11k реализована для всех наших устройств в стабильной ветке. 802.11r для 5ГГц радио тоже в стабильной, и в для 2.4ГГц в эксперементальной (если сильно надо могу выдать по запросу сборки). Добьём багу в dev ветке драйвера для 7620 автоматом появиться и для 2.4ГГц. Для WPA Enterprise доступна поддержка preauth/pmk cache так же если клиент умеет то будет работать и okc. Кроме всего этого поддерживается и принудительный handoff для клиентов-залипал (которые либо не умеют ничего из роуминговых расширений, либо имеют кривую реализацию оных, к сожалению таких клиентов среди однобэндов большинство, с 5ГГц чуть легче, но тоже ~50% нифига не умеют). P.S. Штатные дрова выдаваемые MTK действительно чаще всего идут либо с неработающей, либо с вовсе вырезанной поддержкой 802.11k/r. Потому пришлось потратить море времени что бы заставить работать всё это дело на используемых у нас чипах. Наши ветки драйверов это уже далеко не то, что выдал MTK, правки коснулись буквально всего. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gustas0617 Опубликовано 14 марта, 2017 · Жалоба на чет сылок на точки SNR там чипсеты MTK, на MTK нет поддержки 802.11r/k. Кто вам такое сказал? В нашем ПО поддержка 802.11k реализована для всех наших устройств в стабильной ветке. 802.11r для 5ГГц радио тоже в стабильной, и в для 2.4ГГц в эксперементальной (если сильно надо могу выдать по запросу сборки). Добьём багу в dev ветке драйвера для 7620 автоматом появиться и для 2.4ГГц. Для WPA Enterprise доступна поддержка preauth/pmk cache так же если клиент умеет то будет работать и okc. Кроме всего этого поддерживается и принудительный handoff для клиентов-залипал (которые либо не умеют ничего из роуминговых расширений, либо имеют кривую реализацию оных, к сожалению таких клиентов среди однобэндов большинство, с 5ГГц чуть легче, но тоже ~50% нифига не умеют). P.S. Штатные дрова выдаваемые MTK действительно чаще всего идут либо с неработающей, либо с вовсе вырезанной поддержкой 802.11k/r. Потому пришлось потратить море времени что бы заставить работать всё это дело на используемых у нас чипах. Наши ветки драйверов это уже далеко не то, что выдал MTK, правки коснулись буквально всего. А тесты делали с аудио (VoIP) ? есть скриншоты пингов ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 14 марта, 2017 · Жалоба Тесты делали с UDP мультикаст трафиком, это гораздо более показательно т.к. перезапросить стрим нельзя (UDP такой UDP). И на нём сразу видно выпадение кадров если оно было (в отличии от хабровых тестов эдимакса и контроля пингами раз в секунду, поток шире в разы чем на голосе, перезапрос недолетевшего невозможен впринципе т.к. UDP + если выпал фрэйм в котором была часть опорного кадра то всё стопорнётся до следующего опорного кадра и это будет хорошо видно как в ролике на 0:43). Причём это WPA2+AES FT-PSK т.е. без всяких WPA Enterprise. И сделан тест оооочень давно, с тех пор ситуацию ещё несколько улучшили (в т.ч. для клиентов вообще ничего о роуминге не знающих). В момент миграции между АП у вас всегда будет перерыв передачи т.к. физически клиент в любом случае останавливает передачу с текущей АП и мигрирует на следующую. Весь вопрос бесшовности это дропнуться ли при этом соединения на клиенте (дропнет ли он стэйты). Если клиент стэйты не дропает, а приложения работают по TCP это вызовет лишь перепосыл маленького кусочка данных (ну сколько там выпало). Если льётся по UDP поток то эти данные (которые в момент миграции лились) просто потеряются т.к. UDP не гарантирует доставку. Сколько их потеряется уже зависит от времени переключения, которое в свою очереди зависит в первую очереть от прямости обработки клиентом link beat, наличия или отсутствия на клиенте логики миграции между АП по уровню/числу ошибок и т.д. (чаще всего клиенты залипают на АП пока оная их не выпнет, независимимо ни от каких FT и ынтырпрайзов), наличия или отсутствия на клиенте корректно работающего background scan для привентивного выбора АП до начала миграции без перерыва передачи (тоже не совсем без перерыва ;), и т.д. и т.п., а только потом от всяких ускорялок аля FT и прочие. Большая часть ответственности за корректность (включая время) миграции в 802.11 лежит на клиенте. А как это будет выглядеть для пользователя уже зависит от того насколько критична была потеря этих самых данных. Хочется нормального роуминга для голоса - use dect, там оно штатно. IP-DECT шлюзы нынче не дорогие. Роуминг в WiFi скорее нужен более с целью балансировки нагрузки на АП для обеспечения максимальной утилизации эфира, т.е. обеспечения работы клиентов на максимально возможных рэйтах вне зависимости от их положения, это позволяет обеспечить максимальную ёмкость на радиомодуль. А на 2х диапазонах до кучи добавляется ещё и Band Steering который решает ту же проблему но служит для балансировки 2.4/5 ГГц диапазонами ибо большинство даже супер-пупер клиентов так и наровят юзать 2.4 т.к. логика выбора кандидата АП для коннекта тупенькая и ориентируется в основном на RSSI. И ессно не добаляет прозрачности роумингу внося для таких клиентов доп задержку (часто по 3-5с приходиться на холде клиента держать что бы вынудить его зацепиться куда надо) если вдруг они решают съехать в 2.4 (ну нет других способов вынудить их вернуться в 5 кроме как не пустить в 2.4). А скриншотов пингов нотариально заверенных у меня нет и не будет, ибо не показательно. =))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
9598sp Опубликовано 14 марта, 2017 · Жалоба Тут такой вапрос, как создать бесшовный Wi-Fi с поддержкой протоколов 802.11r 802.11k без контроллера. Я знаю это можно сделать на оборудование Edimax, а можно на какое то другое оборудование? и есть ли инструкции? Про Cisco не говорю, там цена не подойдеть.ubnt не умеет, микротик тоже не очень верю что может. Точки доступа Ruckus или Cisco. Европе все ставит эти бренды в нормальные проекты. Контроллер обезательно ставит. Без контроллера контроллера - безумность какая то. Только с контроллерам. Если дешевле - да Edimax, но там не все ТД поддерживает протоколы 802.11r 802.11k. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 14 марта, 2017 · Жалоба Для работы 802.11r и 802.11k не требуется никаких контроллеров в принципе. Более того для 802.11r не нужен даже радиус сервер и он вполне может работать с WPA Personal режимом, для этого есть FT-PSK и циски его прекрасно умеют. Необходимость наличия контроллера за много зелени, желательно ещё с не бесплатной подпиской на обновления (а то сертификат нечайно протухнет ещё для радиуса, и т.д. и т.п.) это прекрасный маркетинговый ход и только. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gustas0617 Опубликовано 14 марта, 2017 · Жалоба Тесты делали с UDP мультикаст трафиком, это гораздо более показательно т.к. перезапросить стрим нельзя (UDP такой UDP). И на нём сразу видно выпадение кадров если оно было (в отличии от хабровых тестов эдимакса и контроля пингами раз в секунду, поток шире в разы чем на голосе, перезапрос недолетевшего невозможен впринципе т.к. UDP + если выпал фрэйм в котором была часть опорного кадра то всё стопорнётся до следующего опорного кадра и это будет хорошо видно как в ролике на 0:43). Причём это WPA2+AES FT-PSK т.е. без всяких WPA Enterprise. И сделан тест оооочень давно, с тех пор ситуацию ещё несколько улучшили (в т.ч. для клиентов вообще ничего о роуминге не знающих). В момент миграции между АП у вас всегда будет перерыв передачи т.к. физически клиент в любом случае останавливает передачу с текущей АП и мигрирует на следующую. Весь вопрос бесшовности это дропнуться ли при этом соединения на клиенте (дропнет ли он стэйты). Если клиент стэйты не дропает, а приложения работают по TCP это вызовет лишь перепосыл маленького кусочка данных (ну сколько там выпало). Если льётся по UDP поток то эти данные (которые в момент миграции лились) просто потеряются т.к. UDP не гарантирует доставку. Сколько их потеряется уже зависит от времени переключения, которое в свою очереди зависит в первую очереть от прямости обработки клиентом link beat, наличия или отсутствия на клиенте логики миграции между АП по уровню/числу ошибок и т.д. (чаще всего клиенты залипают на АП пока оная их не выпнет, независимимо ни от каких FT и ынтырпрайзов), наличия или отсутствия на клиенте корректно работающего background scan для привентивного выбора АП до начала миграции без перерыва передачи (тоже не совсем без перерыва ;), и т.д. и т.п., а только потом от всяких ускорялок аля FT и прочие. Большая часть ответственности за корректность (включая время) миграции в 802.11 лежит на клиенте. А как это будет выглядеть для пользователя уже зависит от того насколько критична была потеря этих самых данных. Хочется нормального роуминга для голоса - use dect, там оно штатно. IP-DECT шлюзы нынче не дорогие. Роуминг в WiFi скорее нужен более с целью балансировки нагрузки на АП для обеспечения максимальной утилизации эфира, т.е. обеспечения работы клиентов на максимально возможных рэйтах вне зависимости от их положения, это позволяет обеспечить максимальную ёмкость на радиомодуль. А на 2х диапазонах до кучи добавляется ещё и Band Steering который решает ту же проблему но служит для балансировки 2.4/5 ГГц диапазонами ибо большинство даже супер-пупер клиентов так и наровят юзать 2.4 т.к. логика выбора кандидата АП для коннекта тупенькая и ориентируется в основном на RSSI. И ессно не добаляет прозрачности роумингу внося для таких клиентов доп задержку (часто по 3-5с приходиться на холде клиента держать что бы вынудить его зацепиться куда надо) если вдруг они решают съехать в 2.4 (ну нет других способов вынудить их вернуться в 5 кроме как не пустить в 2.4). А скриншотов пингов нотариально заверенных у меня нет и не будет, ибо не показательно. =))) А где у вас инструкции по настройке, на сайте я видел только описание настройки Handover. Но там небыло детально описано настройки R роуминга. И SNR-CPE-MD1 это самое лучшее что есть в линейке ? есть ли что то професиональное ? на пример 3x3 mimo. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 14 марта, 2017 · Жалоба 1) Рядом раздел по устройствам SNR. 2) Настройка K/R сводиться к их активации в роже 3) Настройка WPA-Enterprise описана там же в разделе 4) А чего не 6x6? Ещё же более проффессионально. И пофигу что офисные клиенты в 80% (а в случае с планшетами, телефонами и VoIP трубками все 99%) это 1T1R =))) Или к каждому клиенту ещё по точке в режиме клиента примотаете? =) STBC тоже хоть в 2x2 хоть в 3x3 хоть в 6x6 использует только 2 стрима (такое вот оно в 802.11). MU-MIMO даже будь на АП поддержка требует так же поддержки на стороне клиента иначе будет работать в Legacy так что и сюда эти 3x3 не привернуть. Что значит профессиональное? =))) С лэйбой мегаынтырпрайз или Pro ? =)))) Нет ну ок... Поиграем в буквоеда https://ru.wiktionary.org/wiki/%D0%BF%D1%80%D0%BE%D1%84%D0%B5%D1%81%D1%81%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9 В контексте чего наше железо не профессиональное? Или какое-то другое более профессиональное? =))) P.S. Научитесь цитировать. Или если отвечаете без уточнения не цитируйте вовсе. Оверквотинг тут не приветствуется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gustas0617 Опубликовано 16 марта, 2017 · Жалоба 4) А чего не 6x6? Ещё же более проффессионально. И пофигу что офисные клиенты в 80% (а в случае с планшетами, телефонами и VoIP трубками все 99%) это 1T1R =))) Или к каждому клиенту ещё по точке в режиме клиента примотаете? =) STBC тоже хоть в 2x2 хоть в 3x3 хоть в 6x6 использует только 2 стрима (такое вот оно в 802.11). MU-MIMO даже будь на АП поддержка требует так же поддержки на стороне клиента иначе будет работать в Legacy так что и сюда эти 3x3 не привернуть. все знают что 2x2 mimo лучше чем 1x1 mimo. И на чет настройки 802.11r, больше инфо не нашел, только enable/disable. но при установке без контроллера откуда клиенту знать какое щифрования и ключ второй ТД на которую он переключается, иначе вес процесс 802.11x Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 16 марта, 2017 · Жалоба 1) у нас оно и так 2T2R в 2.4, в 5ке пока 1T1R, на подходе 4T4R DBDC (т.е. либо в 2х диапазонах как 2T2R либо в одном как 4T4R в зависимости от задачи), вот при 2T2R AP и 1T1R клиенте есть профит, при а вот дальше хоть 6T6R поставь если клиент умеет только 1T1R или 2T2R профита не будет. Почему так - поиск по форуму, разжовывал не раз. Да и профит от STBC хоть и есть, но в схемах с ромингом на него можно забить т.к. покрытие должно быть обеспечено с запасом и выигрыш в виде пары dB сказываться не должен никак. 2) в зависимости от, либо при FT-PSK ключ задаётся везде один в настройках шифрования, либо при Enterprise ключиками заведует радиус сервер на любой АП к которой подключаются остальные или на отдельной машине (обычно разворачивают на шлюзе). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...