Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

Wi-CAT LLC
Навигация Форума
Вы должны войти, чтобы создавать сообщения и темы.

Бесшовная миграция - wive-ng вопросы.

Доброго времени суток.

Просьба к автору статей про роуминг допилить типовую настройку из 2 роутеров

Банальные вопросы:

1. Режим работы устройства

2. Имена сети WiFi

3. 811.k и 811.r надо ли это или использовать настройку по уровням

Просьба не пинать.

Понимаю автору и так работы хватает.

Цикл статей не полон ..

Заранее спасибо

А что там дописывать про настройку? Включаем 802.11k/r 2 галки, выставляем одинаковые SSID. Первый роутер в режиме роутера второй в режиме AP. Больше ничего не трогаем. Соединяем кабелем - профит.

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

Но вот только для этого желательно юзать не роутеры с OMNI антеннами, а потолочные или секторные AP. Иначе зона где  у клиента сработает триггер handover`а к переключению может оказаться очень далеко от желаемой зоны и придётся ронять мощность почти в 0 или отказываться от бесшовности призывая на помощь handoff.

Всё остальное в виде размещения и выбора оборудования под конкретные условия и задачи (что крайне важно при организации нормального покрытия) это ещё статей 5ть. Увы нет пока возможности заниматься писательством.

Цикл статей время от времени дополняется. Будет время - будет продолжение.

Чуть не забыл.  В настройках DHCP сервера на роутере выставляем Address conflict check timeout в 0 иначе в некоторых случаях будет задержка при миграции на клиентах которые перед исполнением handover зачем-то "прощаются" с DHCP и отпускают адрес.

Спасибо за ответ.

Цитата: sfstudio от 09/04/2019, 15:52

А что там дописывать про настройку? Включаем 802.11k/r 2 галки, выставляем одинаковые SSID. Первый роутер в режиме роутера второй в режиме AP. Больше ничего не трогаем. Соединяем кабелем - профит.

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

Но вот только для этого желательно юзать не роутеры с OMNI антеннами, а потолочные или секторные AP. Иначе зона где  у клиента сработает триггер handover`а к переключению может оказаться очень далеко от желаемой зоны и придётся ронять мощность почти в 0 или отказываться от бесшовности призывая на помощь handoff.

Всё остальное в виде размещения и выбора оборудования под конкретные условия и задачи (что крайне важно при организации нормального покрытия) это ещё статей 5ть. Увы нет пока возможности заниматься писательством.

Цикл статей время от времени дополняется. Будет время - будет продолжение.

Чуть не забыл.  В настройках DHCP сервера на роутере выставляем Address conflict check timeout в 0 иначе в некоторых случаях будет задержка при миграции на клиентах которые перед исполнением handover зачем-то "прощаются" с DHCP и отпускают адрес.

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

Еще раз прошу не пинать

P. S. Сейчас настроил, точки на 6 канале обе, переключается быстро  но обрыв потокового аудио с буфером 512к есть ...

Сам факт переброс с одной на другую точку очень очень быстрый!

Спасибо за идею и реализацию!

  1. автовыбор канала в случае HD сетей зло как оно есть, руками.
  2. Один или несколько зависит от цели. На одном канале процедура на всех клиентах без поддержки RRM будет проходить в разы быстрее, на разных - больше клиентов можно будет приземлить. Типовые схемы 1/11 20MHz  36/64 80MHz. Если большинство клиентов умеет 40МГц полосу в 2.4ГГц и таргет - квартира, то большие пиковые скорости будут достигаться при ипользовании в 2.4ГГц одного канала и полосы в 40МГц. Часть клиентов  бесшовно мигрирует только между АП на одном канале, при использовании разных (в силу того что не умеет получать данные с RRM) выполняет рескан диапазона а это до ~7с.
  3. Насколько бесшовно будет проходить миграция на 90% зависит от клиента и того что он умеет (без использования handoff в смысле). На SGS A5, например, даже iperf не прерывается при переходе. А ноутбуки с современными Intel картами и правильно выбранным режимом агрессивности роуминга (в настройках драйвера, для квартиры стоит выставить "максимальный") мигрируют вообще без проблем почти на любом железе на стороне сети. Суть в том, что AP может только помочь миграции предоставив нужную инфу через RRM или предоставить возможность использовать короткую (FT) процедуру аутентификации на новой AP, ну максимум DS подготовить (см статьи всё есть). В остальном всё на совести клиента. Сейчас в топовых железках появилась поддержка BTM (в топовых клиентах) в будущем его приюзаем обязательно, пока просто нет на руках клиента нормально оный обрабатывающего. К сожалению большинство железеяк под Android вообще ничего не умеет из расширений касаемо миграции, и слава богу что к 2019г они таки научились сами инициировать миграцию хотя бы по уровню, раньше только с пинка со стороны АП (handoff)

