Тут такой вапрос, как создать бесшовный Wi-Fi с поддержкой протоколов 802.11r, 802.11k без контроллера.

Я знаю это можно сделать на оборудование Edimax, а можно на какое то другое оборудование? и есть ли инструкции?

 

Про Cisco не говорю, там цена не подойдеть.ubnt не умеет, микротик тоже не очень верю что может.

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


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

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.

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


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

Edimax,

Этот не поддерживает 802.11r/k. У него какой то свой проприетарный.

802.11r без контролера поддерживает Cambium cnPilot E400/E500.

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


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

на чет сылок на точки SNR там чипсеты MTK, на MTK нет поддержки 802.11r/k.

 

А где в России можно купить Cisco по 900 рублей, там ebay из Америки?

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


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

на чет сылок на точки SNR там чипсеты MTK, на MTK нет поддержки 802.11r/k.

 

А где в России можно купить Cisco по 900 рублей, там ebay из Америки?

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

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


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

на чет сылок на точки SNR там чипсеты MTK, на MTK нет поддержки 802.11r/k.

а разработчик прошивки пишет совсем другое

В MT7620/MT7602/MT7612 поддержка 802.11K/R встроена в драйвер

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


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

Edimax,

Этот не поддерживает 802.11r/k. У него какой то свой проприетарный.

802.11r без контролера поддерживает Cambium cnPilot E400/E500.

 

Cambium поддерживает только 802.11r, там нет протокола k.

Edimax поддерживает обе протокола 802.11r/k, я сам тестировал и везде на сайте про это у них написано. Но только если без контроллера там настройки много времени занимает.

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


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

на чет сылок на точки 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, правки коснулись буквально всего.

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


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

на чет сылок на точки 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) ? есть скриншоты пингов ?

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


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

Тесты делали с 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).

 

А скриншотов пингов нотариально заверенных у меня нет и не будет, ибо не показательно. =)))

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


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

Тут такой вапрос, как создать бесшовный Wi-Fi с поддержкой протоколов 802.11r 802.11k без контроллера.

Я знаю это можно сделать на оборудование Edimax, а можно на какое то другое оборудование? и есть ли инструкции?

 

Про Cisco не говорю, там цена не подойдеть.ubnt не умеет, микротик тоже не очень верю что может.

 

Точки доступа Ruckus или Cisco. Европе все ставит эти бренды в нормальные проекты. Контроллер обезательно ставит. Без контроллера контроллера - безумность какая то. Только с контроллерам.

Если дешевле - да Edimax, но там не все ТД поддерживает протоколы 802.11r 802.11k.

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


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

Для работы 802.11r и 802.11k не требуется никаких контроллеров в принципе. Более того для 802.11r не нужен даже радиус сервер и он вполне может работать с WPA Personal режимом, для этого есть FT-PSK и циски его прекрасно умеют. Необходимость наличия контроллера за много зелени, желательно ещё с не бесплатной подпиской на обновления (а то сертификат нечайно протухнет ещё для радиуса, и т.д. и т.п.) это прекрасный маркетинговый ход и только.

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


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

Тесты делали с 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.

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


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

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. Научитесь цитировать. Или если отвечаете без уточнения не цитируйте вовсе. Оверквотинг тут не приветствуется.

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


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

 

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

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


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

1) у нас оно и так 2T2R в 2.4, в 5ке пока 1T1R, на подходе 4T4R DBDC (т.е. либо в 2х диапазонах как 2T2R либо в одном как 4T4R в зависимости от задачи), вот при 2T2R AP и 1T1R клиенте есть профит, при а вот дальше хоть 6T6R поставь если клиент умеет только 1T1R или 2T2R профита не будет. Почему так - поиск по форуму, разжовывал не раз. Да и профит от STBC хоть и есть, но в схемах с ромингом на него можно забить т.к. покрытие должно быть обеспечено с запасом и выигрыш в виде пары dB сказываться не должен никак.

2) в зависимости от, либо при FT-PSK ключ задаётся везде один в настройках шифрования, либо при Enterprise ключиками заведует радиус сервер на любой АП к которой подключаются остальные или на отдельной машине (обычно разворачивают на шлюзе).

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


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

Для публикации сообщений создайте учётную запись или авторизуйтесь

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

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!


Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.


Войти
Подписчики 0