В общем эксперементируйте какой вариант будет в ваших условиях и на ваших клиентах работать лучше. Тут не угадать ибо реализации на клиентах разношёрстные и только недавно WifiAlliance запустил программу сертификации на тему миграции (voice enterprise) и только только начало это дело устаканиваться. Лет 5ть пройдёт минимум пока этот бардак весь сойдёт на нет.

Спасибо буду пробовать.

Цитата: sfstudio от 09/04/2019, 15:52

А что там дописывать про настройку? Включаем 802.11k/r 2 галки, выставляем одинаковые SSID. Первый роутер в режиме роутера второй в режиме AP. Больше ничего не трогаем. Соединяем кабелем - профит.

Приветствую!

А если не по кабелю? В данный момент стоит роутер SNR-CPE-ME1, подключенный к провайдеру и ZyXEL Keenetic Viva в режиме репитера. Между ними нет кабеля. К ZyXEL по кабелю подключены два Samsung SMART и ПК, всё работает, но проблема  в том, что у него нет 5GHz.

Хочу вместо ZyXEL вкрутить второй SNR-CPE-ME1, но то ли я слепой, то ли не то ищу, но не могу найти внятную инструкцию по настройке моей конфигурации. На обоих роутерах версия прошивки:  8.2.11.RU.05102019. На втором выбран режим Клиент + AП + Шлюз(WISP) / Клиент + AП + Мост(Repeater)

В настройках "Клиент/Репитер", настроено подключение к сети 5GHz, стоит галка "Включить режим моста"
В настройках "Основные" на обоих роутерах настроены одинаковые SSID, каналы, пароли и сделаны однотипные дефолтовые настройки роуминга.
И вот что делать дальше, я ума не приложу. Буду благодарен за пинок хоть под пятую точку, но в нужную сторону .

Не понял вопроса. Всё ровно так же настраивается. Один в режиме роутера другой цепляется к нему AP+CLIENT(Reapeter) или даже WDS, включается K/R.

Что именно-то не получается?

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

Однако опорная сеть по воздуху это беда даже если прямо сейчас проблем не видно. Мой вам совет. Тяните кабель.

Цитата: sfstudio от 15/10/2019, 00:25

Не понял вопроса. Всё ровно так же настраивается. Один в режиме роутера другой цепляется к нему AP+CLIENT(Reapeter) или даже WDS, включается K/R.

Вопрос в последовательности действий для корректной настройки второго устройства. На ZyXEL при переводе в режим репитера, в интерфейсе отключаются все настройки, которые не нужны в данном режиме. На SNR, только появился дополнительно пункт "Клиент/Репитер" в настройках WiFi.

Что именно-то не получается?

Методом научного тыка вроде настроил, телевизоры подключаются через второй роутер к IPTV, мобильники переподключаются при перемещении по квартире. Но вот внятной доки по настройке конкретно этого роутера в режиме репитера, я не нашел. Так же как и в режиме AP, при подключении к основному роутеру по кабелю.

Однако опорная сеть по воздуху это беда даже если прямо сейчас проблем не видно. Мой вам совет. Тяните кабель.

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

Цитата: HyperMode от 15/10/2019, 13:40

На ZyXEL при переводе в режим репитера, в интерфейсе отключаются все настройки, которые не нужны в данном режиме. На SNR, только появился дополнительно пункт "Клиент/Репитер" в настройках WiFi.

  1. это какие не нужны? =) На самом деле всё убирается что реально не может быть использовано.
  2. правильно появился

Что именно-то не получается?

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

Там вроде ошибиться не где. Ок. Запланируем статью. Написали бы сразу по человечески, что не получается, сразу бы подсказали. Из вашего поста следует что у вас уже настроен репитр. А вижу, наоборот, зарапартовался.

Так же как и в режиме AP, при подключении к основному роутеру по кабелю.

А тут то какие вопросы? Перевели в режим AP, настроили радио аналогично основной железке и ткнули провод в любой порт - настройка завершена.

Однако опорная сеть по воздуху это беда даже если прямо сейчас проблем не видно. Мой вам совет. Тяните кабель.

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

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

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

В остальном схема с репиттером имеет те же проблемы что и если бы клиенты бы коннектились напрямую + ещё и эфир утилизируется дважды. Т.е. это мягко сказать костыль, особенно учитывая что APCLI вообще не репиттер.  А именно что клиент и AP реализуемые на одном модуле. По другому оное нынче не реализуется обычно. И тут свои тараканы могут быть запросто.

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

Т.е. если хочется seamless roaming со всеми атрибутами типа правильно работающего FT и прочего, то ради должно быть как минимум моновендорным. И крайне желательно что бы все узлы вообще одинаковое радио имели. Часть клиентов, например, при миграции с 1T1R радио на 2T2R (и наоборот) запросто превращается в тыкву до ребута (пример Yotaphone 2), при этом между одинаковыми по числу стримов устройствами мигрирует без проблем.

Т.е. хотим сеть с роумингом - забываем о зоопарке.

Цитата: sfstudio от 15/10/2019, 14:58
  1. это какие не нужны? =) На самом деле всё убирается что реально не может быть использовано.
  2. правильно появился

Там вроде ошибиться не где. Ок. Запланируем статью. Написали бы сразу по человечески, что не получается, сразу бы подсказали. Из вашего поста следует что у ва

Например настройки LAN WAN и DHCP. Если оно репитер, то ему эти настройки ни к чему. Здесь же не понятно,и DHCP остаётся включеным и настройки сетей активные, хотя нам вроде нужны настройки нашей основной сети. DHCP я выключил (хотя не понятно зачем он вообще активен в режиме AP), WAN выставил всё в автомат, LAN прописал IP из локальной сети чтобы подключаться ко второму роутеру (хотя логичнее было бы WAN интерфейс перевести в режим LAN и не занимать еще один адрес, т.к. это AP), галки в настройках AP вообще не информативны и не понятно какая зачем. Поэтому и написал, что не понятно что и где настраивать, особенно имея IPTV в сети.

Так же как и в режиме AP, при подключении к основному роутеру по кабелю.

А тут то какие вопросы? Перевели в режим AP, настроили радио аналогично основной железке и ткнули провод в любой порт - настройка завершена.

В любой порт LAN? Они у меня все заняты на втором роутере. А остальные настройки?

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

Какой смысл городить плинтуса, если в квартире запланирован ремонт с укладкой электрики и ЛВС в штробу?

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

Прекрасно понимаю, что это временное решение.

Т.е. если хочется seamless roaming со всеми атрибутами типа правильно работающего FT и прочего, то ради должно быть как минимум моновендорным. И крайне желательно что бы все узлы вообще одинаковое радио имели. Часть клиентов, например, при миграции с 1T1R радио на 2T2R (и наоборот) запросто превращается в тыкву до ребута (пример Yotaphone 2), при этом между одинаковыми по числу стримов устройствами мигрирует без проблем.

Т.е. хотим сеть с роумингом - забываем о зоопарке.

Именно поэтому в сеть вкручен второй роутер SNR, аналогичный основному.

Цитата: HyperMode от 15/10/2019, 15:31
Цитата: sfstudio от 15/10/2019, 14:58
  1. это какие не нужны? =) На самом деле всё убирается что реально не может быть использовано.
  2. правильно появился

Там вроде ошибиться не где. Ок. Запланируем статью. Написали бы сразу по человечески, что не получается, сразу бы подсказали. Из вашего поста следует что у ва

Например настройки LAN WAN и DHCP. Если оно репитер, то ему эти настройки ни к чему. Здесь же не понятно,и DHCP остаётся включеным и настройки сетей активные, хотя нам вроде нужны настройки нашей основной сети. DHCP я выключил (хотя не понятно зачем он вообще активен в режиме AP), WAN выставил всё в автомат, LAN прописал IP из локальной сети чтобы подключаться ко второму роутеру (хотя логичнее было бы WAN интерфейс перевести в режим LAN и не занимать еще один адрес, т.к. это AP), галки в настройках AP вообще не информативны и не понятно какая зачем. Поэтому и написал, что не понятно что и где настраивать, особенно имея IPTV в сети.

APCLI это тот же роутер а не АП, пока не стоит галка bridge only и все абсолютно настройки для WAN актуальны и в aplci если не включен бридж режим для него. Просто WAN в данном конфиге это клиентский интерфейс. О чём написано при выборе режиме.

То что вы называете репитером оным не является. Это режим моста между AP интерфейсом и Cli интерфейсом.

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

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

Так же как и в режиме AP, при подключении к основному роутеру по кабелю.

А тут то какие вопросы? Перевели в режим AP, настроили радио аналогично основной железке и ткнули провод в любой порт - настройка завершена.

В любой порт LAN? Они у меня все заняты на втором роутере. А остальные настройки?

Я вас не понимаю от слова совсем. Чего настраиваем? Точку доступа? Всё переключили в режим AP все порты стали равноценны, нет в режиме AP WAN. Тыкаем в любой порт кабель и тащим до LAN порта вышестоящего роутера.

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

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

Какой смысл городить плинтуса, если в квартире запланирован ремонт с укладкой электрики и ЛВС в штробу?

Какой смысл городить репитеры если надо начинать ремонт? =)) Я откуда знаю планируете вы или нет ремонт.

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

Прекрасно понимаю, что это временное решение.

Нет ничего более постоянного чем временное.

Т.е. если хочется seamless roaming со всеми атрибутами типа правильно работающего FT и прочего, то ради должно быть как минимум моновендорным. И крайне желательно что бы все узлы вообще одинаковое радио имели. Часть клиентов, например, при миграции с 1T1R радио на 2T2R (и наоборот) запросто превращается в тыкву до ребута (пример Yotaphone 2), при этом между одинаковыми по числу стримов устройствами мигрирует без проблем.

Т.е. хотим сеть с роумингом - забываем о зоопарке.

Именно поэтому в сеть вкручен второй роутер SNR, аналогичный основному.

В сегодняшних реалиях странное решение, особенно ME1. Но вам как бы виднее. Сейчас рассматривать ME1 к покупке я бы уже не стал, особенно для multiAP конфигурации. Причём даже если закрыть глаза на то, что мы свернули работу по SNR-CPE кроме как багофиксов.

2 года или даже год назад был смысл брать эту конфигурацию. Сейчас однозначно брать гигабитный дуалбэнд с 7610 в 5ГГц крайне странно.

 

В сегодняшних реалиях странное решение, особенно ME1. Но вам как бы виднее. Сейчас рассматривать ME1 к покупке я бы уже не стал, особенно для multiAP конфигурации. Причём даже если закрыть глаза на то, что мы свернули работу по SNR-CPE кроме как багофиксов.

а что с ним не так? я вот покрутил немного дома - вроде бы хорошая точка.

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

Чип по сегодняшним меркам сверхкуций. Устраивает - ок. Но я бы уже не рассматривал.

Ну и банально в схеме выше с apcli на 1T1R AP благодаря двойной утилизации эфира получаем чуть за сотню полезных мегабит на клиентах второй АП, где можно было бы получить 400+ на 2T2R не  в самых лучших условиях.

И т.д. и т.п.

где можно было бы получить 400+ на 2T2R не  в самых лучших условиях.

да мне нужно-то чтобы на телефоне ssh не отваливался, странички открывались, ну и у жены в условном вк картинки/видео без задержек крутились.

даже 20-30 стабильных мегабит нам хватит за глаза (и большинству домашних пользователей тоже).

Моё дело предупредить, что бы потом не рассказывали что и как сказывается на репутации. =)

На самом деле вопрос не в 20-30 хватит всем (вы тут ооочень сильно заблуждаетесь), а  в том может ли единичный клиент выбрать всё эфирное время (на низких рэйтах с репитерами это раз плюнуть и при 20-30 мегабитах) при простых операциях аля обновление приложений ведроида. В случае схемы без airtime ещё и с apcli совсем не исключён вариант что работать по ssh в это время вы не сможете. А видео 20-30Мбит битрэйтом онлайн эт тоже нынче совсем не редкость.

Так что моя рекомендация тут простая, при выборе гигабитника выбирать железку без airtime с 1T1R в 5ГГц сейчас смысла как такового нет. Для сотки пофигу ибо нужно сильно постараться что бы узким местом стало AC радио,а не порты.

Если предполагается использовать схемы APCLI/WDS то чем больше будет этих самых T/R тем лучше, тем меньше будет затрат эфирного времени на передачу того же объёма данных между узлами и тем больше достанется клиентам.

 

Цитата: sfstudio от 09/04/2019, 15:52

А что там дописывать про настройку? Включаем 802.11k/r 2 галки, выставляем одинаковые SSID. Первый роутер в режиме роутера второй в режиме AP. Больше ничего не трогаем. Соединяем кабелем - профит.

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

Но вот только для этого желательно юзать не роутеры с OMNI антеннами, а потолочные или секторные AP. Иначе зона где  у клиента сработает триггер handover`а к переключению может оказаться очень далеко от желаемой зоны и придётся ронять мощность почти в 0 или отказываться от бесшовности призывая на помощь handoff.

Всё остальное в виде размещения и выбора оборудования под конкретные условия и задачи (что крайне важно при организации нормального покрытия) это ещё статей 5ть. Увы нет пока возможности заниматься писательством.

Цикл статей время от времени дополняется. Будет время - будет продолжение.

Чуть не забыл.  В настройках DHCP сервера на роутере выставляем Address conflict check timeout в 0 иначе в некоторых случаях будет задержка при миграции на клиентах которые перед исполнением handover зачем-то "прощаются" с DHCP и отпускают адрес.

 

Добрейшего дня, не очень понял, что значит первый в режим роутера, а второй в режим AP.

Есть три режима: AP-bridge, AP-Gateway, Client-AP-Gateway(WISP)/Client-AP-Bridge(Repeater))    Какой из них куда (прошу взять в пример две точки ME1 соедененные проводом)

По возможности, прошу порекомендовать новые железки на замену ME1 =)

Добрый.

Тот который на входе с провайдера должен работать как роутер (AP-Gateway). Дополнительный AP-bridge (это чистая точка доступа AP).  LAN IP на АП должен  отличаться от LAN IP роутера но входить в диапазон IP на нём. Всё остальное идентично.

Это если соединяете проводом.

Если по воздуху, то вторая железка будет не AP-Bridge, а Clieant-AP-Bridge  (после переключения настраивается в соответсвующем разделе появившемся не забывая в нём же поставить галку на тему режима бриджа).

Больше отличий нет. От того на каком устройстве стоитWive это так же не зависит. Хоть SNR хоть Acorp ещё под RTNL, хоть новые девайсы которые медленно но верно пытаются ехать в РФ.

P.S. Заранее о когда будут.  О их приезде вы узнаете по закрытию всех тем на форуме касаемых MT ветки кроме раздела багрепортов и появления раздела по HQ. А так же по публикации на сайте. С этого момента все вопросы по SNR-CPE кроме багрепортов будут игнорироваться и/или удаляться как оффтоп.  Т.е. за консультациями только к продавцу и вендору.

PP.S. Использовать DS по воздуху, не важно в каком режиме AP-Cli или WDS крайне не рекомендую даже в ауле где wifi у вас один на 1000км. Всё стационарное включая АП между собой должно по определению быть соединено проводом. Следуя этому правилу заведомо избежите большинство подземных стуков и потенциальных проблем.

Цитата: randwo от 26/10/2019, 17:57

По возможности, прошу порекомендовать новые железки на замену ME1 =)

Как приедут - так сразу рассекретим и названия с характеристиками, поставщиков и обзоры постараемся родить оперативно. Оптимистично оптовым покупателям первые (младшие модели) будут доступны до конца следующего месяца, старшие должны пойти с интервалом в неделю-две. По рознице пока информации сколько-то достоверной нет, врятли раньше НГ ИМХО.

Оценка очень оптимистичная, при условии, что не вылезет ещё чего-нить весёлого на что мы повлиять не можем (влиять можем увы только на техническую часть).

вот у нас стоит несколько десятков snr, если мы захотим расширить сеть парой новых устройств - вы предлагаете всё старое выкинуть и купить новое?

а через два года ещё раз всё менять?

 

ИМХО проще раз уж всё выкидывать - то на условный микротик переехать и забыть все эти пляски с поддерживаем/не поддерживаем.

 

  1. кто мешает докупить ещё пару старых устройств если вопрос исключительно в расширении? А вот если захочется планомерно апгрейить сеть то так и сяк не выйдет этого сделать прозрачно и безболезненно при смене поколений радио (даже AC wave1/2) и начнутся подземные стуки. Т.е. независимо от вендора менять придётся сразу сегментами в которых критична бесшовность (например).
  2. менять по мере необходимости, для вас это новость? Чаще всего в wifi увеличение ёмкости сети напрямую связано с перездом на железо нового поколения умеющего новые "стандарты", и докупанием старого не решается.
  3. с условным микротиком будут те же яйца только в профиль, плюс к этому получите ещё и стопку специфичных для него прелестей условного отсутсвия базовых вещей для корпоративных сетей начиная с отсутсвия WPA Enterprise заканчивая K/R. Ну так, как условный пример.

Так что проблемы с апгрейдом и расширением сети они слабо зависят от вендора. Разве что в части доступности железа снятого с производства на случай необходимости ремонта или "расширения".

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

Вам не кажется, что вы не по адресу вопрос задаёте? У вас на коробке с устройством есть e-mail, и телефон даже. Вот всё туда.

Нам вы можете задать только один вопрос. Аля почему мы не хотим поработать бесплатно во благо вендора SNR-CPE. Ответ на него думаю вам очевиден.

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

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

P.S. Вы бы ещё бы потребовали поддержки ME2 нами.  =)

Вам не кажется, что вы не по адресу вопрос задаёте? У вас на коробке с устройством есть e-mail, и телефон даже. Вот всё туда.

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

Не улавливаю связи от слова совсем. Статьи неправильные? Реализация какая-то не такая? Вроде нет.

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

Как моё авторство делает меня обязанным заниматься саппортом железа 3ей стороны на халяву? И уж тем более разбирать кейзы выходящие далеко за грань типового конфига на уровне дебага? Вроде никак.

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

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

Именно поэтому схема взаимодействия с "вендорами" по HQ изменена на такую которая снимает вопросы сопровождения. Теперь просто не появятся устройства за сопровождение которых нам не оплачено заранее. И выпуск новых без предоплаты за них будет невозможен.

И вот тут уже как поставщики решения мы сможем спокойно сопровождать юзверей не оглядываясь на детей африки.

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

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

Фору по времени в пол года им дали продолжая оказывать саппорт от и до и оперативно чинить даже не критичные баги даже в UI. Терь уровень саппорта будет неизбежно падать сократившись в итоге до только правок проблем безопасности и только если таковые будут выявлены (с примерно марта). В таком виде он просуществует ещё несколько лет, как и было в случае с RTNL для Acorp (за той лишь разницей что в готовом виде обновления будут доступны только тем кто успел зарегаться в системе обновления перейдя сейчас на нашу официальную сборку с sf.net и использующие именно её постоянно, остальным только ручная сборка из сырцов без ессно хоть каких-то гарантий), после чего git вообще будет переведён в RO.

Т.е. выводим из работы MT ветку в максимально безболезненном для end юзера режиме. Хотя по хорошему должны были бы сразу воткнуть EOL и забить, т.к. с окончанием контракта обязательства наши так же закончились.

О чём сразу были уведомлены в т.ч. будущие покупатели, что бы именно, что если берут то делают это на свой страх и риск.

А уж зачем было брать зная, что точка не возврата пройдена я ХЗ

железки были куплены до известий о вашем разводе.

 

Это его зона ответственности. Он взял на себя эти обязательства, вот туда и обращайтесь.

это всё хорошо. но покупались они не как "железки SNR", а как "железки с прошивкой wive-что-то-там".

свои проблемы мы решим, конечно, но вот энтузиазм в использовании того самого wive-что-то-там угас.

Я не знаю что там у вас покупалось, но продавались они как "железки SNR".

И тем более мне не ясно почему если оно покупалось уже скоро как год назад вы пришли только сейчас. За это время можно было 500 раз уже решить все проблемы. В т.ч. "до развода". По новью SNR сразу сказано никакого саппорта вообще ибо объявлено о "разводе".

Более того, я вроде не обещал вообще все возможные конфиги дебажить. Есть вот то что из UI настраивается - welcome. Крутите что-то своё в обход штатной логики - ну могу только направление указать, сидеть разбираться почему не работает никто не будет ессно.

Информация для начала дебага вам дана избыточная.

Угас так угас. Не вижу проблемы.

Цитата: edo1 от 28/10/2019, 17:26

свои проблемы мы решим

Кстати, для юриков бесплатный саппорт вне контрактов на поставку вообще для MT не предусматривался. От слова никогда, и всегда было окно по юрикам одно - через поставщика в закрытом режиме. Так что как появляется "мы" то тут можно было даже и не начинать. Те кто "мы" всегда идут через окно поставщика если не имеют с нами прямых контрактов, где условия в т.ч. по сопровождению могут быть совсем иные. И даже по обновлению до специфичных веток вопрос решается совсем не как "для остальных". Тут кто хотел озаботились заранее. Сейчас смысла уже нет.

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

Цитата: edo1 от 21/10/2019, 11:46

а что с ним не так?

Вот вам и ответ что не так. И советчики которые продолжают рекомендовать к покупке (из коробки же всё ок) делают медвежью услугу. Ибо железо живо пока в т.ч. ПО по нему в работе. MT ветка давно выведена из рабочего процесса, а изменений относительно HQ столько что что бы что-то проверить нужно вывалиться из основного процесса и сидеть расколупывать что же там было.

В т.ч. поэтому и не может быть никаких рекомндаций к покупке. В т.ч. поэтому саппорт сведён до минимума и только по критичным и штатным вещам.

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

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

Обязанность предоставить саппорт АПК так и сяк ложиться на поставщика/производителя. Чьими руками, нашими или своими это уже их выбор.  У вас есть полное право истребовать с них обеспечение сопровождения и устранение недостатков в товаре если вы такие выявили.

Ибо после этих опусов у меня желание вообще в хоть каком-то виде сопровождать MT уже почти отсохло.

просто, чтобы не было непонимания.

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

 

Крутите что-то своё в обход штатной логики - ну могу только направление указать, сидеть разбираться почему не работает никто не будет ессно.

 

Кстати, для юриков бесплатный саппорт вне контрактов на поставку вообще для MT не предусматривался

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

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

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

Я не знаю какое у кого непонимание возникло.

Но вот тут уже у меня диссонас полный:
1) на кой фиг в 2019г брать соточные девайсы для офисной сети, их место на складах и только. Гигабитных АП у SNR нет. Если имеется в виду коробка ME1 то тем более не понимаю кто надоумил строить офисную сеть на коробке омников, оно вообще близко для этого не подходит.
2) даже пол года назад было уже понятно, что новые офисные сети не имеет смысла строить на железе с одним стримом в 5ГГц ещё и без AirTime и Mu-Mimo т.е. Wave-1. Ибо ровно тот кейз где MU-MIMO имеет шанс заметно увеличить ёмкость эфира, и уже сейчас почти все новые сматры идут с поддержкой MU-MIMO.
3) на кой фиг их брать что бы мариновать пол года, особенно на фоне смены поколений  радио, когда цену на предыдущее активно скидывают. Т.е. либо берётся сразу и под задачу, либо берётся когда надо ставить. Маринование на пол года не делает девайсы лучше, это не вино. За пол года может произойти всё что угодно, перехать трамваем кого-то, конторы могут закрыться и т.д. и т.п. В итоге ровно то место где нужен саппорт для устройств используемых в режиме АП (нужен он при развёртывании ибо потом оно просто работает и не трогается обычно) велик шанс его не получить.
4) зачем тащить домой на какой-то стэнд чего-то там крутить если там нельзя повторить ровно тот конфиг который будет использован в месте установки и эксплуатации. Причём если речь и роуминге повторять придётся всё включая помещение и тонну разношёрствных  клиентов и состояние эфира, ибо на 99% миграция зависит не от софта на АП, а от софта на клиентах и правильно организованного покрытия физически. Поддержка хоть самая золотая в криво построенной с точки зрения покрытия сети вам ничем не поможет.
5) зачем мне рассказывать выше про телефон, ssh и хватит всем в контексте развёртывания дома если речь идёт вообще не о том?
6) почему до сих пор не обратились туда где взяли это железо, они бы вам радостно заявили что будет вам и саппорт ещё чего-нить. Уж на уровне подсказать как разместить и что крутить, что нет поди за 4ре года запомнили мои многоразовые пояснения на пальцах. Надеюсь по крайней мере на это. Иначе не ясно на что они вообще рассчитывают в перспективе.

И т.д. и т.п.

Ставить или не ставить дело ваше. Я бы не стал бы строить офисную сеть на железе доступном у SNR даже если опустить софт. Аппаратно оно не отвечает требованиям минимальным для построения офисных сетей в 2019г. От слова совсем. Оно устарело. Объективно это железо можно легко ставить на какие-нить склады где надо кучу терминалов приземлить. Ставить подобное железо в реальный офис (если это не офис на 3,5 колеки не отшибе с чистым эфиром) уже нельзя. Поезд ушёл. А через 2 года таким минимумом станет поддержка AX ибо TDD. Тут ведь вопрос не  в скоростях, а в экономии эфирного времени расходуемого на одного клиента и контроль этого эфирного времени и доступа к среде передачи за счёт CSMA/Airtime/TDD/etc...

Так что подход с маринованием тут не подходит от слова совсем и не применим от слова никогда. Всё меняется в этой сфере достаточно шустро, ещё и ускоряется с годами.

Это так для понимания почему всё пошло не так.

Не знаю почему все так плохо.

Брал snr для работы в цехе где 10 клиентов по воздуху, для вайфая в офисе где 15 клиентов.

Доволен как слон, кто может тот мигрирует, сам на китайском honor теряю 2 пакета в локалке.

На ноутбуках с интелами древними как мамонт 1 пакет при смене точек.

100 % аптайм, включил настроил и забыл.

Моё мнение про наг и про по wi-cat - молодцы. Сработали, сделали норм железо норм софт. Цена 3 копейки, для своих задач одни плюсы.

Всей команде wi-cat большое спасибо!

Всё ещё надеюсь в тест свалится в hq, но по мне лучше стабильность чем пляски с бубном.

Цитата: Xelrons от 29/10/2019, 18:38

Не знаю почему все так плохо.

Не знаю у кого плохо.

Цитата: Xelrons от 29/10/2019, 18:38

Брал snr для работы в цехе где 10 клиентов по воздуху, для вайфая в офисе где 15 клиентов.

Это тот кейз который я называю 1,5 колеки. Вот когда у тебя опенспэйс или просто ряд кабинетов в каждом по минимум 20 клиентов, пи этом за стенкой ещё десяток офисов это вот тот кейз на который мы ориентируемся при отладке.

И если я говорю что нет смысла брать Wave-1 уровня девайсы, то наверное опираюсь на разницу работы и результаты полученные при сравнении именно  в этих кейзах. И если сегодня кейз с засранным эфиром в 5ке относительно редок где-то кроме БЦ (пол года назад он и там был ещё редок), то завтра оно будет везде. А при строительстве сети надо ориентироваться, не на вчера, а на завтра. Эфир он не резиновый. И только если вы и ваши соседи по офисному помещению осилят это осознать и использовать железо позволяющее экономить эфирное время например за счёт использования более высоких модуляций, или MU-MIMO, только тогда в будущем к вам внезапно не постучится карачун в виде сигнала валом и нифига не работает.

Всё ещё надеюсь в тест свалится в hq, но по мне лучше стабильность чем пляски с бубном.

Как буд-то в HQ со стабильностью как-то иначе. =) Надёжная работа это то, на что тратиться большая часть времени при отладке и разработке. Набор тестов такой уже нарисован, что проверяются даже кейзы крайне редкие или даже на грани возможности. Правда это тоже на 100% не закроет все потенциальные варианты (реальность она такая, не перестаёт удивлять), но как минимум выявит большинство проблем. Как недавняя трабла в 7615 приводящая регулярно к отрыву головы на уровне sanity checks.

P.S. Все причастные к разработке SNR-CPE на 7620-7621 до ME1 включительно работают в Wi-Cat. Ну за исключением по объективным причинам оставшегося в команде SNR вебера. Жаль не было возможности перехватить ещё одного толкового товарища (безотносительно участия в разработке) который нынче в яндексе трудиться.... А так команда в сборе и железки пекуться и готовятся в т.ч. на перспективу. Хотелось бы лишних часов 100 в сутках правда...

PP.S. В больших офисах где требуется бесперебойная работа, апгрейд радиосегмента закладывается заранее. Задолго до того как в дверь постучались проблемы. Я бы рекомендовал бы синхронизироваться по интервалам с выходом (не появлением а принятием финальной версии как недавно AX) новой версии стандарта 802.11 + 1 год. Т.к. год нужен что бы появились отлаженные решения и ценник устаканился, так же вымерли всякие совсем уж драфтовые реализации. Причина такой необходимости проста. Ёмкость сети в силу ограниченности частотного ресурса (большинство клиентов могут работать только в 36-64 диапазоне, а это макс 2АП по 80МГц полосе) наращивать установкой доп АП не выходит, ни по числу ни по скорости, а обстановка в эфире при этом деградирует, и это не говоря уже о постоянно объективно растущих объёмов данных и т.д. Нет можно попытаться нарезать узкими полосами. Да общая ёмкость если по числу клиентов смотреть будет выше. Но достижимые скорости на одного клиента упадут в разы, что зачастую критично. Т.е. единственный вариант это плановые апгрейды инфраструктуры, с перемещением старого железа куда-нить на склад где не критична скорость от слова совсем. А если речь идёт о БЦ то там соседние офисы ещё вносят свои коррективы. В общем для офиса нельзя подходить к выбору железка как к выбору для дома или склада, аля "мне хватает". Специфика офисных сетей совсем иная, и аспекты которые нужно учитывать не заканчиваются на "хватает".

Вот когда у тебя опенспэйс или просто ряд кабинетов в каждом по минимум 20 клиентов, пи этом за стенкой ещё десяток офисов это вот тот кейз на который мы ориентируемся при отладке.

У меня так только полторы колеки.

P. S. Народ любит таскать свои попы по кабинетам и просил что бы все работало. Оно работает благодаря Вам!

Как буд-то в HQ со стабильностью как-то иначе. =) Надёжная работа это то, на что тратиться большая часть времени при отладке и разработке.

Дак дайте уже прошивку на mt.

Ещё раз выражаю огромную благодарность за вашу работу!

Удачи!

На счёт времени, как говорит директор, у тебя же ещё ночь есть.

Цитата: Xelrons от 29/10/2019, 19:20

Дак дайте уже прошивку на mt.

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

В общем не получается никак 2+2=5. Так что SNR будет доживать у нас под MT свой век.

На счёт времени, как говорит директор, у тебя же ещё ночь есть.

Ночью пожертвовали ещё года 3 назад. Нынче доступно только спектральное уплотнение. =)

Приветствую. На днях купил ме1 роутером доволен, спасибо вам умельцы.  Но роутер расположен в плохом месте а именно а углу трёхкомнатной квартире в дальней комнате. Переместить его нет возможности т.к. по кабелю к нему подключены устройства. Появилась необходимость в точке доступа для увеличения покрытия. Вопрос вот в чем: есть возможность взять роутер W4n за недорого и настроить его как точку доступа по кабелю от ме1. Эта связка нормально будет работать? Есть еще возможность купить TP-link RE205.

Посоветуйте может ещё какие варианты с устройствами

Приветствую.

Первое чего всегда избегаем это зоопарка. Реализация FT в части обмена данными между АП не регламентирована требованиями 802.11, т.е. совместимости между вендорами и/или софтом в этой части обычно нет от слова совсем.

Ну и добавлять голый 2.4 к 5ке крайне странно. Особенно учитывая что обратная миграция с 2.4ГГц в 5Ггц почти на всех клиентах будет обламываться (ну вот такие реализации в клиентах в большинстве своём). Т.е. мигрировать оно будет, но бесшовно ли эт вопрос очень большой.

Т.е. по хорошему ставить стоит совсем одинаковое железо включая версии ПО.

Ну и поздновато вы на ME1 решились. Этого устройства даже аналога у нас не будет и поддержка, с нашей стороны, гарантированно будет прекращена уже достаточно скоро. Прям вот уже стучится в дверь этот момент.

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: