В честь наступающего 2025г мы решили сделать общедоступной редакцию Wive-NG-HQ для x86-64 систем.;)

Система базируется на 6.12 LTS ядре в его чуть ли не самой минимальной конфигурации. В качестве стандартной библиотеки, традиционно для Wive, задействован uclibc-ng.

Размер образа 8Гб, из которых сама система менее 100Мб. Остальной объём на разделах может быть свободно использован пользователями для собственных нужд (например установки пакетов из Entware, достаточно запустить entware_install.sh).

Система требует от процессора поддержки 64Bit и как минимум две гигабитные сетевые карты от Intel или Realtek. Может работать на устройствах с объёмом RAM от 128Мб.

Большинство микрокомпьютеров с Aliexpress на базе старых i3-7 и атомов должны подойти.

Для запуска достаточно записать на накопитель с помощью dd образ системы bootfs.img и загрузиться с накопителя.

Так же система может быть запущена в Virtualbox. Преднастроенная машина в архиве, нужно лишь добавить виртуальный интерфейс с адресом из подсети 192.168.1.0/24 т. к. LAN интерфейс в системе по умолчанию имеет адрес 192.168.1.1.

Для чего всё это?

Ну в первую очередь для отладки.

В текущее время мы совершаем глобальную переделку OS т. к. пришло время мигрировать на свежее ядро (6.12 LTS) и поддерживать больше архитектур (кроме mips и x86-64 в планах поддержать ряд SoC на ARM/RISC-V а возможно даже и E2K).

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

Т.к. система собирается из того же дерева исходников и кроме ядра на 99% использует одну и ту же кодовую базу, что и текущая Wive-NG-HQ для MIPS, то выявленные шероховатости не редко касаются сразу обеих архитектур, однако ранее они могли оставаться незамеченными годами.

В этом основной смысл существования Wive-NG-HQ x86-64 на текущий момент.

Для чего может пригодиться в хозяйстве остальным? Ну например для экспериментов для изучения Wive не боясь угробить устройство.

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

Или по-быстрому развернуть Radius сервер для организации централизованной аутентификации пользователей с индивидуальными парами логин/пароль в своей сети (WPA Enterprise).

Так же пригодиться нашим клиентам и операторам связи для локальных экспериментов.

Пробуйте, экспериментируйте, делитесь результатами.

!!!ВНИМАНИЕ!!!

Текущая сборка имеет статус прототипа и поставляется как есть, без сопровождения.

Вероятнее всего работает не весь представленный в UI функционал (если кто хочет заняться детальным тестированием и предоставить список недочётов — Welcome).

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

Система бесплатна для некоммерческого использования.

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

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

С наступающим всех новым годом. Ваши предложения ждём на com@wi-cat.ru

Для обсуждения x86 версии создан отдельный раздел на форуме.

Медиа: image / jpeg

Вдуть или не вдуть, вот в чём вопрос.

В последнее время просто откровенно завалили вопросами на тему максимальной выходной мощности устройств работающих под нашим ПО.

Казалось бы причём тут вообще ПО..?

Однако задав такой вопрос собеседнику получаем круглые глаза и фразу: «Ну вот же, заливаем ***WRT и вдуваем мощи на аж 29dBm».

На вопрос откуда такие сказочные данные ответ ещё круче. Оказывается из обзора iXBT.

Идём смотреть что там нынче (лет 5ть как не отслеживаем подобные ресурсы). И действительно находим подобный тихий ужас.

Ну ок. Давайте разбираться кто и где вас обманул…. Поехали.

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

И так, какие ограничения у нас накладываются на выходную мощность PA (Power Amplifire) который есть в любых радиопередающих устройствах?

Не важно, где находится этот усилитель.

Встроен в чип прямо с ЦПУ на одном кристалле, как например в MT7620. Или в радиочип устанавливаемый отдельно как в схемах с MT7615 и более ранними.

Или находиться в специализированном модуле сателлите относительно основного радиочипа (Front End Module – FEM) в котором кроме прочего обычно стоит ещё и TX/RX коммутатор (симплекс, внезапно).

Или же может стоять отдельно, да хоть собран на рассыпухе.

Но он всё равно в схеме есть ВСЕГДА!

Впрочем, то же самое касается и LNA (Low Noise Amplifire) устанавливаемый в схеме RX. Он так же есть всегда.

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

В современных решениях MTK сейчас применяется чуть более хитрый подход. Рассмотрим на примере MT7915+MT7975 (MT7981+MT7976 будет иметь в тех же диапазонах примерно те же характеристики).

Как видим, что в современных чипах – сателлитах у МТК кроме прочего вынесены так же по сути полностью и приёмник и передатчик, ЦАП/АЦП и т.д. и т.п.

Краткое описание от чипмэйкера:

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

В схеме, например MT7615 (и более ранних) + External FEM в этих FEM были только RX/TX Switch + PA + LNA. Теперь же всё иначе.

Важно, оговоримся, что внутри этого FEM так же есть термодатчик. Угадайте зачем?=)

Вот теперь мы знаем как устроен непосредственно кусочек тракта который отвечает за ту самую выходную мощность.
Но ведь нас интересует не она?

И тут подходим к такому страшному слову как EIRP.

Эквивалентная изотропно-излучаемая мощность (ЭИИМ, англ. EIRP — Equivalent Isotropically Radiated Power) — произведение мощности радиочастотного сигнала, подводимого к антенне, на абсолютный коэффициент усиления антенны [1] [2]. ЭИИМ может быть рассчитана по формуле: где EIRP и мощность P на выходе радиопередатчика выражаются в дБВт или дБм, потери L в фидере должны быть подставлены в дБ, коэффициент усиления антенны G — абсолютный, то есть в децибелах относительно изотропного излучателя ( дБи).

Вот именно на неё накладываются уже законодательные ограничения.

И так. Т.е. для расчёта нам нужно выходную мощность усилителя сложить с Ку антенны (потери в фидере будем считать 0) и вауля, будет EIRP.

Ок. Считаем что Ку антенн у нас 5dBi (как заявляет большинство вендоров для большинства коллинеаров устанавливаемых в бытовых маршрутизаторах).

Т.е. что бы получить искомые 29dBm EIRP – на выходе усилителя должно быть 24dBm.

Смотрим в RF_DVT_Report от МТК (распространяется под NDA потому только кусочки из таблицы) и пытаемся найти в каком же режиме такую мощность можно получить на выходе 7595 при приемлемом уровне искажений.

Оказывается что практически НИКОГДА и ни для каких режимов.

Ближайшее для 2.4ГГц:

А для 5ГГц:

Ну вот же вот!!! Воскликнет любитель дуть… Почти не соврали… Но расстрою.

Дело в том, что 1Мбит CCK это режим 802.11B который нынче даже для маяков не всегда используется. Эффективная (т.е. сколько данных фактически передаётся) передача на данных при такой модуляции возможна на уровне 256кБит/с… Как-то так себе в 2024м…

При этом вы займёте такой передачей всё эфирное время. И остальные устройства будут тупо ждать пока вы загрузите 4k видео на скорости в 256кБит и освободите эфир, что бы они могли начать передачу.

Аналогично и в 5ГГц, только там уже 6Мбит в голом OFDM. Мегабита на 3 можно рассчитывать с теми же последствиями.

Airtime Fairness в современных чипах не даст совсем уж всё эфирное время утилизировать, если есть другие активные клиенты. Но в любом случае передача в 3Мбит так себе достижение. Зато вдул=))

Я уже не говорю, что PA будет работать на пределе.

Ок. Спросите вы. Так какие же значения EIRP доступны на бытовых маршрутизаторах для современных модуляций и широких полосах? Ну что бы ВЖУХ и котики загрузились, а мы их смотрим и никому не мешаем?

Смотрим в таблицу:

Итого, видим что для рэйта 433Мбит (1S 80MHz AC) максимум будет 19дБм. Т.е. прибавив сюда почти всегда фантазийные 5дБи получим 24Дбм и это НА ПРЕДЕЛЕ.

Типовые, читай рекомендуемые значения, указаны в столбце Power Spec. Остальное это уже без гарантий повторяемости и того что чип вообще не прикажет долго жить.

И вот тут мы до кучи вспоминаем о термодатчике. Всё дело в том, что современные чипы, будут всеми силами сопротивляться, что бы их не спалили любители вдуть.

Для этого мало того что микрокод не даст поднять значения выше предельно допустимых для схемы с iPA/iLNA (а это именно она самая) так ещё и термодатчик сообщает микрокоду о нагреве не просто так. ;)

Зачем? Это вам в качестве домашней работы.

А что в реале?

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

Задача стояла получить максимум на тест стенде, что бы и откалибровалось без ошибок и с соблюдением огибающих мощности per rate, т.к. если просто орать на максимальной мощности для каждого отдельно взятого рэйта, то DRS(он же RATE ALG) будет работать некорректно.

Приведу для высших рэйтов ибо нижние так или иначе будут ограничиваться (см требование для работы DRS выше). Работа идёт в ATE режиме, региональные ограничения отсуствуют.

Вот собственно результаты для OFDM 54 (802.11G)/VHT MCS9 (802.11AC)/HE-80 MCS11 (802.11AX). Уровень дан без учёта Ку антенн.

Как высказался бы мой стародавний друг радиофизик – реальность тут дала вдудям по почкам, развернулась и добавила с ноги да в нос.=)

Т.е. даже с превышениями (с PA на пределе, но ещё до закипания, т.к. тесты идут быстро, в реальности термокомпенсация бы ограничила бы ещё дурь) EIRP получается:
54Мbit 20MHz BW OFDM== 24.7dBm
433Mbit 80MHz BW VHT== 22,5dBm
600Mbit 80MHz BW AX== 21.3dBm

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

Голый OFDM нынче рекомендуют отключать или хотя бы убрать всякие Legacy рэйты.

А так же в схеме с MultiAP может быть полезно ещё дурь и маякам придушить, благо 7915 и старше чипы это всё прекрасно умеют (в Wive под AX эти возможности есть все).

Цель – обеспечить более внятное переключение в Multi AP сети, т.к. клиент уровень сигнала всегда меряет исключительно по управляющим фрэймам летящим на самой низкой скорости дабы быть корректно декодированными даже в условиях существенного зашумления. Что приводит к залипанию клиентов на одной ТД, но это уже совсем другая история….

Как итог.

Типовые значения мощности для реально используемых режимов на которых «летят» дата фреймы для большинства домашних маршрутизаторов не будут превышать 17-18dBm. Т.е. 22-23dBm EIRP, и то с оговорками. ;)

Ни о каких сказочных 29dBm на решениях с iPA/iLNA в сколько-то приемлемых для современных модуляций режимах речи и близко не идёт.

И никакие смены региона не позволят это обойти если установленные PA упираются в максимум своих возможностей.

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

Подведём итог. Что же это такое чаще всего за циферки меняющееся в UI при смене региона?

Да всё банально. Это MAX power который законодательно разрешён в этом регионе и вещаемый в IECAP. И эта цифра абсолютно никак не говорит о том, что само устройство может выдать такую мощность.

А вот реальная используемая мощность будет ограничена как минимум:
1) возможностями конкретного установленного PA (пример выше)
2) заданными ограничениями в калибровках выполняемых на заводе, они легко могут никак не зависеть от всего остального софта
3) ограничения накладываемые на диапазон значений микрокодом MCU/BBP конкретного чипа (в iPA/iLNA режимах проверка разумности значений вполне себе существует, хотя и несколько выше номинального и корректируется калибровками per rate/bw/ss)
4) системой термо компенсации и защиты от перегрева

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

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

Выводы:

Типовые схемотехнические решения применяемые в 99% типовых домашних маршрутизаторов, даже если их перевести в тестовый режим, отключить термокомпенсацию и т.д. на сколько-то приемлемых для передачи данных в современном мире модуляциях и тем более в широких полосах врятли смогут превысить законодательные ограничения EIRP просто потому что упруться в возможности применяемых FEM и качество реализации тракта включая пигтейлы и антенны.

В бюджетных маршрутизаторах (как и в wifi картах для ноутбуков), практически во всех, всегда будут использованы встроенные в радиомодуль FEM или штатные саттелиты от производителя основного WiFi чипа (как в случае разобранном выше).

!!!В ряде случаев, попытки вывернуть мощность сверх лимита может закончится и вовсе плачевно. Особенно в схемах с внешними FEM.!!!

Если у вас хромает покрытые, следует не пытаться надуть больше дури из одной точки в эфир, а перейти на схему с многоточкой, где точки доступа объеденены кабелем + настроен бесшовный роуминг.

Это позволит иметь максимальную скорость в любом месте помещения, а значит минимальное время занимать в эфире для передачи данных к одному из клиентов. Так же позволит использовать (для РФ) аж 3 поддиапазона по 80МГц полосой в каждом.

Т.е. устройства работающие на разных ТД не будут никак мешать друг другу и скорость будет максимальной.

При этом мощность, скорее всего, можно будет безболезненно и существенно снизить.

Медиа: image / jpeg

Пришло время сказать Welcome абсолютно любым производителям оборудования на популярной платформе MT7621 с радио интерфейсами на базе MT7610/MT7603/MT7613/MT7615/MT7915.

OS Wive-NG-HQ доросла до уровня когда мы можем смело масштабировать продажи теперь не ограничиваясь одним производителем.

При разработке ПО мы всегда опираемся на посыл: «включенное однажды должно работать не напоминая о себе вплоть до аппаратной смерти, в т.ч. от старости».

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

OS хорошо известна провайдерам в РФ, её ценят за надёжность, предсказуемость, а так же расширенные возможности (например за средства диагностики, в т.ч. радио сегмента, или функционал необходимый для организации бесшовного сегмента в корп сетях).

У многих операторов уже развёрнуты ACS полностью готовые к работе с решениями на базе OS Wive-NG.

И интерес к продукту продолжает расти.

Производство оборудование с предустановленной OS Wive-NG по сути мало чем отличается от штатных механизмов заложенных чипмэйкером.

Т.е. перевод производства не займёт много времени.

Все расчёты осуществляются по числу закупленных лицензий. Минимальная партия 1000 устройств. Максимальная неограниченна.

Цена зависит от количества устройств и необходимых изменений.

Заинтересовало? Тогда напишите нам: com@wi-cat.ru

Медиа: image / jpeg

Внимание!!!

На фоне происходящего в ИНФ поле и роста доли мошеннических операций в РФ хочется ещё раз акцентировать внимание на следующих моментах:

1. Разработкой и поставками ПО Wive-NG является «ООО Вайрлесс КЭТ» (сокращение Wi-Cat — читается как Вай Кэт)

2. Вайрлесс КЭТ не входит ни в какие объединения и/или группы компаний, а так же не имеет дочерних предприятий

3. Все ресурсы компании размещены исключительно в доменной зоне wi-cat.ru.

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

5. Единственным поставщиком (на текущий момент) готовых АПК (2 модели Wi-Cat-AX и Wi-Cat-GL) решений с OS Wive-NG является компания Синертау ( https://synertau.ru)

6. Никакие права, кроме необходимых для производства оборудования с предустановленной OS WIve-NG в рамках договоров и по числу устройств, так же никаким компаниям не передаются.

Если вам предлагают приобрести лицензии Wive-NG для пред установки, или разработать что-либо в ключе Wive-NG, или выпустить новую модель устройств заявляя при этом Wive-NG как часть АПК (возможны и иные варианты) — следует написать нам на info@wi-cat.ru

Такого рода услуги может представлять только компания «ООО Вайрлесс КЭТ». А решения принимаются генеральным директором компании в лице Маначкина Евгения Романовича.

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

Тоже касается иных документов (включая сертификаты) использующие фирменные изображения и иную атрибутику нашей компании без нашей печати и/или за подписью 3их лиц.

Всю необходимую информацию, включая список партнёров и поставщиков того или иного решения под или для Wive-NG, а так же возможные варианты сотрудничества можно запросить написав на info@wi-cat.ru. Или даже лично встретиться, но предварительно встречи и звонки всегда согласуются по e-mail (иначе голосовой спам увы не даёт сосредоточиться на работе).

Полные данные о нашей компании можно получить бесплатно онлайн из ЕГРЮЛ
Информацию о Wive-NG доступна в реестре российского ПО.

Будьте осторожны. Паразитов больше чем кажется… (с)

Медиа: image / jpeg

Перед Новым Годом принято подводить итоги и принимать решения которые зададут вектор развития на год грядущий.

Компания Wireless-CAT в преддверии нового, 2024г. Рада сообщить о доступности OS Wive-NG для Cost Effective наборов логики от MTK для построения SMB точек доступа и маршрутизаторов ориентированных на предустановку операторами связи конечным пользователям.
Возможно как производство нового оборудования с предустановленной OS Wive-NG-HQ, так и адаптация под уже существующие решения заказчика (при условии совместимости наборов логики).

OS хорошо известна на операторском рынке России и даже немного за её пределами. Ставка, как и прежде сделана на надёжность и раннее выявление проблем (не дожидаясь репортов от пользователей).

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

Полноценная поддержка SNMP/Zabbix/CWMP/etc позволяет вписать оборудование работающее на Wive-NG-HQ в существующую инфраструктуру вместо того, что бы плодить дополнительные сущности и точки отказа.

Точки доступа работающие на Wive-NG-HQ не требуют контроллера для организации бесшовных сетей с множеством точек доступа.

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

Стоимость лицензий обсуждается индивидуально, зависит от объёмов, необходимого функционала, уровня поддержки и т. д.

Ваши вопросы и предложения мы ждём на com@wi-cat.ru С функционалом обзорно можно ознакомиться в демо интерфейсе http://demo.wi-cat.ru

Пусть новый год решит существующие проблемы не добавляя новых!

Ваши мохнатые разработчики.

Медиа: image / jpeg

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

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

И так. Представляем вам первого из линейки оборудования под общим названием Wireless-Cat — Wi-Cat-AX.

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

В качестве ОС используется последнее, на момент написания, поколение OS Wive-NG (ветка HQ).

Как и более ранние это устройство ориентировано на работу в не обслуживаемом режиме, т. е. не требует к себе внимания с момента включения и первичной настройки до выхода из строя аппаратной части в связи с внешними факторами либо объективным «старением».

Устройство готово к использованию в качестве основы для SOHO/SMB сетей, в т.ч. сетей с множеством узлов в режиме бесшовного роуминга (поддержка 802.11k/r/v, средств балансировки между AP и принуждением к выбору диапазона) как в качестве маршрутизатора, так и в качестве точки доступа.

Имеет аутентичный, хорошо структурированный интерфейс с широким набором средств диагностики покрывающий нужды как новичка (easy config), так и проф инженеров.

Совместим с любыми вариантами используемыми ISP РФ на доступе (IPOE/PPTP/L2TP). Имеет средства для организации VPN канала для удалённого доступа в локальную сеть (серверная часть L2TPv2,3/PPTP/EOIP/Wireguard).

Поддержка современных средств шифрования и аутентификации для радиосегмента (в т.ч. WPA Enterprise режимы).

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

Так что же изменилось?

Во-первых. Изменился набор логики WiFi. В Wi-Cat-AX используется современный WiFi6 Wave-1 (802.11ax) чип от Mediatek, точнее пара чипов MT7905+MT7975.

Данная связка поддерживает 2 пространственных потока в каждом из диапазонов. Максимальная ширина полосы 80МГц. Максимальные канальные скорости 1201Мбит/с и 574Мбит/c в 5ГГц и в 2.4ГГц соответственно.

MT7905 является полноценным FullMac Offload чипом, построенным на ARM Cortex R4 ядре. Это позволяет существенную долю операций связанных с обслуживанием беспроводного сегмента выполнять средствами MCU не нагружая CPU.

А что даёт AX???

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

Большинство изменений в wifi6 направлены не столько на увеличение производительности на одном клиенте (хотя и тут была добав лена QAM1024 модуляция), сколько на увеличение числа обслуживаемых абонентов при приемлемом качестве сервиса (MU-MIMO/OFDMA/SR).

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

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

Так же серьёзные изменения претерпели и механизмы энергосбережения. TWT это безусловно значительный шаг в сторону экономии батареи носимых и иных устройств с автономным источником энергии.

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

К сожалению пришлось пожертвовать одним LAN портом и USB ради того что бы не сломать баланс между надёжностью и ценой (кризис всё ещё с нами).

А вот с программной точки зрения все AX устройства линейки Wi-Cat получат расширенное ПО включающая в себя SMB/Enterprise функционал.

В т.ч. расширенные средства диагностики беспроводного сегмента, дополнительные настройки радиомодуля (необходимые, например при построении HD wifi сетей с большим числом ТД и клиентов) как в режиме точки доступа, так и в режиме клиента.

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

Поддержку ещё одного варианта балансировки устаревших устройств между точками доступа внутри сети (Low Rate Balancing), необходим для оптимизации использования эфирного времени при наличии клиентов не умеющих handover.

Интегрированные Zabbix и SNMP агенты для осуществления удалённого мониторинга.

Реализация протоколов обнаружения топологии (LLDP/LLTD/CDP/EDP/FDP/SONMP) заметно упрощает диагностику опорной сети. А так же позволяет автоматически визуализировать топологию.

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

Так же в наличии OSFP/RIP/BGP ( Bird), и многое многое другое, что-либо уже реализовано, либо планируется к реализации в проекте Wive-NG for Enterprise (читайте на нашем телеграмм канале).

Производителем оборудования является наш партнёр, компания Synertau.
Она же осуществляет и гарантийное и пост гарантийное обслуживание и первую линию технической поддержки.

А эксклюзивным дистрибьютором оборудования Synertau линейки Wi-Cat – компания Wireless Mobile Devices ( страница продуктов wi-cat).

Обзор устройства от производителя: https://www.synertau.ru/post/wi-cat-ax

Краткое руководство пользователя маршрутизатора Wi-CAT-AX:

Загрузка...

Слишком долго?

Перезагрузить документ

| Открыть в новой вкладке

Краткое руководство пользователя операционной системы Wive-NG-HQ:

Загрузка...

Слишком долго?

Перезагрузить документ

| Открыть в новой вкладке

Сохранить [879.58 KB]

Медиа: image / jpeg

Затишье? А вот и нет…

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

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

И пару фото прототипов напоследок. ;)

Медиа: image / jpeg

Медиа: image / jpeg

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

В 3.9.16 произведено слияние всех внутренних веток в которых тестировались те или иные изменения по драйверам (99% багфиксы после fuzz тестирования). Версия 3.9.16 является полностью стабильной. И именно версии из 3.х.х ветки будут поставляться как минимум до НГ для оборудования Fibertool. Все изменения в 3.х.х ветках будут связаны исключительно с фиксом уязвимостей и критичных ошибок в компонентах системы, если таковые будут выявлены.

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

Основные работы по ним:
1) расширение набора средств мониторинга
2) доработка автосборки сети и массовой конфигурации
3) расширение поддержки CWMP (TR-*)
4) реализация нового функционала предоставляемого AX (Wi-Fi 6) чипами
5) лабораторные пред серийные испытания
6) перевод реальных сетей коллег и партнёров на тестовые образцы для испытаний в реальных условиях (сейчас только моя сеть построена целиком на наших AX решениях)
7) множество более мелких изменений, а так же добавление функционала под заказ партнёров

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

PP.S. Заморозка кода не означает окончание разработки. Даже наоборот. Замораживается публичная ветка, чтобы отловить все потенциально возможные регрессии при слиянии веток с поддержкой нового оборудования и для проведения глубокого рефакторинга кода там где выполнить оный в рабочем режиме не удаётся или чревато регрессиями. Это всего лишь временная пауза при переносе серьёзного пласта изменений из веток не связанных с работой над уже запущенным в серию оборудованием.

Медиа: image / jpeg

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

Для этого реализована сложная система автоматического анализа исходного кода. Непрерывное отслеживание изменений в апстримах всех компонентов системы и их своевременное обновление при необходимости.Ведём собственную SLTS ветку ядра бэкпортируя все исправления безопасности (и не только) из mainline версий (5.14 на текущий момент). А первую линию контроля качества результата выполняет система автотестов (не говоря уже о ручных проверках, лабораторных и иных испытаниях).

Но самая главная работа скрыта в драйверах радиоинтерфейсов.

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

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

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

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

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

В 3.8.9, например, исправлена крайне неприятная уязвимость позволяющая злоумышленнику осуществить подстановку L2-кадров в защищённой сети, что даёт возможность вклиниться в трафик жертвы.

Подробнее на русском можно прочесть тут https://www.opennet.ru/opennews/art.shtml?num=55133

Нами была проделана работа по портированию фикса из MT7915 драйвера в драйвера для всех поддерживаемых Wive-NG-HQ устройств (MT7610/MT7620/MT7603/MT7613/MT7615/MT7915).

И это лишь один из сотен примеров даже на отрезке времени c момента окончания контракта по Wive-NG-MT и выделения ветки Wive-NG-HQ в отдельный проект.

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

Хочу заметить, что мало кто (точнее будет сказать, почти никто) из SOHO вендоров вообще задумывается о необходимости иметь в штате специалистов способных выполнять вышеперечисленные работы… К сожалению это норма жизни.

P.S. Для Wive-NG-MT, в силу отсутствия контракта с вендором (NAG, торговая марка SNR), нами обновления не поставляются 3й год, поэтому просьба вопросы по исправлениям (в т.ч. уязвимостей) адресовать их ТП.

Медиа: image / png

Для удобства доступа к информации наших партнёров и пользователей мы развернули официальный канал в Telegram.

На текущий момент канал по сути дублирует данные с сайта wi-cat, но надеюсь заживёт своей отдельной, уникальной жизнью и будет охватывать не только вопросы о сетевом оборудовании под управлением операционной системы Wive-NG, но и сетях на базе 802.11 в общем.

Добро пожаловать!

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

Медиа: image / png

Wive-NG-HQ – это новое поколение встраиваемого ПО для сетевых маршрутизаторов из семейства Wive-NG, вобравшее в себя преимущества подходов, выработанных многолетним опытом, и актуализированное под современные требования с программной и аппаратной точки зрения. Разумеется, все возможности предшествующего поколения – Wive-NG-MT – были сохранены, но также добавилось множество новых.

Предпосылки создания отдельной HQ ветки.

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

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

Так было принято решение выделить Wive-NG-HQ в отдельный продукт.

Что осталось неизменным?

Наши ценности и подходы. Во всех продуктах Wive-NG традиционно основные ставки сделаны на надёжность и отсутствие уязвимостей.

Как и прежде, утро наших разработчиков начинается с анализа изменений в апстримных ветках ПО, используемых в составе Wive-NG, а также чтения репортов безопасности.

Своевременная синхронизация изменений в компонентах с апстримными проектами, отслеживание и устранение потенциальных уязвимостей – залог отсутствия проблем у пользователя в процессе эксплуатации. Для оператора это — снижение нагрузки на техподдержку (а вместе с тем и снижение операционных издержек). Для корпоративной среды — гарантия отсутствия потерь, связанных с простоем инфраструктуры.

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

Что нового?

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

Общесистемные изменения

• Была с нуля разработана новая система сборки, получившая кроссплатформенность, позволяющую реализовать поддержку ARM и x86 (чего невозможно было сделать в рамках МТ). Буквально каждая wive-специфичная библиотека и приложение были адаптированы для работы на любой платформе с любой архитектурой.
• Проведён рефакторинг всего кода, написанного и интегрированного за последние 6 лет. Как результат — системное исправление сотен мелких недочётов, которые в рамках МТ могли быть оперативно решены лишь с помощью обходных путей.
• Расширены API, пересмотрена взаимная интеграция компонентов системы. Что в свою очередь позволило реализовать дополнительные возможности, в частности в init и WebUI, являвшиеся “в лоб” не реализуемыми в рамках МТ.
• Реализовано сквозное автоматическое тестирования каждого вносимого изменения. В дополнение к непрерывным проверкам кода статическими анализаторами была разработана и внедрена специализированная система выявления регрессивных изменений, автоматически проверяющая на реальном оборудовании ключевой функционал после каждого изменения в git репозитории.

Радиочасть

• Реализованы и оттестированы в реальных сетях доработки драйвера радиочасти, включая собственный набор алгоритмов ADRS (Rate ALG), буквально вдохнувших новую жизнь в уже поддерживаемые радиочипы, что особенно заметно на MT7620 в 2.4ГГц в условиях максимально зашумленного эфира.
• Переработана в сторону повышения эффективности логика работы вспомогательных компонентов, реализующих, например, band steering.
• Отдельный пласт изменений коснулся роуминга. Так, handoff теперь пытается избегать отключения клиентов, которые технически способны мигрировать сами. Для старших моделей handoff теперь умеет использовать BTM (из 802.11v), позволяющий «попросить» клиента мигрировать на соседнюю AP, вместо принудительного отключения.
• Решены проблемы совместимости с «проблемными» клиентами (т.е теми, которые не поддерживают какую-либо логику в принципе, либо же анонсируют поддержку, но фактически она не работает либо работает некорректно), в т.ч. в режимах c PMF и FT.
• Полностью переработана логика FT/RRM (802.11k/r), которая теперь совместима с требованиями wifi альянса для сертификации по программе VoiceEnterprise.
• Обеспечено более строгое соблюдение RFC в сетевой подсистеме, устранены разночтения со стандартом 802.11 в радио.

Функциональность и комфорт эксплуатации

• WebUI переработан с целью повысить удобство эксплуатации для начинающих пользователей, и дать дополнительный инструментарий подготовленным. При этом сохранив комфорт и функциональность при работе технических специалистов, использующих устройства в корпоративной среде.
• Реализовано онлайн обновление ПО. Проверка наличия новой версии осуществляется автоматически, а загрузка и установка — с согласия пользователя.
• Для хранения ключей шифрования и данных оператора, в т.ч. кастомизации, было решено к механизму RWFS добавить механизм PSS (persistent storage), что решило проблему со сквозным обновлением ПО без необходимости повторной переконфигурации RWFS. Т.е. кастомизированное один раз, сохраняется впоследствии и при простом обновлении с наших серверов, не требуя никакого вмешательства.
• Для операторов добавлен механизм автоматического предоставления iptv-источников по DLNA без ручной конфигурации. Достаточно сообщить нам адрес плэйлиста IPTV, и при включении устройства пользователь сразу же, без каких-либо действий со своей стороны, получает доступ к сервису с любого медиаустройства с поддержкой DLNA. Как маркетинговый инструмент, «из коробки» может быть автоматически доступен сокращённый плэйлист, а полный — отдаваться только на STB.
• В WebUI добавлены инструменты обзора и диагностики сети (arp-scan, arpwatch, ping, traceroute, mcprobe, tcpdump итд). А также мониторинг обстановки в эфире, включая данные об утилизации эфирного времени, среднем качестве и уровне приема сигнала, количестве ошибок передачи на радиоинтерфейсах и т. д., позволяющих радиоинженеру оценить корректность построения wi-fi сети и локализовать возможные проблемы.
• Добавлен функционал управления соседними AP, традиционно называемый контроллером (доступен только в корпоративной версии ПО).

Если разбор и описание какого-то функционала кажется Вам наиболее интересным и актуальным, но статьи о нём ещё нет, будем рады Вашим предложениям на info@wi-cat.ru

С уважением автор проекта Wive-NG – Маначкин Евгений Романович (sfstudio).

Медиа: image / png

FT-AIR-DUO-F — новый двухдиапазонный FE маршрутизатор под управлением OS Wive-NG-HQ.

В отличии от предыдущих моделей, для работы в 5ГГц диапазоне устройство оснащено AC Wave2 2T2R радиомодулем, являющимся полноценным fullmac offload чипом, что позволяет снять ограничения по производительности локального радиосегмента, связанные с CPU. Это выгодно отличает модель от большинства популярных FE Dualband устройств.

Основополагающие ценности семейства устройств на базе OS Wive-NG-HQ:

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

Платформа

CPU маршрутизатора — чип MedaTek MT7620DA, работающий на частоте 580МГц. DA — это обновленная версия популярного WiSoC MT7620A, оснащенная встроенной оперативной памятью 64МБ (DDR2). В маршрутизаторе используется быстрый NOR SPI Flash объемом 16МБ.

Основным преимуществом DA версии чипа является современный, более тонкий техпроцесс, заметно снижающий нагрев в процессе эксплуатации. Снижение рабочей температуры благоприятно сказывается на собственном уровне шумов радиотракта. Также за счет оптимизации техпроцесса обеспечивается большая термостабильность, в том числе встроенного радиомодуля, что ведёт к меньшей зависимости параметров последнего от нагрузки на CPU.

CPU имеет встроенный 5-портовый коммутатор со скоростью портов 10/100Мбит/с. Благодаря встроенному блоку PPE (hwnat), маршрутизация и NAT являются аппаратными для режимов IPoE/ PPPOE , что позволяет для указанных режимов снять ограничение производительности по CPU и обеспечивает скорости, равные физическим возможностям портов. Благодаря чему маршрутизатор FT-AIR-DUO-F на базе MT7620DA выгодно отличается от других FE роутеров, в качестве HostCPU у которых используется более бюджетный FE чип от MTK – MT7628 различных ревизий, не имеющий встроенного блока PPE, следствием чего является деградация производительности в связи с нагрузкой на процессор даже в режимах IPoE/ PPPOE.

Аппаратный offload IPv6, также реализованный в MT7620DA, позволяет работать без потери производительности в операторских сетях, где ipv6 уже внедрён.

Радиочасть

Уникальным отличием FT-AIR-DUO-F от предыдущих моделей и большинства популярных устройств со сходными номинальными характеристиками является использование в качестве радиомодуля для диапазона 5ГГц современного AC Wave-2 двухстримного (2T2R) чипа MT7613AEN. Максимальный рейт в 5ГГц при полосе 80МГц составляет 867Мбит/с. Full MAC offload позволяет снять нагрузку по обработке беспроводного трафика с CPU, то есть весь трафик между клиентами внутри одного диапазона, а также в схемах WDS/APCLI дает 0% нагрузки на CPU. Таким образом, производительность беспроводного сегмента значительно превышает скорость порта (100МБит/с) и составляет порядка 300Мбит/с полезного TCP трафика между двумя клиентами, со стороны каждого.

В соответствии с возможностями AC Wave-2 , MT7613AEN поддерживает MU-MIMO, LDPC, TxBF. Аппаратный WPA3 (чем не могут похвастаться чипы предыдущих поколений) и PMF (802.11w) обеспечивают дополнительные меры безопасности для беспроводных клиентов.

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

Также использование 2T2R Wave-2 чипов позволяет заметно увеличить ёмкость беспроводного сегмента и снизить взаимное влияние соседних AP, что актуально для размещения устройств в офисе, при использовании в режиме повторителей. Благодаря наличию MU-MIMO и двух стримов (2T2R) возрастает запас эфирного времени на передачу того же объема данных.

Немаловажно, что для устройств, использующих MT7613AEN в качестве радиочипа в 5ГГц, не выявлено проблем совместимости на полосе 80МГц с клиентским оборудованием Apple и других производителей, использующих в качестве wi-fi модуля чипы BCM.

Работа 2.4ГГц обеспечивается встроенным в 7620DA 2T2R радиомодулем, поддерживающим стандарты 802.11b/n/g с максимальным рейтом 300Мбит/с.

Для построения сетей с возможностью бесшовной миграции включена поддержка 802.11k/r/v. Гибкая реализация Handoff с большим числом параметров, доступных для конфигурации, позволяет создавать распределенные сети с произвольным набором клиентских устройств. Цикл статей про роуминг в wi-fi сетях

Собственные алгоритмы ADRS (расширение Rate ALG), разработанные авторами Wive-NG-HQ, обеспечили рост производительности и повышение стабильности работы беспроводного тракта в зашумленном эфире в обоих частотных диапазонах (как по сравнению с продуктами других производителей на аналогичной платформе, так и по сравнению с устройствами, работающими под управлением ветки Wive-NG-mt).

Экспериментально полученные результаты, подтверждающие номинальные расчёты в соответствии со спецификациями радиочипов, демонстрируют отсутствие необходимости использовать внешние усилители / FEM для обеспечения стабильного покрытия в пределах EIRP, регламентированного законодательством, что положительным образом сказывается на стоимости устройства без потери качества работы беспроводного тракта. Маршрутизатор имеет 4 внешние несъемные антенны с усилением 5дБи каждая.

Функционал

Помимо работы в качестве VPN клиента, маршрутизатор также может являться VPN сервером, а именно PPPoE, PPTP или L2TP сервером. Также запланировано добавление поддержки OpenVPN.

Встроенный RADIUS сервер на базе FreeRADIUS позволяет организовать корпоративную сеть с авторизацией, включая возможность создавать уникальные пары логин-пароль прямо в web-интерфейсе роутера. Также, для работы с внешним RADIUS сервером реализована поддержка схем с Enterprise-режимами безопасности. С помощью встроенного hotspot сервера NoDogSplash возможно создание captive portal прямо на маршрутизаторе (а также, присутствует поддержка работы с внешними Hotspot серверами на базе ChilliSpot).

Встроенный AdBlock позволяет минимизировать нежелательный рекламный контент при просмотре web страниц. А функционал DNSSEC позволяет дополнительно обезопасить интернет-серфинг от подмены адресов.

Преобразование multicast в UDP unicast/HTTP обеспечивает стабильную работу IPTV. Для устройств, не умеющих напрямую работать с multicast потоками, доступно использование встроенного DLNA xupnpd. Также, встроенный DLNA сервер позволяет автоматически загружать и обновлять плейлисты операторов связи.

Управление и мониторинг

Для операторских сетей, использующих ACS для управления и диагностики, добавлена реализация протокола cwmp (TR-069, TR-098), совместимая с различными коммерческими и открытыми ACS серверами. Также реализовано автоконфигурирование с использованием Option 43. Для загрузки собственной графики, конфигурации по умолчанию, скриптов и других кастомных материалов без необходимости осуществлять пересборку ПО, реализован функционал PSS/RWFS.

Сбор статистики и данных об устройстве возможен посредством SNMP, также поддержаны такие протоколы как LLTD, LLDP, CDP. Встроенный Arpwatch позволяет собирать данные относительно клиентских пар MAC-IP.

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

Реализована регулярная автоматическая проверка наличия обновлений ПО и информирование о доступности новой версии в Web-интерфейсе, а также загрузка актуальной версии непосредственно с сервера обновлений, без необходимости дополнительно скачивать файл прошивки на ПК для дальнейшей загрузки на роутер. Установка новой версии ПО производится исключительно с согласия пользователя.

Три независимых уровня доступа к управлению — Ordinary, Management, Administrator, позволяют разделить права для различных групп пользователей, тем самым повысив безопасность администрирования.

Дистрибьютором линейки AIR является компания Fibertool ( ссылка для заказа)

Описание на Wikidevi

Обзор гигабитного роутера FT-AIR-DUO-G (Wave2 AC1300)

Медиа: image / png

FT-AIR-DUO-G — новый гигабитный маршрутизатор под управлением OS Wive-NG-HQ, являющейся на сегодняшний день актуальной и развиваемой веткой из семейства Wive-NG.

Маршрутизатор поддерживает стандарты 802.11a/b/g/n/an/ac, включая AC Wave2 и относится к классу AC1300.

В создании устройства приоритетами являлись такие ключевые качества, как:

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

Платформа

CPU маршрутизатора — чип MedaTek MT7621AT, оснащенный двумя ядрами, каждое из которых работает в 2 потока на частоте 880МГц.

Встроенный 5-портовый гигабитный коммутатор, подключенный двумя RGMII интерфейсами к CPU позволяет организовать физически независимые интерфейсы WAN/LAN, что обеспечивает полнодуплексный гигабит (т.е, суммарно 2Гбит/с). Это даёт очевидное преимущество перед распространенной среди недорогих маршрутизаторов схемой, в которой коммутатор подключен к CPU одним портом, а интерфейсы разделены посредством VLAN, что даёт ограничение в 1Гбит/с полудуплекса WAN->LAN.

Благодаря встроенному блоку PPE (hwnat), маршрутизация и NAT являются аппаратными для режимов IPoE/ PPPOE , что снимает ограничение по CPU и обеспечивает скорости, равные физическим возможностям портов. Аппаратный offload IPv6 позволяет работать без потери производительности в операторских сетях, где ipv6 уже внедрён.

Объём оперативной памяти составляет 256МБ (DDR3), что позволяет обеспечить работу дополнительных сервисов, таких как медиасервер, внешнее хранилище данных и тд. В маршрутизаторе используется NOR SPI Flash объемом 16МБ.

USB3.0 на борту позволяет резервировать канал с помощью 3G/4G модема, а также подключать внешний накопитель для организации файлового хранилища и расширения функционала маршрутизатора с помощью приложений из репозитория EntWare. USB порт имеет программное управление питанием, что при необходимости позволяет снять питание именно с USB, без необходимости целиком перезагружать устройство.

Радиочасть

В качестве радиомодуля используется чип MT7615DN. Это Wave2 MU-MIMO чип класса AC1300, работающий в режиме DBDC, то есть одновременно в двух частотных диапазонах 2.4ГГц и 5ГГц, по два стрима в каждом (2x 2T2R). Максимальный рейт в 5ГГц при полосе 80МГц составляет 867Мбит/с, а в 2.4ГГц — благодаря поддержке 256QAM — 400Мбит/с (в отличии от бюджетных маршрутизаторов, например, с использованием MT7603, где номинал составляет N300).

Встроенный процессор ARM Cortex R4 позволяет снять нагрузку по обработке беспроводного трафика с CPU, что обеспечивает общий рост производительности маршрутизатора.

Будучи Wave-2 чипом, MT7615DN включает в себя поддержку технологий MU-MIMO, LDPC, TxBF, Airtime. Для повышения мер безопасности добавлен WPA3 на аппаратном уровне (чем не могут похвастаться чипы предыдущих поколений) и PMF (802.11w).

Для построения сетей с возможностью бесшовной миграции включена поддержка 802.11k/r/v(BTM). Гибкая реализация Handoff с большим числом параметров, доступных для конфигурации, позволяет создавать распределенные сети с произвольным набором клиентских устройств. Цикл статей про роуминг в wi-fi сетях

Собственные алгоритмы ADRS (расширение Rate ALG) позволили повысить стабильность и пропускную способность радиочасти в зашумленном эфире, как по сравнению с продуктами других производителей на аналогичной платформе, так и по сравнению с устройствами, работающими под управлением ветки Wive-NG-mt.

Для обеспечения стабильного покрытия в пределах EIRP, регламентированного законодательством, оба частотных диапазона оснащены современными усилителями (FEM) от SkyWorks: SKY85303-21 для 2.4ГГц и SKY85746-11 для 5ГГц. Все дорожки экранированы. Маршрутизатор имеет 4 внешние несъемные антенны с усилением 5дБи каждая.

Функционал

Маршрутизатор не только может являться VPN клиентом, но и позволяет организовать встроенный VPN сервер, а именно PPPoE, PPTP или L2TP сервер. Также в ближайшее время появится поддержка OpenVPN.

Для организации корпоративной сети с авторизацией добавлен встроенный RADIUS сервер на базе FreeRADIUS с возможностью создавать уникальные пары логин-пароль прямо в web-интерфейсе роутера. Встроенный hotspot сервер NoDogSplash позволяет создать Captive Portal прямо на маршрутизаторе (впрочем, есть и возможность интеграции с внешними Hotspot-сервисами на базе ChilliSpot). Также, для работы с внешним RADIUS сервером реализована поддержка схем с Enterprise-режимами безопасности.

Встроенный AdBlock позволяет снизить количество нежелательного рекламного контента при просмотре web страниц. А функционал DNSSEC позволяет дополнительно обезопасить интернет-серфинг от подмены адресов.

Для обеспечения работы IPTV реализовано преобразование multicast в UDP unicast/HTTP, в т.ч. с привлечением встроенного DLNA для работы на устройствах, не умеющих напрямую работать с multicast потоками. Также, встроенный DLNA сервер позволяет автоматически загружать и обновлять плейлисты операторов связи.

Для внешнего хранилища (flash/ HDD), подключенного к USB3.0, доступны такие возможности как организация FTP сервера, загрузка приложений для расширения фукнциональности устройства с репозитория Entware, а также загрузка медиаконтента посредством встроенного torrent клиента. Подробнее про возможности USB

Управление и мониторинг

Для работы в операторских сетях добавлена поддержка протокола cwmp (TR-069, TR-098) совместимая с различными реализациями ACS (открытыми и коммерческими), а также автоконфигурирование с использованием опции 43. Для загрузки собственной кастомной информации, такой как графика, конфигурация, скрипты и т.д, без необходимости осуществлять пересборку ПО, реализован функционал PSS/RWFS.

Сбор статистики и данных об устройстве возможен посредством SNMP, также поддержаны протоколы LLTD, LLDP, CDP. Встроенный Arpwatch позволяет собирать данные относительно клиентских пар MAC-IP.

В Web-интерфейсе доступна развернутая статистика по всем беспроводным клиентам, включая информацию о том, с какими характеристиками клиентское устройство подключено к роутеру, статистические данные о пропускной способности, рейтах и средневзвешенном качестве сигнала как по всей AP, так и по каждому клиенту. Для наглядности доступно как текстово-табличное, так и графическое представление статистических данных.

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

Для разделения прав и повышения уровня безопасности, для маршрутизатора доступно три независимых уровня доступа пользователя — Ordinary, Management, Administrator.

Дистрибьютором линейки AIR является компания Fibertool ( ссылка для заказа)

Описание на Wikidevi

Медиа: image / png

EEE Std. 802.1X-2001 — это стандарт, описывающий механизм аутентификации и контроля доступа пользователей на уровне транспортной сети (подробнее: https://ru.wikipedia.org/wiki/IEEE_802.1X). Если говорить про Wi-Fi, то 802.1x является ключевым элементом процесса аутентификации в сетях с WPA Enterprise. Отличительной особенностью такой схемы является возможность иметь индивидуальные учётные данные для каждого пользователя.
Обычно схема состоит из трех основных компонентов: Запрашивающее устройство (Supplicant), Аутентификатор (коммутатор, точка доступа) и Сервер Аутентификации (RADIUS server). Чаще всего используется выделенный RADIUS сервер предприятия, который также может быть интегрирован с AD (или иным используемым на предприятии решением), что позволяет не только реализовать сквозную аутентификацию пользователей по индивидуальным учетным данным, но и управлять доступностью тех или иных ресурсов для каждого пользователя.

Работа 802.1x авторизации – схематически

Рассмотрим подробно процесс авторизации на RADIUS сервере беспроводного клиента

1. В момент подключения нового беспроводного клиента (Wireless Node) с запросом на получения доступа к локальным ресурсам, точка доступа (AP), выступающая в роли Аутентификатора запрашивает у него идентификацию. В этот момент никакой трафик, кроме EAP, клиенту не разрешен. Задачей Supplicant-а, входящего в состав клиентского устройства, является ответ Аутентификатору и передача необходимых для идентификации данных. Аутентификатором, кстати, необязательно должна быть точка доступа — это может быть и внешний компонент.

2. После того как идентификационные данные отправлены, начинается процесс аутентификации. Протокол, используемый для взаимодействия Supplicant-а и Аутентификатора называется EAP, или если быть точнее, EAP инкапсуляция поверх LAN (EAPoL). Аутентификатор реинкапсулирует сообщения EAP в формат, соответствующий требованиям RADIUS и отправляет их на Сервер Аутентификации. В процессе аутентификации Аутентификатор лишь транслирует пакеты между Supplicant-ом и Сервером Аутентификации. По завершении процесса, Сервер Аутентификации отправляет сообщение в зависимости от результата — Success или Failure.

3. В случае успешной аутентификации на Сервере, Аутентификатор открывает доступ клиентскому устройству, с Supplicant-ом которого он взаимодействовал. Клиентское устройство получает доступ к локальным ресурсом и/или сети Интернет.

Важно: Wi-fi точка доступа, выступающая в качестве Аутентификатора, играет роль исключительно ретранслятора запросов от клиента к RADIUS-у с инкапсуляцией EAP в EAPoL. При этом поддерживаемый набор EAP методов обеспечивается Supplicant-ом клиента и Сервером Аутентификации, и никак не зависит от точки доступа.

Настройка RADIUS авторизации в Wive-NG

Маршрутизатор на базе OS Wive-NG может выступать как в роли Аутентификатора на предприятии, где уже развернут RADIUS сервер, так и исполнять роль этого сервера, за счёт интегрированного FreeRadius. Последнее очень удобно для небольших организаций, поскольку позволяет построить полноценную сеть с авторизацией, не прибегая к наращиванию сетевой инфраструктуры и мультивендорности.

Настройка RADIUS авторизации беспроводных клиентов

Конфигурация осуществляется в разделе Настройки радио -> Основные -> Политики безопасности. Значением параметра «Выбор SSID» (1) выбирается та беспроводная сеть, которую необходимо настроить для работы с внешним RADIUS сервером (в том случае, если на роутере настроено несколько SSID).
«Режим безопасности» (2) необходимо установить WPA2 (Enterprise). После этого, помимо настроек WPA, отобразится блок «Радиус сервер». В нём необходимо как минимум указать IP адрес сервера аутентификации (3) (это может быть как произвольный RADIUS сервер, уже имеющийся на предприятии, так и сервер, запущенный на другом маршрутизаторе под управлением Wive-NG, или даже на этом же самом маршрутизаторе). Также необходимо указать Shared Secret (4) в соответствии с конфигурацией сервера аутентификации. Порт по умолчанию указан 1812, что является дефолтным значением в рамках стандарта.

Настройка WPA2-Entrprise для работы с внешним RADIUS сервером в Wive-NG

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

Пример настройки 802.1x авторизации на Android клиенте

Настройка RADIUS сервера на Wive-NG

Чтобы сконфигурировать RADIUS сервер на маршрутизаторе под управлением Wive-NG, достаточно перейти в раздел настроек Сервисы -> Сервер RADIUS и включить (1) RADIUS сервер, а также задать Shared Secret (2), который впоследствии будет указан на Аутентификаторе. После применения статус (3) будет переведен в значение «работает». Чтобы создать пользовательские пары «логин-пароль», достаточно ввести соответствующие данные в разделе «Пользователи» и нажать «Добавить». Чтобы отредактировать или удалить уже существующую пару, воспользуйтесь соответствующими иконками, расположенными в строке с этой парой.

Важно: На клиентском устройстве необходимо будет указать метод EAP — PEAP, а для проверки подлинности 2 этапа использовать значение MSCHAPv2. Для штатной реализации RADIUS сервера в Wive-NG была выбрана именно схема PEAP+ MSCHAPv2, потому как именно она является наиболее универсальной и поддерживаемой на любых устройствах.

Настройка встроенного RADIUS сервера в Wive-NG

P.S. В корпоративной среде обычно используют отдельный радиус сервер, например на основе специализированного дистрибутива https://www.daloradius.com/

Медиа: image / png

Уведомление о наличии обновленной версии ПО для wi-f -маршрутизатора на базе Wive-NG

Оповещение об отсутствии обновлений ПО для устройства

Медиа: image / png

Предоставление ва шим провайдером белого статического IP адреса является обязательным условием работы туннеля. Иными словами, IP адреса на WAN-интерфейсе не должны быть из следующих подсетей: 192.168.0.0/16, 172.0.0.0/8, 10.0.0.0/8.

Шаг №1. Регистрация на сайте туннельного брокера
Регистрируемся на ipv6.ip4market.ru (или у другого брокера).

Регистрация на сайте ipv6 брокера

Процесс регистрации максимально прост и представляет собой указание email, контактного номера телефона и белого IP адреса от провайдера. Нажатие «Go IPv6!» завершает процесс регистрации:

Успешная регистрация

А на электронную почту будут отправлены персональные настройки туннеля 6in4.

Важно: 6in4 — это частный случай 6to4. Разница состоит в том, что в случае 6in4 шлюз находится вне операторской сети, т.е у брокера. В случае же 6to4 адрес шлюза находится в операторской сети и является фиксированным (192.88.99.1), как и префикс.

Реквизиты 6in4 , предоставленные ipv6 брокером

Эти же данные можно найти в личном кабинете.

Реквизиты 6in4, предоставленные брокером ipv6

Шаг №2. Настройка ipv6 туннеля на маршрутизаторе

Заходим в web-интерфейс маршрутизатора (реквизиты по умолчанию: IP адрес 192.168.1.1, логин и пароль Admin / Admin). Рекомендуется обновить прошивку до последней из официального репозитория. Переходим в Настройки сети -> настройки IPv6. Первым делом необходимо включить IPv6, выбрав режим работы IPv6 “Туннель 6TO4”.

Включение ipv6 в режиме 6to4

Далее необходимо взвести флаг «Использовать IPv6 префикс провайдера» в блоке «Настройка туннеля 6to4» и произвести настройки в соответствии с тем, что указано в личном кабинете на ipv6.ip4market.ru. Пример заполнения приведен на скриншоте. Для работы IPv6 на клиентах в локальной сети включаем «Автоматически выдавать клиентам IPv6 адреса (radvd)» и «Автоматически выдавать клиентам DNS/prefix (dhcp6s)». По окончании настройки не забываем нажать «Применить».

Настройка 6to4 в Wive-NG

Важно: указывая префикс, необходимо исключать «::» в конце. Например, если от ipv6 брокера предоставлено 2a03:e2c0:bdd:5555::/64 , то указывать необходимо 2a03:e2c0:bdd:5555.

Важно: при работе 6to4 необходимо использовать префикс /64 в соответствии со стандартом.

На клиентском устройстве необходимо убедиться в том, что IPv6 включен, а в его настройках выбрано автоматическое получение IP адреса и DNS. В состоянии подключения убеждаемся в том, что IPv6 адресация пришла на ПК. В OS Windows выглядит так:

Включение ipv6 в Windows

Состояние сетевого подключения в Windows

На этом настройка заканчивается. Проверить, что ipv6 заработал, можно с помощью сайтов https://ipv6test.google.com/ , http://ipv6-test.com/ , https://test-ipv6.com/ и других.

Подтверждение успешного подключения к ipv6 туннелю

Медиа: image / png

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

Определимся с терминологией:

DS – Distribution System. Дословно «система распределения». В контексте рассматриваемой задачи это опорная сеть. Т.е. непосредственно сеть, по которой бегает трафик от клиента в мир и назад.

Как может быть организована DS?

• Самый частый (и правильный) случай – это банальная кабельная сеть, связывающая все AP и шлюз в мир в единую сеть.
• Второй вариант – использование WDS/APCLI. По сути то же самое, но по воздуху без использования кабельной ифраструктуры.
• Гибридные схемы. Например, разные AP подключены в разные шлюзы, используют разный транспорт и даже разные сети, принадлежащие разным операторам (3G/4G,WiFi,LAN и т. д.). Даже в этом случае возможен бесшовный роуминг между AP. Однако, этот подход добавляет лишний слой в виде L2 туннелей (например L2TPv3) для объединения всех их в единую связную на L2 сеть.

Уже на этом этапе вы могли заметить оговорку о необходимости организации плоской L2 сети. Это является основным требованием для реализации бесшовной миграции.

Допустим, с миграцией на L1 у нас всё отлично, и все описанные предыдущих статьях вещи работают от и до, клиенты корректно переключаются между AP. А что дальше? Нам ведь нужно не просто обеспечить корректное переключение клиента на уровне физики. Нам важно сохранение соединений на уровне клиентских приложений, чтобы авторизация не слетала, голосовые соедиенения не рвались, чатики не реконнектились при каждой миграции.

Именно тут и добавляются новые требования к построению DS:

1. Плоская L2 сеть между клиентами и шлюзом;
2. Единый шлюз в мир, доступный с любой точки, на какую бы клиент ни переключился;
3. Единое адресное пространство с минимальным шансом смены адреса клиентом при миграции;
4. Быстрое и гарантированное обновление MAC tables на всём промежуточном оборудовании (коммутаторах, например) при первом же пакете от клиента после миграции;
5. Связная на L2 сеть между AP.

Иными словами, все клиенты у нас должны быть в одной плоской сети, а IP-адреса выдаваться одним DHCP сервером, дабы избежать ситуации, когда при миграции клиента сменится и его IP-адрес, в результате чего state`ы соединений приложений и conntrack пойдут прахом.

DHCP

Штатный механизм с выделением lease и продлением оных часто тут оказывается бессилен (нередко клиент до или после миграции зачем-то шлёт DHCP release). Поэтому во всех Enterprise системах (в Wive аналогично) используется DHCP сервер, который выдаёт адреса из диапазона с оглядкой не только на возможно уже существующую lease для этого клинта, но и на hash MAC-адреса.

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

Коммутация

AP чаще всего собраны в один или несколько коммутаторов. Важно, чтобы эти коммутаторы не имели распространённой проблемы в виде «залипания» записи в MAC table. Т.е. когда клиент исчез с одного порта и появился на другом, все таблицы по пути должны быть перестроены мгновенно (т. е. процесс, как многие любят выражаться, «обучения» должен быть моментальным).

Для ускорения этого момента на стороне AP в Enterprise мире (в Wive аналогично) используется следующий подход: после миграции клиента AP, не дожидаясь первого пакета в мир от клиента, сама шлёт от его имени что-либо в DS, вынуждая коммутаторы перестроить таблицы коммутации. Чем обеспечивается готовность DS ещё до начала передачи клиентом полезных данных.

Для чего нужна связность между AP?

Дело в том, что AP между собой обмениваются информацией, используя протокол IAPP, внутри которого бегают данные, например, необходимые для ускорения фазы аутентификации при использовании FT (не будем вдаваться в подробности, т. к. это тема отдельной большой статьи).

Самое важное – этот же IAPP используется для move notify.

Таким образом, AP, на которую мигрировал клиент, сообщает всем своим соседям о том, что клиент теперь работает через неё, и запись для этого клиента можно удалить из MAC table старой AP.

Важно это потому, что чаще всего клиент при миграции не посылает LEAVE той AP, с которой мигрировал. AP, продолжая думать, что клиент всё ещё обслуживается на ней, продолжает пытаться послать данные из очереди в сторону этого клиента. Учитывая, что клиент её уже не слушает, такие передачи всегда будут неудачными. Но проблема не в этом, она глубже: дело в том, что пока AP пытается выполнять TxRetry в сторону такого клиента, никакая передача больше невозможна. TxRetry limits могут быть достаточно большими, к тому же RATE-ALG закономерно снижает rate, думая, что просто ухудшились параметры эфира, и пробует снова. В некоторых случаях этот процесс может занимать секунды, а все соседи на этой AP будут ждать, когда же их обслужат. Проще говоря всё это время любой другой обмен данными с этой AP будет парализован.

Move notify позволяет свести к нулю подобные проблемы, удаляя запись о клиенте из MAC table AP сразу по приходу нотификации о том, что клиент уже обслуживается другой AP.

Это всё работает независимо от того как организована DS. Что бы ни было ниже (LAN/ WDS/ MESH/ APCLI) , эти подходы не меняются и для полноценной прозрачной миграции являются необходимостью.

Гибридные сети.

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

Лучшая DS для сетей с миграцией это LAN DS на коммутаторах с минимумом мозга, т. к. чаще всего проблемы начинаются именно с этого мозга (ложные детекты конфликта MAC-адресов при миграции, залипание записей в MAC table, дикие траблы с ARP cache и прочие прелести).

Workarounds (костыли).

Часто, чтобы обойти излишнюю “умность” и инициативность коммутаторов (из-за которой чаще всего и возникают проблемы с обновлением mac tables и arp cache в DS), в Enterprise делают финт ушами. Разворачивают а-ля контроллер. Он же обычно является шлюзом для беспроводки, на нём же живёт DHCP (с механизмом генерации IP по hash`у MAC-адреса), и на нём же собирают L2 туннели с AP, которые и решают проблемы излишней «умности» оборудования DS. Иными словами, осуществляется надстройка над физической сетью ещё одного уровня логики. Аналогично делает Mikrotik с его capsman.

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

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

Ибо, как говорил Чехов, «Если в начале пьесы на стене висит ружье, то (к концу пьесы) оно должно выстрелить.».

Стоит избегать:

• Усложнения схемы без нужды (усложнение ради усложнения);
• Использования чересчур умного оборудования для решения простых задач;
• Построения DS по воздуху просто в силу того, что воздух – среда передачи непредсказуемая и доступная всем, кто имеет соответствующее оборудование. В случае с WiFi любой школьник с телефоном в кармане может стать проблемой вашей корпоративной сети с DS по воздуху.

Чем меньше потенциальных точек отказа — тем лучше. А Wive-ng позволит вам иметь реализации подходов к организации бесшовной беспроводной сети уровня Enterprise, не теряя полного контроля над логикой работы на самом низком уровне.

Часть 4 Часть 6

Медиа: image / jpeg

Знакомство с Wive-NG стало ещё проще и доступнее, благодаря эмулятору WEB UI нашей OS. С его помощью можно познакомиться с интерфейсом, оценить доступный в GUI функционал маршрутизаторов на базе OS Wive-NG. Demo UI расположен тут

Эмулятор Web-интерфейса демонстрирует максимально полный функционал, соответствующий старшим моделям под управлением OS Wive-NG (на текущий момент SNR-CPE-ME1).

Необходимо помнить, что эмулятор – это система, созданная для ознакомления с решением, а не “живое” устройство. Поэтому для него есть ряд ограничений. Некоторые опции (особенно, связанные с внешними для web-сервера службами) доступны к конфигурированию частично, либо вовсе недоступны. Часть функционала может работать некорректно по сравнению с “полевым” использованием реального устройства. Также, данные, добавленные для демонстрации работы сервисов сбора и отображения статистики, являются эмуляцией, но не реальным realtime-состоянием какого-то конкретного устройства (либо статистических данных может не быть). Это нормально и вызвано ограничениями Demo UI.

Медиа: image / jpeg

Помимо контент-фильтрации на уровне DNS и блокировки нежелательного контента посредством Adblock, механизм работы которых мы рассмотрели в предыдущей статье, в ПО Wive-NG начиная с ветки 7.8 добавлена поддержка DNSSec, призванного обеспечить защиту от подмены DNS, а также – возможность организовать доступ к ресурсам локальной сети по доменным именам.
Включается и настраивается весь опционал, относящийся к DNS сервисам, в разделе Services -> DNS Services (Сервисы ->Службы DNS) при условии запущенного DNS Proxy.

Добавление локальных записей DNS

Для обеспечения пользователям доступ к локальным ресурсам и сервисам посредством доменных имён, в разделе DNS Services предусмотрен блок настроек Local DNS Entries. Помимо этого, локальная запись DNS позволяет отказаться от NAT loopback – достаточно для ресурсов, доступных в глобальной сети по определенному доменному имени, создать локальную запись с идентичным доменным именем и локальным IP адресом этого ресурса. Это позволяет разгрузить маршрутизатор и нивелировать риск некорректной работы того же NAT loopback.

Включение локальных DNS в ПО Wive-NG

Для того, чтобы обеспечить корректную работу локальной записи DNS, необходимо первым делом присвоить постоянный IP адрес (2) MAC адресу (1) устройства (3), для которого мы создаем запись. Сделать это можно в разделе Services -> DHCP Server -> Static IP address assignment table. При отсутствии статической пары MAC — IP, IP адрес целевого устройства, полученный от DHCP сервера роутера, может измениться, после чего локальная запись DNS станет недействительной.

Присвоение постоянного IP адреса MAC адресу целевого устройства

Следующим шагом в блоке Add Local DNS Entry следует создать запись, включающую IP адрес (1) (который ранее мы присвоили на постоянной основе ресурсу, к которому обеспечиваем доступ) и доменное имя (2), по которому ресурс будет доступен пользователям локальной сети. Достаточно добавить запись (3) и применить, нажав Apply внизу страницы. Перезагрузка устройства не требуется.

Добавление локальной DNS записи

После добавления записи, последняя появится в таблице Local DNS Entries. Одновременно с этим целевой ресурс станет доступен по доменному имени.

Проверка доступности локального ресурса по доменному имени

Тип сервиса в данном случае роли не играет (это может быть http, samba, и т.д).

Важно: если пользователь пропишет DNS локально на своем устройстве, то доступа к локальным ресурсам по доменным именам, прописанным в качестве локальных DNS на роутере, не будет. Чтобы избежать такой ситуации, достаточно включить опцию «Перенаправлять DNS на локальный сервер»:

Включение редиректа всех запросов на локальный DNS

Важно: не забываем, что данные записи – исключительно локальные. То есть, из интернета резолвиться они не будут.

Функционал DNSSEC

Для препятствования атакам, основанным на подмене DNS, в ПО Wive-NG добавлена поддержка DNSSec. Чтобы ее включить, достаточно выставить параметр DNSSec в значение Enable.

Важно: в силу ресурсоёмкости функционал DNSSEC доступен только в сборках Wive-NG для старших моделей (на базе MT7621)

Включение DNSSec в Wive-NG

Как работает DNSSec:

В основе принципа работы DNSSec лежат цифровые подписи, за счёт которых проверяется подлинность ответов, полученных от DNS серверов. Для понимания нам понадобятся термины:
ZSK – zone signing key — ключ, которым подписывается зона
KSK – key signing key — ключ, которым подписывается набор ключей
Закрытый ключ – с помощью него формируется цифровая подпись
Открытый ключ – с помощью него производится валидация цифровой подписи
В отличии от схемы без DNSSec, при выставленном бите DO (означающем работу DNSSEC) каждая итерация будет возвращать резолверу не только адрес DNS сервера, отвечающего за нижестоящую зону, но еще и DNSKEY — набор открытых ZSK и KSK ключей зоны, подписанный закрытым ключом KSK зоны, а также подписанный с помощью закрытого ZSK зоны хэш KSK (DS-запись) для нижестоящей зоны.
Алгоритм каждой итерации таков: подлинность открытого KSK зоны проверяется путем сравнения хэшей с тем, что получен для этой зоны от вышестоящей на предыдущей итерации. Если подлинность подтверждается, резолвер доверяет открытому ключу KSK и производит валидацию подписи набора ключей (DNSKEY). Если валидация пройдена, резолвер начинает доверять открытому ключу ZSK и с его помощью производит валидацию DS-записи для нижестоящей зоны, получая тем самым хэш KSK, используемый в следующей итерации для валидации ключей нижестоящей зоны. DS-запись для корневой зоны резолвер получает от т.наз. trust_anchor. Схематически, процесс выглядит так:

Принцип работы DNSSec – схематически

Какая-либо ручная настройка для работы DNSSec не требуется — достаточно просто включить данную опцию в web интерфейсе.

Важно: если хотя бы на одном из этапов валидация не будет пройдена, резолвер вернет ошибку servfail. То есть, для корректной работы DNSSEC все клиенты и серверы должны его поддерживать.

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

Просмотр и добавление альтернативных DNS серверов для корректной работы DNSSec

В этом случае DNSMASQ использует для резолва альтернативные серверы из блока Upstream DNS, в то время как локальные сервисы ПО продолжают использовать провайдерские DNS серверы.

Список публичных DNS серверов, в том числе поддерживающих DNSSec, доступен, например, здесь

Медиа: image / png

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

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

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

Как это выглядит для пользователя. Запускаем speedtest, радуемся скорости, не соврали. Тест завершается, и спустя пару секунд wifi решает переподключиться. Зачем? А фиг его знает. Ладно, ну глюк, ну бывает. Запускаем видео с DLNA в VLC. Играет минут 5 – 30 (как повезёт) – опять реконнект.

Лезем на AP и смотрим лог. И видим там такую картину.

5GHz AP ASSOC - receive DIS-ASSOC(seq-352) request from cc:4b:73:2e:4d:5e, reason=8
ASSOC - Assign AID=2 to 5GHz AP cc:4b:73:2e:4d:5e
ASSOC - HT support STA. Update AP OperaionMode=3 , fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
ASSOC - VHT support STA

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

[ 164.696490@0] CFG80211-ERROR) wl_escan_handler : unexpected Escan Event 11 : abort 
[ 181.162645@0] CFG80211-ERROR) wl_escan_handler : unexpected Escan Event 11 : abort 
[ 186.057573@2] CFG80211-ERROR) wl_cfg80211_disconnect : Reason 3 
[ 187.013622@0] CFG80211-ERROR) wl_is_linkdown : Link down Reason : WLC_E_LINK 
[ 187.019685@0] link down if wlan0 may call cfg80211_disconnected. event : 16, reason=2 from f8:f0:82:01:00:04

На первые 2 строки не обращаем внимания – это просто неработающий background scan, ибо дров криво собран, опять-таки не удивительно.
А вот дальше видим сообщение от 802.11 подсистемы ядра, что, мол, что-то пошло не так (2 – leave – я устал, я ухожу=). Затем сразу видим опускание линка с генерацией линк биат и посылом в сторону AP DEAUTH фрэйма с reason=2 (reason 2 – предыдущая сессия аутентификации не верна), и что самое интересное – AP получает этот DEAUTH фрэйм с reason=8 (т.е. как DISSASSOC LEAVING, чудесато)…

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

Нагугливаем даташит на AMPAK. Несколько раз ужасаемся, какое это гамно, легче от этого не становится. Однако в нём есть прекрасная картинка – блок схема, из которой понятно, что в обвязке BCM только свитч BT/WLAN.

После ряда тестов выясняем, что с момента, когда пропал трафик, и до момента того, когда клиент решает отключиться, проходит несколько секунд. Правдами и неправдами пытаемся поймать зависимость, а её нет. И тут после пары литров кофе и мешка сигарет в голову приходит, что единственное, что может вот так лихо останавливать передачу на корню, – это срабатывание механизма CCA и RRM QUIET. Второго эта железка не умеет. А вот ED-CCA ещё как.

Лезем в конфиг, живущий по адресу /etc/wifi/6255/nvram.txt и в самом конце видим:

ed_thresh2g=-54
ed_thresh5g=-54

ООООО.. -54 порг для ED-CCA ??? Он же почти никогда не будет срабатывать…. Гуглим, находим ошмётки непокорёженных дров от BCM и там видим порог -77. Ок. Пробуем – фиг, вообще RX почти всегда вырублен и даже аутентификация не проходит. Прелесть какая.

Ок. Действуем от обратного, напрочь вырубаем ED логику в CCA, задрав порог в -30. Вуаля.. Всё забегало, скорость в норме, смотрим фильмец и под самый конец ловим опять то же самое. Пытаемся повторить – повторяется, но интервал уже около получаса, не меньше. Пробуем выкрутить ещё выше порог, но нет.

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

Выправляем (т.к. нет оборудования – на глазок по примеру от какой-то железки, где оно похоже на правду).

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

Тупо подменяем бинари и тестим. И вот оно. Самый последний бинарь от июля с какого-то проекта на рокчипе не устраивает диких плясок ни при копировании, ни при просмотре. УРРРА.

Ради интереса меняем конфиг на оригинальный и получаем ту же Ж, что была раньше. Вывод ED-CCA по-прежнему глючит у BCM, и его вырубать надо, калибровки тоже нужно править (PER на стороне AP с новыми 0, со старыми 12-15% постоянно).

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

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

P.S. По собственной оценке, за такие устройства вендор ещё и приплачивать должен. Ибо куда ни плюнь, всё работает через Ж. Это ещё одна причина, почему не стоит покупать железки без нормальной софтовой поддержки вендором. Ну если вы только не готовы сами тратить время на решение проблем, что не всегда реально, даже имей вы должную квалификацию. В том смысле, что время потратите, но решить проблему может и не удаться т.к. вендор так или иначе не поставляет исходники. Описанное выше решение – это банальное везение, что удалось обойтись без ковыряния самого драйвера, иначе бы этим проектором только орехи колоть.

Медиа: image / jpeg

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

Ну и как же без развенчания мифов?

Медиа: image / jpeg

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

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

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

Запомните правило. Все стационарные клиенты (TV/STB/PC/etc, всё что пользователь не носит с собой) должны быть подключены исключительно кабелем (Ethernet/PLC/etc), никаких Wi-Fi! И это факт.

Тяга навесить всё на WiFi неизбежно приводит к ситуации, когда на WiFi, например, оказывается 4К телевизор или STB. И всё время, пока один пользователь смотрит свой фильм, все ближайшие соседи вынуждены отдыхать. И хорошо, если оборудование соседей настроено правильно и за счёт механизма CCA (проверка доступности среды передачи) мы не получим интерференцию, а вместо этого эфирное время абы как поделится.

На практике это не так. Ваши же (в основном отличились ISP) вредные советы на тему выбора “свободного канала” всякими inSSIDer-ами приводят к тому, что CCA по сути никогда не будет работать, а эфир утонет в интерференции. Т.е. нормальная передача и достижение высших рэйтов будут невозможны по определению.

Это теория. Теперь практика. Сейчас 5ГГц более-менее свободен. И вот Васе провайдер ставит 4K STB (ну или Вася покупает 4K ТВ, или Вася качок и гоняет круглые сутки торренты)… И тут начинается самое интересное. Провод? Да нет же, у Васи ремонт. И всё радостно вешается на WiFi. В итоге Вася выбрал всю полосу в первом поддиапазоне (36-48 канал), ему же нужны максимальные скорости (те же 4к рипы нередко 160Мбит), при этом роутер в коридоре, а Вася на другой стороне квартиры с ТВ (или ещё с чем). Т.е. рэйт колеблется в 263Мбит, при этом утилизация полосы 100%.

И тут вы заходите к его соседу Пете, заводите кабель. История повторяется. И вы (ну если очень повезло и все клиенты Пети умеют работать во втором 52-64 поддиапазоне) садите туда Петю. И вот уже оба поддиапазона с точки зрения CCA заняты. А больше ёмкости нет… Выше 64го канала уже редкие клиенты умеют работать.

Появляется новый абонент Галя (ну чтобы так грозно). Галя – любитель 4к собачек рассматривать. И конечно у неё ровно та же история. Супер ремонт, кабели не проложены и т.д. И вот “умный монтажник” ставит всё то же самое и радостно выбирает по инсайдеру “свободный канал”. При этом, обоих соседей слышно с уровнями >-75. Это гарантированно добивает эфир. Выставь он тот же канал, что у Пети или Васи, работал бы CCA, и устройства бы старались не мешать друг другу и не орать совместно, т.е. у обоих бы упала скорость, но работа была бы стабильной. При этом, монтажник уходит, т.к. всё вроде работает.

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

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

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

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

Увы, WiFi такой палочкой не является. И если сейчас проблемы наблюдаются редко, то с началом радостной экспансии проводных ISP в 5ГГц диапазон, на стороне пользователя неизбежно возникнут проблемы. И коснётся это всех, кроме людей, живущих в частном секторе.

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

Проблема взаимного влияния пользователей и их оборудования, возможно, решится с массовым приходом 60ГГц (802.11ad, 802.11ay), в котором просто в силу физических причин сигнал существенно затухает даже в тонком листе бумаги. Но это не решит проблемы использования радиоканала как замены кабеля в помещении.

А что же делать? Ну, например, использовать PLC (связь по электропроводке). Использовать плинтуса, которые сегодня поголовно идут с кабель-каналом и максимально дёшевы.

Есть правило, гласящее, что все стационарные клиенты должны быть подключены проводом. ТВ, STB, и прочие. Чем меньше вы навесите на WiFI – тем меньше в итоге получите проблем (пользователи с сервисом, операторы с ТП).

Используйте PLC, тяните кабель. Если уж надо wifi – размещайте оборудование там, где будут основные потребители в той или иной квартире. Объясняйте пользователям о потенциальных проблемах. Рассказывайте, что чем меньше они сами же нагружают эфир – тем меньше шансов через какое-то время получить проблемы.

Пользователям же рекомендую перестать слушать “умных монтажников” и пытаться навешивать всё на Wi-Fi. А при ремонте предусмотреть LAN розетки и разводку проводного сегмента так, чтобы не возникало необходимости вешать стационарные устройства и устройства, генерирующие очень много трафика исключительно на WiFi.

Такова природа радиосвязи, и это нужно учитывать.

P.S. О наболевшем, после очередного созерцания мучений пользователя, где ситуация с Петей, Васей и Галей уже случилась. Т.е. по мотивам реальных событий.

Медиа: image / jpeg

Просто отличная статья о проблемах тех самых, “дружественных интерфейсов” была некогда опубликована компьютеррой. Позволю себе привести её полностью.

Есть у меня шестерка слуг,
Проворных, удалых
И все, что вижу я вокруг, –
Все знаю я от них.
Редъярд Киплинг

Сейчас все привыкли к термину “дружественный интерфейс”. Никто и не задумывается над тем, какой смысл кроется в этих словах. А если задуматься, то становится немного страшно – такое впечатление, что наши электронные творенья – программы, если и не захватили еще власть на Земле, то, во всяком случае, из-под нашей власти вырвались.

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

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

Но программы – наши создания. А что бывает, когда создание забывается и пытается встать на равную ногу с создателем, подробно описано в Книге Бытия.

Конечно, английский термин friendly, калькой с которого является наше “дружественный”, имеет несколько другой оттенок. Его, скорее, следует переводить как “дружелюбный” или “обходительный”. Но и эти эпитеты применимы к случайно встреченному на дороге путнику или продавцу в магазине, пытающемуся вам что-то впарить. То есть к кому-то, кто преследует свой собственный интерес.

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

Программы не более чем орудия. Вспомним, кого в старину называли говорящими орудиями? Правильно – рабов. Вот истинное место программы по отношению к человеку. Хороший интерфейс должен быть не дружественным, рабским. Никакого вам панибратства и похлопывания по плечу. “Чего изволите, хозяин?”, “Будет исполнено, хозяин”, – и больше никаких разговоров, если не случилось чего-то, действительно заслуживающего внимания.

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

Заметим, “дружественные” программы обычно “вопят” о проблемах на всю систему, выкидывая модальный диалог, который не дает вам сделать ничего, пока вы на него не отреагируете. Совершенно не так себя ведут командно-строчные утилиты – если вы работаете в оконной среде, сообщение будет лежать в том окне, где вы запустили программу, пока вы, хозяин, не соизволите обратить внимание на неудачливого раба.

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

Еще один недостаток “дружественного” интерфейса – восприятие разработчиками интерфейса пользователя как чего-то совершенно особенного. А между тем, еще тридцать лет назад был сформулирован принцип: “Если тебе лень читать вывод программы, заставь это делать другую программу”. Олицетворение данного принципа – программы yes и grep, входящие в состав любой стандартной системы. Первая из них занимается тем, что генерирует бесконечное число ответов “да” на любые вопросы, задаваемые программой, в которую направлен вывод yes. Таким образом, пользователю очень легко избавиться от монотонного сидения за экраном и нажатия Enter на каждый вновь появившийся вопрос. Монотонная работа не для хозяина, ее нужно поручить рабам.

Программа grep (и ее варианты egrep и agrep) выполняет строго противоположную функцию – читает вывод какой-нибудь другой программы и выбирает из него интересные хозяину строки. Нечто вроде секретаря-референта. Причем секретаря довольно продвинутого – ей можно указать достаточно гибкие шаблоны для поиска, воспользовавшись так называемыми регулярными выражениями, и можно потребовать достаточно разнообразного представления результатов: только количество найденных выражений; только имена файлов; строки с найденными образцами; строки с парой-тройкой соседних.

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

Формулировка способа решения задачи словами: “Прочитать почтовый ящик, выбрать из него все строки, начинающиеся со слова Subject:, отсортировать в алфавитном порядке, удалив дубликаты” превращается в команду cat mbox |grep ^Subject: |sort|uniq.

(Не знакомого с языком оболочки ОС такая строка может напугать, однако она – лишь формальный эквивалент приведенной формулировки. Команды cat, grep, sort и uniq – эквиваленты глаголов “прочитать”, “искать”, “сортировать” и “удалять дубликаты”, соответственно, соединенные символом |, обозначающим в большинстве оболочек перенаправление вывода на ввод следующей команды (программы). Глаголы “прочитать” и “искать” требуют для определенности дополнения, так что соответствующим командам передаются параметры mbox (имя файла, который следует читать) и ^Subject: (строка, которую следует искать).

Фактически, так оно и есть. Набор команд, которыми вы оперируете, – это язык, с помощью которого вы даете команды машине. Для Киплинга, писателя, верными слугами были обычные слова английского языка. Для пользователя компьютера слугами являются команды операционной системы.

То, что в системе тысячи команд (мне на моем скромном ноутбуке в данный момент доступен 1411 исполняемый файл), не должно вас смущать. В русском языке сотни тысяч слов, а героиня Ильфа и Петрова Эллочка-Людоедка вполне обходилась в повседневной жизни тридцатью. Примерно так же распределяется и частота использования команд операционной системы.

Обратите внимание, что в мире “дружественных интерфейсов” более распространено понимание программы как вещи, которую можно сделать, продать, купить, использовать, а не как слова в языке общения человека с машиной. Такое понимание, без сомнения, выгодно производителям программного обеспечения. Ведь любая, даже самая топорная вещь имеет свою цену. А вот платить за слова мы согласны только, если эти слова достаточно талантливы. С другой стороны, мало кто будет самостоятельно изготовлять себе мебель или радиоприемник. Предпочтут купить. А сформулировать достаточно простую мысль словами способен любой грамотный человек.

Поэтому индустрии программного обеспечения выгодно превратить пользователей компьютеров в потребителей программ. А вот выгодно ли пользователю? Представьте себе охотничьего сокола, приученного брать кусочки мяса из рук человека. Он вполне способен догнать и убить зайца, но не знает, что этого зайца можно тут же немедленно съесть. Он отдает зайца человеку и довольствуется тем мясом, которым человек сочтет нужным с ним поделиться. Примерно в таком же положении находится большинство пользователей компьютеров – они способны сформулировать свою задачу (догнать зайца) и даже знают, как ее решить (убить зайца). Но вот “содрать с зайца шкуру и съесть” – превратить свою формулировку в набор приказов машине – они не могут. В результате львиная доля “зайчатины” достается производителям программного обеспечения.

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

Это происходит потому, что основная черта компьютерного “вещизма” – непонимание, что имеющиеся у тебя программы следует знать. Если возникла иная задача, покупают или выискивают в Сети новый инструмент. Метафора программ-слов способствует другому подходу – попытаться сформулировать задачу с помощью уже известных тебе (и твоей машине) слов. Благо, результат этой формулировки всегда можно обозвать одним новым словом.

Собственно, движение свободного программного обеспечения возникло как противовес данной тенденции. Когда появилась индустрия программного обеспечения, многие обратили внимание, что эта “индустрия” норовит лишить пользователей компьютеров власти над ними. А Ричард Столлмен не только обратил внимание, но и сформулировал стратегию борьбы – манифест ГНУ.

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

Очевидно, что принять активное участие в этом движении могут только люди, умеющие создавать новые программы. Поэтому инструментальные программы – программы, решающие задачи, полезные программистам, как правило, появляются быстрее, чем программы, решающие задачи конечного пользователя-непрограммиста. Так, например, компилятор GNU C появился десятилетием раньше, чем графический редактор GIMP.

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

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

© 2002, Издательский дом “КОМПЬЮТЕРРА” | http://www.computerra.ru/
Журнал “Домашний компьютер” | http://www.homepc.ru/
Этот материал Вы всегда сможете найти по его постоянному адресу: http://www.homepc.ru/offline/2002/78/22451/

Медиа: image / jpeg

Ниже представлено краткое руководство пользователя по быстрой установке и настройке маршрутизатора на базе OS Wive-NG.

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

1. Руководство по установке
   1. Установка встраиваемой OS Wive-NG
      

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

   2. Подключение маршрутизатора с предустановленной OS Wive-NG
      

      1. Подключите персональный компьютер, с которого будет осуществляться настройка, в один из свободных LAN портов маршрутизатора. Если Ethernet-порт на ПК отсутствует, можно воспользоваться подключением по Wi-fi (не рекомендуется для загрузки обновлений ПО).

      2. Подключите кабель от Интернет-провайдера в WAN порт маршрутизатора, если таковой имеется и предусмотрен топологией Вашей сети.

      3. Подключите маршрутизатор к сети 220V адаптером из комплекта поставки (не рекомендуется использовать сторонний адаптер и/или адаптер с номиналом, отличным от штатного).

   3. Настройка рабочего места (ПК)
      

      По умолчанию IP адрес маршрутизатора 192.168.1.1 с маской подсети 255.255.255.0.
      Для того, чтобы компьютер получил сетевые реквизиты от маршрутизатора автоматически, необходимо включить опцию «Получить IP-адрес автоматически» в настройках сетевого подключения ПК (в ОС Windows данную настройку можно произвести, нажав на подключение по локальной сети правой кнопкой мыши, выбрав Свойства, а в открывшемся окне – Протокол Интернета версии 4 (TCP/IPv4)).
      

   4. Подключение к web-интерфейсу маршрутизатора на базе OS Wive-NG
      

      Для настройки маршрутизатора через WEB интерфейс Вы можете использовать один из доступных интернет-браузеров: Chrome, Opera, Mozilla Firefox, Internet Explorer, Safari и др.
      Для доступа к интерфейсу управления маршрутизатором откройте веб-браузер и в адресной строке введите адрес 192.168.1.1 http://192.168.1.1, нажмите Enter. Появится окно входа в систему с предложением ввести Логин и Пароль.
      

      

      Авторизация в web-интерфейсе wive-ng

      Логин и пароль по умолчанию: Admin /Admin (с большой буквы).
      Для удобства пользователя, предлагается выбрать русский язык интерфейса. Для этого на открывшейся странице необходимо указать Russian в разделе Select Language, и затем нажать Apply:
      

      

      Выбор русского языка в web-интерфейсе Wive-ng

   5. Обновление встраиваемой OS Wive-NG
      

      При первом включении устройства желательно произвести обновление ПО, чтобы не пропустить критичные правки и новый функционал, добавленные в ПО после производства устройства на заводе.
      Проверить наличие новой версии ПО можно по ссылке: https://sourceforge.net/projects/wive-ng/files/
      Необходимо выбрать файл, соответствующий Вашей аппаратной платформе. В настоящий момент официально поддерживаемой является ветка Wive-NG-mt. Для обновления необходимо использовать именно тот файл, имя которого соответствует Вашей модели устройства (информация о модели скорее всего содержится на стикере, расположенном на нижней части устройства). Например, если Вы используете гигабитный двухдиапазонный маршрутизатор SNR-CPE-ME1, то необходимо выбрать файл, имя которого начинается с SNR-CPE-ME1 (1).
      

      

      Выбор версии прошивки для обновления ПО wive-ng

      Помимо модели устройства, наименование файла содержит версию ПО (2) и дату релиза (3). Чтобы узнать текущую установленную версию, необходимо войти в раздел Администрирование -> Статус, либо воспользоваться быстрым переходом к Статусу (4) со стартовой страницы маршрутизатора (ссылка расположена под блоком выбора языка). В блоке Информация о системе указана Версия ПО.
      

      

      Статус маршрутизатора и текущая версия ПО Wive-NG

      Важно: ПО будет скачено на Ваш ПК в виде .zip архива. Необходимо извлечь .bin файл прошивки, сделать это можно с помощью любого установленного на Ваш ПК архиватора.
      

      Для загрузки новой версии ПО на маршрутизатор необходимо войти в раздел Администрирование -> Управление web-интерфейса маршрутизатора. Также, можно воспользоваться быстрым переходом со стартовой страницы, нажав Управление (5) (ссылка расположена под блоком выбора языка). В блоке Обновление прошивки выбрать на ПК ранее скаченный .bin файл, нажать Обновить.

      

      Стартовая страница маршрутизатора Wive-ng

      

      Обновление ПО Wive-NG

      После нажатия Обновить, на экране появится служебное сообщение и таймер, ведущий отсчет до окончания процесса обновления ПО.

      

      Счетчик обновления ПО Wive-NG

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

2. Руководство пользователя по быстрой настройке
   Важно: по завершении настроек на каждой странице, не забывайте нажать «Применить» для подтверждения и применения внесенных изменений.
   1. Изменение реквизитов по умолчанию
      

      Встраиваемая OS Wive-NG сигнализирует, если используются реквизиты по умолчанию для доступа к интерфейсу управления и/или беспроводной сети, а также — если шифрование Wi-fi сети полностью отсутствует.
      

      

      Оповещение о необходимости изменить реквизиты по умолчанию

      Кнопки «Перейти» позволяют совершить быстрый переход к соответствующим блокам настроек. После смены либо установки реквизитов оповещения будут скрыты.

   2. Настройка интернет соединения
      

      Для работы в сети оператора связи необходимо произвести настройки в соответствии с данными, указанными в договоре с интернет-провайдером. Чтоб начать настройку, необходимо перейти в раздел Настройки сети – Настройки WAN и выбрать Тип подключения WAN в зависимости от технологии предоставления услуги:

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

      – STATIC(фиксированный IP), если Ваш провайдер использует статическую адресацию для работы в сети и не использует DHCP. Необходимо указать IP address (IP адрес), Subnet Mask (Маска подсети), Default Gateway (Шлюз по умолчанию) в соответствии с договором.

      – Zeroconf(без настройки) — если Ваш провайдер для работы в сети использует только VPN подключение. Указание дополнительных параметров не требуется.
      

      

      Настройки WAN подключения

      В блоке Дополнительные настройки необходимо указать адреса DNS серверов либо снять флаг Назначить статические сервера DNS для автоматического получения адресов DNS от провайдера (доступно только для типа подключения DHCP).
      Статическое назначение DNS серверов допускает два варианта:
      – Вручную, в этом случае необходимо ввести адреса DNS серверов, указанные в договоре с интернет-провайдером:
      

      

      Настройка статических DNS

      – Выбор одного из доступных профилей облачных DNS сервисов (Яндекс, Google, SkyDNS и т. д.):
      

      

      Выбор профиля сервиса DNS

   3. Настройка VPN
      

      Если оператор предоставляет услугу с использованием VPN, то произвести соответствующие настройки можно в разделе Настройки сети – Настройки VPN. Для запуска службы необходимо взвести флаг Включить VPN. Далее в соответствии с договором необходимо выбрать Режим VPN (PPPoE, PPTP, L2TP) и ввести указанные в договоре данные.
      Важно: если оператор использует PPPoE не в связке PPPoE+IPoE (DHCP), необходимо указать «Чистый PPPoE».
      При нажатии Применить и подключить, соединение будет установлено
      

      

      Настройки VPN в Wive-NG

   4. Настройка IPv6
      

      Если Ваш интернет-провайдер предоставляет доступ по IPv6, соответствующие параметры можно настроить в разделе Настройки сети – Настройки IPv6. В зависимости от схемы предоставления услуги оператором, необходимо выбрать Режим работы IPv6:

      – Туннель 6to4 с указанием Адрес сервера в блоке Настройка туннеля 6to4:
      

      

      Настройка IPv6to4

      – Прямое динамическое или статическое подключение
      По аналогии с Настройкой WAN, необходимо взвести флаг Автоматическая настройка IPv6 через DHCP/RA, если оператор автоматически отдает сетевые реквизиты по DHCP, либо снять флаг и вручную вести IPv6 реквизиты, указанные в договоре, в блок Настройка статического IP:
      

      

      Настройка статических IPv6

      Конфигурацию работы IPv6 в локальной сети можно произвести в блоке Сервисы IPv6 для локальной сети.

   5. Беспроводная сеть. Создание беспроводной сети

      Встраиваемая OS Wive-NG предназначена для работы как однодиапазонных (2,4ГГц) , так и двухдиапазонных (2,4ГГц + 5ГГц) wi-fi устройств. При настройке устройств, работающих на частоте 2,4ГГц без поддержки 5ГГц, параметры 5ГГц не отображаются в web-интерфейсе.
      

      Для создания и базовой настройки wi-fi необходимо перейти в раздел Настройки радио – Основные:
      

      

      Включение и базовая конфигурация wi-fi в Wive-NG

      Базовая настройка включает два этапа:

   6. Физическое включение и настройка режима работы радиомодуля.
      

      Для начала работы необходимо включить (1) необходимый радиомодуль в блоках настройки Беспроводная сеть 2.4ГГц и Беспроводная сеть 5ГГц (если доступен). На двухдиапазонных устройствах возможна работа как одного, так и обоих радиомодулей одновременно.
      Канал (2,4ГГц / 5ГГц) — конкретная частота, на которой будет работать радиомодуль (2). Можно воспользоваться автовыбором либо указать канал вручную, выбрав один из менее загруженных. Используйте сканирование (3) для определения загрузки радиоэфира.
      

      

      Скан эфира wi-fi сетей

      Важно: некоторые клиентские устройства (смартфоны, ноутбуки и т. д.) могут некорректно работать на верхних каналах диапазонов (12-14 в 2,4ГГц, 132-165 в 5ГГц). При обнаружении проблемы с подключением одного устройства на фоне беспроблемной работы wi-fi сети в целом, рекомендуется попробовать использовать канал из середины диапазона.

      Важно: Некоторые клиентские устройства (смартфоны, ноутбуки и т.д.) некорректно работают с шириной канала 80МГц. В случае возникновения проблем с одним устройством на фоне корректной работы остальных, попробуйте изменить Ширину канала (5GHz) на 20/40MHz в блоке Расширенные настройки Wi-Fi
      

      

      Настройка ширины канала wi-fi

   7. Настройка SSID и безопасности wi-fi сетиДля создания сетей wi-fi, к которым будут подключаться клиентские устройства, необходимо указать Имя сети (2,4ГГц / 5ГГц) (1) в блоке Настройки радио -> Основные -> Настройки SSID. В этом же разделе доступны настройки изоляции беспроводных клиентов и SSID.
      Важно: Для двухдиапазонных устройств SSID могут быть как одинаковые, так и разные. Однако, если Вы планируете использовать Band Steering, то необходимо указать одинаковые SSID
      

      Настройка безопасности wi-fi сети

      Следующим этапом необходимо настроить параметры безопасности беспроводных сетей. В разделе Настройки радио -> Основные -> Политики безопасности необходимо выбрать Ваш SSID (2) (в случае нескольких созданных SSID, т.е при использовании режима MBSSID, указывается SSID, который Вы планируете настраивать прямо сейчас) и указать режим безопасности (3). В следующем блоке Настройки радио -> Основные -> WPA указать WPA алгоритм (алгоритм шифрования) (4). Мы рекомендуем использовать Режим безопасности – WPA2-PSK в связке с WPA алгоритмом AES, как наиболее безопасный на сегодняшний день.
      Важно: Смешанные режимы допустимы лишь при наличии клиентов, не поддерживающих WPA2 / AES.
      В качестве ключевой фразы (пароля для подключения к wi-fi сети) (5) рекомендуется использовать криптостойкие комбинации длиной более 8 символов, включающие цифры и буквы различных регистров, не содержащие словарных слов. Если Вы забыли пароль, его можно отобразить, взведя соответствующий флаг (6).

      

      Подтверждение автоматического включения WPA2-PSK на маршрутизаторе

      При первом включении, либо при не оптимальных параметрах безопасности, система предложит включить WPA2-PSK как рекомендованный режим. Для автоматического применения оптимальных настроек достаточно нажать ОК. При необходимости, данные настройки можно будет осуществить позже вручную.

   8. Мониторинг подключенных устройств
      Чтобы посмотреть перечень устройств, подключенных к wi-fi сети, включая технические данные о режиме подключения клиентского устройства, необходимо перейти в раздел Настройки радио -> Активные подключения. Для простоты восприятия клиенты, работающие на частоте 5.ГГц отображены в зеленом цвете; клиенты, работающие на частоте 2,4ГГц — в синем:
      
      

      Список устройств, подключенных к wi-fi сети

      Для просмотра доступно два режима (1) — Базовый и Расширенный, отличающиеся набором отображаемых данных. Для построения графического отображения данных по клиентам (трафик, уровень сигнала и т. д.) необходимо взвести флаг (2) напротив нужного клиента, либо общий на всех клиентов.
      График будет построен в нижней части окна. Для удобства можно указать:
      – Тип графика: анализируемый тип данных (скорость приема и/или передачи, суммарная скорость, уровень сигнала, качество сигнала, номинальная скорость подключения)
      – Время графика: от 1 минуты до 6 часов, либо за всё время.
      – Единицы измерения: Мбит/с или Кбит/с

      

      Графическое отображение статистических данных wi-fi клиентов

   9. Настройка IP–TV
      

      Блок настроек Сервисы IPTV расположен в разделе Сервисы -> Разное. Для просмотра iptv по технологии мультикаст рекомендуется произвести следующие настройки:
      IGMP прокси – Включить (1)
      Поддержка IGMP snooping — Автоматически (2)
      Преобразование мультикаста в уникаст — WLAN (3)
      Если Вы используете IPTV приставку (STB) или мультимедиа плеер с поддержкой HTTP Proxy (например, vlc), то для повышения качества работы рекомендуется настроить Преобразование мультикаста в http — LAN (4). В целях безопасности не рекомендуется использовать значение, включающее WAN.
      Необходимо обратить внимание, что в настройках роутера и приставки/плеера должен быть указан один и тот же порт UDPXY (5). По умолчанию указан 81 порт.
      

      

      Настройки параметров iptv в Wive-NG

      Если провайдер предоставляет m3u плейлист, его можно загрузить на маршрутизатор, используя DLNA медиа сервер xUPNPd (6) для просмотра iptv без использования STB на устройствах, не поддерживающих технологию Multicast. Подробная инструкция доступна по ссылке

Полная версия руководства в формате PDF:

Загрузка...

Слишком долго?

Перезагрузить документ

| Открыть в новой вкладке

Сохранить [1.01 MB]

Медиа: image / jpeg

В предыдущей статье был рассмотрен проброс портов и всё, что с ним связано. Теперь остановимся на фильтрации трафика (раздел Сетевой Экран / Firewall web-интерфейса) — как транзитного, так и обращенного к локальным сервисам маршрутизатора.

1. Настройки фильтрации транзитного трафика
Данный блок позволяет создать набор правил, регламентирующих (как запрещающих, так и разрешающих) прохождение трафика через маршрутизатор из глобальной сети в сторону клиентов и наоборот. Фильтрация может осуществляться по MAC адресам устройств, подключенных к роутеру, IP адресам устройств и внешних ресурсов, а также портам.
Чтобы начать работать с фильтрами, необходимо:

• Включить фильтрацию (по умолчанию опция отключена).
• Определиться, что будет происходить со всеми соединениями, не попадающими под правила. Варианта два: либо они пропускаются , либо блокируются. Грубо говоря, понять, какая задача стоит: разрешить доступ лишь к определенным ресурсам и определенному кругу лиц, а всё остальное — запретить; или напротив — в общем случае разрешать любые соединения всем пользователям, за определенными исключениями, оформленными в правила.

Включение фильтрации транзитного трафика на роутере

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

1. Интерфейс, на который поступил трафик, обрабатываемый правилом. Если цель — фильтровать соединения, инициированные пользователями локальной сети, необходимо указать LAN, в случае соединений извне — WAN либо VPN в зависимости от типа подключения роутера к операторской сети.
2. Протокол, на который будет распространяться правило. По умолчанию значение None, т.е любой трафик без уточнения. Но возможен выбор : TCP, UDP или ICMP.
3. Если фильтрация осуществляется по MAC адресу источника соединения, то необходимо его указать.
4. Также доступен вариант фильтрации по IP адресу источника соединения (как единственному, так и подсети).
5. Порт, с которого производится соединение. Для ICMP протокола это поле недоступно.
6. IP адрес назначения, т.е IP адрес, к которому устанавливается соединение. Это может быть как один адрес, так и подсеть.
7. Порт назначения, на который производится соединение. Для ICMP протокола это поле недоступно.
8. Политика, т.е определение того, что будет происходить с соединениями, попадающими под правило. Варианта два: правило может быть либо запрещающим, либо разрешающим.
9. Комментарий в свободнонй форме, позволяющий не держать в голове, какое правило и зачем было создано.
10. Действие, а именно — что вы хотите сделать с правилом: добавить (новое) либо удалить (уже существующее).

Настройка фильтрации трафика (firewall) на роутере

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

Интерфейс= LAN;
Протокол= ICMP;
MAC не указан;
IP источника (src)= 192.168.1.124, Маска не указана;
Порт ист. (src) / Порт назн. (dst) недоступны;
IP назначения (dst)= 8.8.8.8, Маска не указана;
Политика= Запретить;

приводит к тому, что мы теряем возможность пинговать адрес 8.8.8.8 (google dns) с устройства в локальной сети, расположенного по адресу 192.168.1.124 . К такому же результату приведет правило, в котором не будет указан IP источника, но будет указан MAC адрес этого устройства.

— Правила для LAN

Правила, созданные для интерфейса LAN, подразумевают, что в качестве источника выступает устройство, находящееся в локальной сети (т.е, инспектируемый трафик пришел на LAN интерфейс). Т.о, в качестве src (исходящего) IP будут выступать локальные IP адреса устройств , а src (исх) портами будут являться порты, с которых улетает пакет в сторону интерфейса LAN с локальных устройств.

Если необходимо ограничить доступ к определенным web-ресурсам пользователю или группе пользователей, то в IP источника (src) необходимо указать IP адрес пользователя, либо, если речь о группе, — маску, которая будет в себе содержать диапазон адресов пользователей, которых мы ограничиваем. В IP назначения (dst) необходимо будет указать адреса запрещаемого ресурса, также можно указать порты, соответствующие сервисам, которые стоит цель ограничить (например, стандартные 80, 8080 – http и 443 — https) — в случае, если заблокировать необходимо лишь часть сервисов, но не адрес целиком.
Важно: необходимо помнить, что одному доменному имени может соответствовать несколько IP адресов, а также — ограничиваемый сервис может быть доступен через не стандартные порты. Для определения IP адресов, соответствующих доменному имени, можно воспользоваться утилитой nslookup:

Вывод nslookup

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

Если же стоит задача ограничить свободу пользователя до определенного набора разрешеных ресурсов и сервисов, то необходимо выбрать значение «Блокированы» для параметра «пакеты, которые не подходят ни под одно правило, будут:» (т.е, политика по умолчанию – запрещающая). В IP и портах назначения (dst) указываются данные (адреса/подсети и порты) тех ресурсов, которые должны быть доступны. Что касается IP адресов источников (src), то их можно не указывать вообще (тогда правило распространится на всех пользователей, работающих в локальной сети маршрутизатора), либо указать конкретный IP адрес, на который действует разрешающее правило (в этом случае, на всех, для кого не создано такое правило, по умолчанию будет действовать запрещающая политика на любую активность). Либо же — указать подсеть, если правило создается для группы пользователей (по аналогии с указанием одного адреса, на всех, кто не попал в подсеть, будет действовать общая запрещающая политика).

Важно: если необходимо создать идентичные правила для нескольких IP адресов, то можно ограничиться одним правилом, если все адреса находятся в одной подсети. Например, указанный адрес 192.168.1.1 и маска 255.255.255.240 будут означать, что правило распространяется на адреса из диапазона 192.168.1.1-192.168.1.14. Если же невозможно объединить адреса, для которых распространяется правило, в подсеть, необходимо создавать несколько дублирующих правил для каждого IP-адреса.

— Правила для WAN / VPN

Правила, созданные для WAN или VPN интерфейса, регулируют политику относительно входящего трафика в сторону маршрутизатора из внешней сети.

Например, создавая запрещающее правило для интерфейса WAN, в котором выбран протокол TCP, указан исходящий адрес 217.118.91.73 и порт 433, мы подразумеваем, что все соединения в сторону маршрутизатора, устанавливаемые со стороны 217.118.91.73:433, будут отброшены (в том случае, если мы точно знаем, с какого порта будет устанавливаться соединение).

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

Пример:

Запрещающее правило фильтрации транзитного трафика

Данное правило будет означать, что вне зависимости от исходящего адреса в глобальной сети, соединения, назначением которых является 80 порт устройства, проживающего по адресу 192.168.1.124, будут отброшены. В предыдущей статье мы настраивали проброс портов с WAN / 8888 на 192.168.1.124:80, таким образом отбрасываться будут соединения , устанавливаемые на 8888 порт глобального адреса маршрутизатора.

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

Создание двух противоречащих друг другу правил Firewall

первое из них разрешает доступ к web интерфейсу 192.168.1.124 с внешнего IP адреса 217.118.91.73, второе — запрещает все без исключения соединения извне. Таким образом, если мы с адреса 217.118.91.73 обратимся на http://my_ip:8888 (в предыдущей статье мы настроили проброс портов следующим образом: при обращении по адресу http://Ваш_IP_адрес:8888 либо http://Ваш_Домен:8888 весь TCP трафик будет перенаправляться на устройство, имеющее IP адрес 192.168.1.124 в Вашей локальной сети, а именно — на 80 порт), то на соединение распространится первое в списке правило (разрешающее) , и соединение будет установлено. Если же поменять правила местами, т.е , первым в списке сделать правило, запрещающее все соединения к 80 порту 192.168.1.124, то соединение с 217.118.91.73 будет отклонено , попросту не дойдя до разрешающего правила, под которое попадает.

2. Подключение к локальным сервисам

Для лимитирования доступа к локальным сервисам самого маршрутизатора (не транзитного трафика!) выделен блок настроек «Подключение к локальным сервисам». По умолчанию сервис выключен. Для включения необходимо перейти в Сетевой экран -> Сетевой экран -> Подключение к локальным сервисам -> Разрешить подключение -> Включить.

Включение фильтрации трафика, обращенного к локальным сервисам маршрутизатора

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

По аналогии с правилами для транзитного трафика необходимо указать данные:

1. Интерфейс, со стороны которого устанавливается соединение, которое необходимо разрешить. WAN, VPN или LAN.
2. Протокол, на который будет распространяться правило. По умолчанию значение None, т.е любой трафик без уточнения. Но возможен выбор : TCP, UDP или ICMP.
3. MAC адрес источника соединения.
4. IP адрес, с которого устанавливается соединение.
5. Подсеть, с которой устанавливается соединение.
6. Порт, с которого производится соединение (src / ист). Для ICMP протокола это поле недоступно.
7. Порт, на который устанавливается соединение (dst / назн). Для ICMP протокола это поле недоступно.
8. Комментарий в свободнонй форме.
9. Действие, а именно — что вы хотите сделать с правилом: добавить (новое) либо удалить (уже существующее).

Настройка правил подключения к локальным сервисам

Пример:
На маршрутизаторе запущен UDP Proxy (udpxy) на 81 порту. С целью обеспечения безопасности, соединение разрешено только со стороны LAN.

Включение UDPXY на роутере

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

Правило, регулирующее доступ к локальному сервису маршрутизатора udpxy

Созданное правило означает, что соединения, устанавливаемые с WAN с IP адреса 217.118.91.120 на 81 порт маршрутизатора не будут отклоняться, несмотря на то, что в общем случае, политика доступа к udpxy на 81 порт доступны только для LAN интерфейса. Т.е, клиент находящийся на указанном IP-адресе сможет в порядке исключения пользоваться сервисом.

Важно: данный блок в частности призван управлять разрешениями доступа для сервисов, установленных из Entware, т.к по умолчанию все они имеют политику drop без каких-либо разрешающих правил и исключений. Следовательно, для сервисов из entware всегда необходимо создавать правила доступа, в противном случае доступ по умолчанию будет закрыт.

Медиа: image / png

В данной статье рассмотрим всё, что связано с Port Forward (проброс портов) – автоматически и вручную.

Часто, помимо обеспечения доступа в интернет пользователям, подключенным к маршрутизатору, возникают такие задачи как:
– прозрачный доступ к какому-либо устройству или сервису, находящемуся в локальной сети
– фильтрация входящих или исходящих соединений с целью ограничить посещение тех или иных ресурсов, работу сервисов, и другие несанкционированные активности.

Для этих целей в ПО Wive-NG предусмотрен блок настроек , именуемый Firewall (Сетевой Экран).

По сути, раздел веб-интерфейса Firewall (Сетевой Экран) — это не что иное, как GUI, позволяющий создавать правила iptables, не прибегая к консоли. Разумеется, последний вариант (консоль) позволяет осуществить более гибкую настройку политик разрешений и запретов, и если есть такая возможность, то лучше «подружиться» с iptables (тем более, что это штатное средство unix-систем, и понимание логики его работы будет применимо и к работе с другими unix-based устройствами). Однако, базовые пользовательские задачи вполне решаются посредством web.

1. Настройки проброса портов (Port Forwarding).

Иногда нам необходимо организовать удаленный доступ к устройству, находящемуся в локальной сети, по тому или иному протоколу. К примеру, доступ к web-интерфейсу IP телефона (по умолчанию, порт 80), или же работу с удаленным рабочим столом по протоколу RDP (по умолчанию порт в Windows 3389). Также, может возникнуть задача обеспечения функционирования сервиса, запущенного в локальной сети, который ведет прием и передачу данных по конкретному диапазону равнозначных портов (к примеру, SIP сервер, или же раздача контента посредством torrent клиента).

Но с точки зрения того, кто находится в глобальной сети, все эти устройства имеют один и тот же IP адрес (либо доменное имя). Именно тут на помощь приходит проброс портов (port forward).

Включение проброса портов (port forward)

Для включения сервиса необходимо обратиться к пунктам меню:
Сетевой экран (Firewall) -> Сетевой экран (Firewall) -> Настройка проброса портов (Port Forwarding), и включить сервис.

Настройка проброса портов через web интерфейс достаточно проста , и состоит из следующих шагов:

1. Выбор интерфейса, для которого дейстует правило. По умолчанию это WAN, но если Ваш оператор использует VPN, то следует указывать его.
2. Протокол. Возможные варианты: TCP (например , доступ к web), UDP (например, работа VoIP ). Также доступен вариант выбора обоих TCP и UDP . Данный вариант стоит использовать только в случае, если целевой сервис использует и TCP и UDP (например, torrent). Во всех остальных случаях (например, Вы точно не уверены нужно ли TCP или же UDP) рекомендуется ознакомиться с документацией, выяснить, какой протокол используется и указать нужный, дабы избежать бреши в безопасности и эксплуатации ее троянами.
3. Порты, на которые будет производиться обращение извне, для переадресации на нужное устройство / сервис, для которого создается правило. Т.е, по сути, то, за счёт чего маршрутизатор поймет, к чему именно в локальной сети Вы обращаетесь. Можно указать как один порт, так и диапазон.
4. IP адрес в локальной сети, соответствующий устройству, к которому Вы обращаетесь.
5. Порты, которые соответствует необходимому сервису на самом устройстве в локальной сети, к которому происходит обращение.
Важно: рекомендуется использовать одинаковые порты dst и src, т.к данная схема снижает нагрузку на CPU и гарантирует корректрую работу программного и аппаратного offload.
6. NAT loopback — т.е, будет ли работать доступ при обращении на глобальный адрес и src порт из локальной сети. Важно: корректная работа NAT loopback (в силу того, что по сути это грязный хак на уровне нетфильтра с подменой адресов на лету на уровне фаервола) зависит от множества факторов, включая операционную систему, src/dst порты на клиенте и сервере, а так же частично несовместима с software offload и т. д. Поэтому установленное положительное значение не является гарантией корректной работы данной службы. Так же в некоторых случаях для корректной работы NAT Loopback, может потребоваться отключение программного оффлоада, что приведёт к снижению производительности.
Рекомендуется вместо использования NAT loopback в настройках DNS добавить локальные DNS записи для ваших серверов с локальными же именами и использовать их для обращения к серверам внутри сети. Это гораздо более верное со всех точек зрение решение.
7. Комментарий в свободнонй форме, позволяющий не держать в голове, какое правило и зачем Вы создавали.
8. Действие, а именно — что вы хотите сделать с правилом: добавить (новое) либо удалить (уже существующее).

Важно: После завершения работы с правилами (добавление , удаление) необходимо нажать Применить / Apply, в противном случае все добавленные правила не будут сохранены. Добавление правила (нажатие Добавить / Add) в ходе редактирования таблицы port forwarding само по себе не является мгновенной записью созданного правила в конфигурацию роутера, а лишь предварительно сохраняет его на странице.

Настройка проброса портов (Port forward) на роутере

Например, правило вида:

Interface (Интерфейс)= WAN,
Protocol (Протокол)= TCP,
Src Ports (Порт ист.)= 8888,
Dst IP (IP назначения)= 192.168.1.124,
Dst Ports (Порт назн.)= 80,
Comment (Комментарий)= ‘IP Phone’

будет означать, что при обращении по адресу http://Ваш_IP_адрес:8888 либо http://Ваш_Домен:8888 весь TCP трафик будет перенаправляться на устройство, имеющее IP адрес 192.168.1.124 в Вашей локальной сети, а именно — на 80 порт.

А правило вида

TCP&UDP / 3389 / 192.168.1.150 / 3389 / ‘RDP’

гласит о том, что в Вашей сети есть ПК, живущий на IP адресе 192.168.1.150, к удаленному рабочему столу на котором Вы подключитесь, сказав “http://Ваш_Домен:3389” (т.к в примере выбран интерфейс VPN, то судя по всему, указать статический IP просто невозможно — для решения этой проблемы можно воспользоваться аккаунтом на одном из DynDNS сервисов (такая возможность также доступна штатно в ПО Wive-NG).

Настройка Dynamic DNS

Важно: необходимо удостовериться в следующих моментах:
-указываемый Вами порт назначения (dst) действительно настроен на целевом устройстве для необходимого сервиса.
-доступ по указанному порту доступен с WAN на устройстве (если настраиваемый роутер является шлюзом для целевого устройства), и в целом доступ извне не блокируется локальным firewall.
Например, в настройках IP телефона из примера необходимо проверить две вещи: порт доступа к web / http= 80 , доступ к web / http разрешен для wan интерфейса всем, либо как минимум конкретному хосту роутера.

Важно: правило не будет работать, если IP адрес целевого устройства в локальной сети изменится. Для исключения такой возможности, есть два варианта:
1. Настройка статического адреса сетевого интерфейса на целевом устройстве. Т.е, отказ от получения IP адреса от DHCP сервера роутера .
2. Закрепление IP адреса, выдаваемого DHCP сервером роутера, за MAC адресом конкретного устройства. Осуществить это можно , зайдя в раздел меню Сервисы -> Сервер DHCP и создав новую пару MAC — IP с соответствующим комментарием. Если в текущий момент времени устройство имеет активную аренду IP адреса от DHCP сервера роутера, то его текущий выданный IP , а также MAC можно будет увидеть на этой же странице в соответствующем списке.

Настройка статической пары MAC-IP на DHCP сервере роутера

Если же Вам необходимо пробросить диапазон портов, необходимо учесть следующее:
1. Стоит по возможности избегать проброса с разными портами src/dst, т.к при использовании комплексных протоколов обслуживаемых ALG (FTP/RTSP/SIP/PPTP/L2TP etc) т.к., могут возникать разночтения.
2. Ширина диапазонов src и dst портов должна совпадать.
3. Порты должны быть равнозначны. Т.е, работа сервиса не должна зависеть от конкретного выбранного порта из диапазона. Такими случаями, например, являются: data порты FTP сервера, порты для передачи голоса SIP сервера, порты раздачи torrent, и т.д.
4. Если необходимо настроить NETMAP, т.е проброс 1:1 (фиксированные пары src и dst портов диапазона), то необходимо каждую пару создавать отдельным правилом. В общем случае при указании диапазона соединение осуществляется на первый доступный порт для которого в conntrack отсутствует запись.

Уже созданные правила проброса портов можно проверить в консоли в Chain FORWARD, скомандовав iptables -L -v -n -t nat . Необходимо помнить, что для получения корректных данных счетчиков (например, в диагностических целях), весь возможный offload должен быть отключен, иначе большая часть трафика в счетчик не попадет. Разумеется, если такой цели не стоит, offload использовать можно и нужно.

2. Пара слов про UPNP

На сегодняшний день многие приложения, включая torrent-клиенты, умеют UPNP IGD (Universal Plug and Play Internet Gateway Device), что позволяет не пробрасывать порты вручную для этих приложений, а воспользоваться автоматичесим пробросом. OS Wive-NG также поддерживает эту возможность. Основным условием является включение UPNP как на роутере, так и в настройках клиента.
Включить UPNP можно в блоке настроек Сервисы -> Разное -> Сервис

Включение UPNP на роутере

3. Пара слов про настройки ALG (Шлюз прикладного уровня)

ALG (Application Layer Gateway, Шлюз прикладного уровня) анализирует проходящий трафик, распознаёт конкретные протоколы и осуществляет ретрансляцию на стандартный порт, соответствующий протоколу. Это позволяет нескольким клиентским устройствам, находящимся за NAT (т.е, в локальной сети маршрутизатора) одновременно и беспрепятственно вести обмен трафиком ряда прикладных протоколов с внешними хостами без настройки проброса портов. В linux данная опция называется Conntrack NAT Helpers.

Включение ALG на роутере

В Wive-NG ручная настройка ALG не требуется — достаточно выбрать интересующий протокол из списка.

4. Пара слов про DMZ (Демилитаризованная зона)

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

Настройка DMZ на роутере

Пример: при указании в качестве DMZ адреса 192.168.1.124 , все соединения на глобальный адрес маршрутизатора будут перенаправлены на соответствующие порты устройства 192.168.1.124. К примеру, попытка подключиться к web-интерфейсу через браузер с указанием в адресной строке http://my_ip:80 , будет интерпретировано маршрутизатором как обращение к машине 192.168.1.124 на 80 порт. Будет ли установлено такое соединение, зависит исключительно от того, открыт или закрыт указанный порт на устройстве, расположенном на 192.168.1.124.

Важно: при включении DMZ NAT loopback соединения с LAN на маршрутизатор будут обрабатываться тем же образом, что и соединения с WAN. То есть, доступ к маршрутизатору будет утерян, тк все запросы будут перенаправлены на соответствующие порты по адресу, указанному в качестве DMZ.

Важно: чтобы избежать конфликта, не следует одновременно с DMZ настраивать правила firewall, содержащие в себе тот же адрес, что указан в качестве DMZ.

Особенности фильтрации трафика по IP / MAC / портам рассмотрим в следующей статье…..

Медиа: image / png

16 апреля 2018 года состоялось знаковое для нас событие – встраиваемая операционная система Wive-NG была включена в Единый реестр российских программ для электронных вычислительных машин и баз данных по Приказу Минкомсвязи РФ от 12.04.2018 №157, Приложение 1, №пп.12, реестровый № 4388.

Процесс регистрации занял чуть более полугода, большую часть которого составила техническая экспертиза переданных материалов. Успешное прохождение экспертизы и, как результат, включение ОС в Реестр являются документальным подтверждением российского происхождения программных продуктов проекта Wive-NG. Теперь наше решение заслуженно имеет статус Российской разработки — не только фактический, но и официально зарегистрированный.

Включение OS Wive-NG в Реестр также обеспечит преимущество нашим Партнерам в конкурсах, содержащих требования / преференции для решений российского происхождения.

Автор разработки и правообладатель — один из основателей проекта Wi-CAT и технический директор ООО «Вайрлесс КЭТ» Маначкин Евгений Романович (sfstudio).

Медиа: image / png

В данной статье мы рассмотрим настройку вещания медиаконтента, в частности IPTV, в домашних и офисных сетях с использованием встроенного DLNA-сервера xUPNPd .

Для чего это нужно: для просмотра контента IPTV на устройствах пользователя, не поддерживающих Multicast и плейлисты, без использования TV-приставки (STB). Всё , что необходимо — это устройство , на котором Вы собираетесь просматривать IPTV (телевизор, смартфон) с поддержкой dlna.

Для начала, рекомендации и ограничения:

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

2. Методом, рассмотренным в статье, можно воспроизводить только открытые каналы. То есть, если провайдер шифрует потоки, то ничего не выйдет и метод не применим.

3. Максимально эффективно будет использовать xupnpd в связке с udpxy для использования последнего в качестве конвертера multicast udp в http, понятный для телевизоров. Встроенный в xupnpd вариант крайне урезан и может доставлять проблемы, особенно при попытке смотреть iptv на нескольких устройствах одновременно. Особенно это важно в сетях, для доставки iptv в которых используется Multicast. Для сетей, отдающих поток открытых каналов по http в HLS, это не так критично. Порядок действий таков: сначала включаем udpxy (Services -> Miscellaneous -> Services IPTV ->Multicast to http proxy->LAN либо в русском варианте Сервисы ->Разное -> Сервисы IPTV-> Преобразование мультикаста в http->LAN), затем включаем xupnpd и производим его настройку.

И так, приступаем к настройке.

Настройка сервисов iptv в wi-fi роутере с ПО wive-ng

В настройки xupnpd в web интерфейсе можно попасть следующем путём: Services -> Miscellaneous -> Services IPTV -> DLNA media server (в русскоязычном варианте: Сервисы ->Разное -> Сервисы IPTV->DLNA медиа сервер) . По умолчанию он отключен (находится в статусе Disable / Отключить). После выбора Enable и применения настроек, статус сервиса изменится на «work» / «работает». После этого можно приступать к настройке (переходим в «Configure» / «Настройка»)

Web — интерфейс настройки xUPNPd выглядит следующим образом:

web gui встроенного dlna – сервера xupnpd

Способ №1 — загрузка плейлиста.

Самый простой и быстрый способ начать смотреть iptv — это загрузить плейлист , предоставляемый Вашим провайдером для онлайн-тв. Всё, что Вам необходимо сделать — это зайти в Playlists , выбрать плейлист в формате m3u , ранее скаченный на Ваш ПК , и загрузить его нажатием кнопки Send.

загрузка плейлиста Iptv каналов от провайдера на wifi-роутер

Результатом данной манипуляции будет появление плейлиста в списке на странице Playlists

список загруженных плейлистов

Нажатием Back возвращаемся в главное меню. Теперь мы можем увидеть каналы, доступные для данного плейлиста, на своем телевизоре. Для примера, покажу как это выглядит на Smart TV от Samsung.

1. Заходим в список Источников (Source). Выбираем наш роутер в качестве сетевого устройства (его имя будет совпадать с тем, что отображается в качестве заголовка на стартовой странице настроек xupnpd)

Выбор wi-fi роутера с ПО Wive-NG-mt в качестве сетевого источника на телевизоре Samsung

2. Выбираем интересующий нас плейлист в случае, если их несколько (либо «кликаем» в единственный). Имя плейлиста будет, разумеется, то же самое, что и при загрузке его с локального хранилища.

Выбор плейлиста

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

Список каналов iptv , доступных после подключения к dlna серверу

Процесс простой настройки IPTV без использования STB можно считать законченным.

Способ №2 — настройка фида для автоматического получения плейлиста.

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

Раздел feeds в web gui dlna сервера xupnpd

По умолчанию в Wive-ng добавлено несколько фидов операторов связи (это такие операторы Екатеринбурга как Конвекс, Планета и Инсис, омский ТТК), рекомендуется удалить все не нужные и оставить только те,которые будут использоваться.

Если Вы ранее создавали фид, но забыли его содержание, «зайти» в него через web gui xupnpd, к сожалению, невозможно. Но можно воспользоваться следующей командой:

[Wive-NG-MT@/]# cd etc/xupnpd/config && cat feeds.lua

результат будет выглядеть следующим образом:

feeds=

{

{ "generic", "http://iptv.pantyushin.ru/oms.m3u", "TV-TTK-OMSK" },

{ "generic", "http://www.adslclub.ru/tv/ws-omsk.m3u", "TV-RTK-OMSK" },

{ "generic", "http://www.profintel.ru/files/tv/channels.m3u", "TV-INSIS-EKB" },

{ "generic", "http://tv.convex.ru/tv_all.m3u", "TV-CONVEX-EKB" },

{ "generic", "http://weburg.tv/playlist.m3u", "TV-PLANETA-EKB" },

}

т.е , имя фида, и соответствующие ему плагин и URL плейлиста.

Чтобы добавить собственный фид, соответствующий плейлисту оператора, необходимо в разделе Add feed заполнить три значения следующим образом:
Plugin= Generic
Feed data= m3u_url (т.е ссылка на плейлист в формате m3u)
Name= Любое наименование, под которым Вы хотите видеть Ваш плейлист в списке.
В моем случае настройка выглядит так:

список созданных feed-ов

После завершения настройки , жмём Add, для того, чтобы наши данные сохранились после покидания раздела Feeds — используем, как обычно, Save.

Важно: Поле Feed data чувствительно к регистру. Будьте внимательны при указании URL (лично я потратила кучу времени , чтобы понять,чяднт).

Список доступных плейлистов после обновления фидов

Если всё прошло успешно, то в списке фидов появится только что созданный фид с указанным Вами именем. Перейдя обратно в Playlists , Вы увидите, что ничего не изменилось — список по прежнему пуст. Не стоит пугаться. Если у Вас настроено ручное обновление фидов, то необходимо нажать Reload Feeds. После этого в списке плейлистов появится плейлист, соответствующий только что настроенному фиду. Плейлист появится на Вашем телевизоре по аналогии с разобранным выше Способом №1.

Важно: по умолчанию Feeds reload interval= Playlists reload interval= 0 , это означает, что обновление фидов и плейлистов производится по команде пользователя. Для автоматизации этого процесса необходимо задать таймаут в секундах: например, 86 400 для обновления раз в сутки. Также, необходимо задать ненулевое значение, если необходимо сохранять настроенные фиды даже после обновления ПО на более поздние версии.

Чтоб попасть в раздел настроек xupnpd , необходимо перейти в раздел Config

Переход в раздел “Настройки” в web gui xupnpd

и найти блок «Common (restart needed)»

Настройки dlna сервера xupnpd

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

Не забываем сказать save в xupnpd, а также save & reboot самому роутеру , для сохранения rwfs.

Медиа:1. application / vnd 2. image / jpeg

Теперь немного праздника для владельцев Android устройств.

Идём сюда https://play.google.com/store/apps/details?id=de.resolution.wififixer&hl=ru

Приложение позволяет крутить 3 параметра:

1) порог, при котором будет запущена процедура сканирования и хэндовера
2) дельту уровней между текущей и другими AP, при которой будет выполнено переключение
3) время принудительного рескана окружения

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

Из минусов – требует включенной геолокации (видимо фоновые сканирования зависят теперь в андроиде от этого, т.к. Aruba Utilites ведут себя так же). Параметров не так много как в случае с прямой правкой конфига драйвера, время срабатывания плавает, возможны побочные эффекты.

Мной работа проверена на Samsung Galaxy A5. При выставленном пороге RSSI в -65 и интервале в 3 секунды, аппарат мигрировал где-то при уровне -68 (без приложения у него миграция стартует при -75, причём сильно не сразу), делал это без обрыва соединений от приложений, использование FT также оставалось на месте, и железка мигрировала, используя короткую процедуру (т.е. это не вкл/выкл wifi, как в аналогичных приложениях). Автор заявляет, что писал это дело для SGS S7/8. Но судя по всему будет работать на всех девайсах с радио от Qualcomm (предположительно начиная с Android 6).

Оптимальные значения лежат в пределах -68 ~ -72 (в зависимости от покрытия вашей сети).

P.S. Кстати автор приложения хоть и в правильную сторону движется, но судя по описанию, не очень догоняет, почему именно так происходит. Попробую ему отписать, заодно выяснить, что там ещё через API (геолокации???) на эту тему доступно. Правда не сейчас….

Вариант решения от CISCO – workaround for android devices do not roam on wifi.

Медиа: image / png

# default value of this parameter is zero to enable dynamic threshold allocation
# to set static roming threshold uncomment below parameter and set vaule
gNeighborLookupThreshold=78

# CCX Support and fast transition
CcxEnabled=0
FastTransitionEnabled=1

# 802.11d support
g11dSupportEnabled=0

# Legacy (non-CCX, non-802.11r) Fast Roaming Support
# To enable, set FastRoamEnabled=1
# To disable, set FastRoamEnabled=0
FastRoamEnabled=1

# Handoff Enable(1) Disable(0)

gEnableHandoff=0

#Check if the AP to which we are roaming is better than current AP in terms of RSSI.
#Checking is disabled if set to Zero.Otherwise it will use this value as to how better
#the RSSI of the new/roamable AP should be for roaming
RoamRssiDiff=5

RoamRssiDiff=8

#Beacon Early Termination (1= enable the BET feature, 0= disable)
enableBeaconEarlyTermination=1
beaconEarlyTerminationWakeInterval=11

gActiveMaxChannelTime=60
gActiveMinChannelTime=30
gActiveMaxChannelTimeConc=60
gActiveMinChannelTimeConc=30

# 802.11K support
gRrmEnable=1
gRrmOperChanMax=8
gRrmNonOperChanMax=8
gRrmRandIntvl=100

# 1: Enable standby, 2: Enable Deep sleep, 3: Enable Mcast/Bcast Filter
gEnableSuspend=3

#Channel Bonding
gChannelBondingMode24GHz=1
gChannelBondingMode5GHz=1
gShortGI20Mhz=1
gShortGI40Mhz=1

Медиа: image / png

Медиа: image / png

Лечим неприятную регрессию в Linux с картами от Intel.

После обновления wpa_supplicant с правками, касающимися уязвимости WPA2 CRACK, многие владельцы интелов могли обратить внимание на странное поведение адаптера. Проявляется оно как потеря связи на некоторое время с интервалом в половину времени истечения срока жизни GTK.

При этом в логах нет абсолютно никакого криминала. Нет также и попыток переподключения, просто останавливается хождение данных, пока роутер или точка доступа не отстрелят такого клиента по idle timeout.

Проблема оказалась в том, что intel частично реализует логику SME (даже в случае использования nl80211 подсистемы ядра) на уровне микрокода. И после внесения правок на стороне supplicant’а, обновление группового ключа происходит не всегда корректно.

Исправление микрокода Intel представил в обновлении от 3.11.2017, однако большинство дистрибутивов так и не обновили микрокод, хотя обновили supplicant. Отсюда и появилась проблема.

Для решения, достаточно стянуть новый микрокод отсюда https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git/log/ (например сказав git clone https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git)

После чего содержимое скопировать поверх /lib/firmware и перезагрузиться.

Проконтроллировать успех можно заглянув до и после в вывод dmesg и обратив внимание на строку iwlwifi 0000:01:00.0: loaded firmware version XX.YYYYYY.Z op_mode iwlmvm.

Кроме всего прочего, неаккуратно бэкпортированные фиксы уязвимости wpa_supplicant в Mageia 6 ломают миграцию. Клиент перестаёт выполнять автоматические фоновые сканирования и даже не пытается мигрировать.

Решение — сборка последней версии wpa_supplicant из git куда уже включены все необходимые правки. Ну и репортим разработчикам своих дистрибутивов.

Медиа: image / jpeg

Band steering глазами инженера

В этой части мы поговорим о такой «технологии» как Band Steering. Это необходимое для понимания работы миграции в Dual Band сетях отступление.

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

Поясню. На заре появления 802.11a, т.е. варианта 802.11, работающего в 5ГГц диапазоне, никто (как обычно) не задумывался о совместном использовании двух диапазонов, и о возникающих проблемах. В итоге вся логика, используемая на клиентах для 2.4ГГц, плавно перекочевала в 5ГГц.

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

Т.к. «стандарт» 802.11 не требует никакой специальной логики для dual band сетей, то выбор осуществляется просто по уровню сигнала (RSSI).

Но тут существует несколько моментов:
1) чем выше частота — тем выше затухание сигнала с отдалением от передатчика
2) чем выше частота — тем выше затухание в преградах

Т.е. при той же мощности передатчика (что на практике зачастую именно так) мы крайне часто, даже находясь в одном помещении, будем иметь ситуацию, когда RSSI в 5ГГц диапазоне будет заметно ниже. И наш клиент, несмотря на то, что умеет 5ГГц, будет стремиться соединиться в 2.4ГГц.

Проблема усугубляется с ростом расстояния от AP.

Почему это, собственно, вообще проблема? Какая, казалось бы, разница, в каком диапазоне будет работать клиент.

Тут всё просто. В 2.4ГГц очень тесно. В том смысле, что нет ни одного непересекающегося канала для полосы 40МГц (если посмотреть на спектр, который, как известно, не заканчивается резким обрывом). А 80МГц (и более) полосы вообще не доступны.

Плюс уже работает море устройств, не только wifi, и в т.ч. у соседей. Всё это приводит к значительному падению SNR (соотношению сигнал/шум). А именно SNR, а не RSSI, важен. Т.е., можно орать сколько угодно громко, но если рядом соседи будут кричать со сравнимыми уровнями, то клиент просто не сможет разобрать, что ему пытаются сказать.

В 5ГГц всё иначе. Диапазон более чистый, т. к. устройств там не так много, и в основном это такие же wifi устройства. Также, заметно более низкое влияние оказывают соседи, т.к. заметно выше затухание сигнала в преградах (читай стенах). Т.е., SNR даже при заметно более низком RSSI будет заметно выше, а передача данных быстрее и стабильнее. Плюс, доступна как минимум в четыре раза большая полоса (в случае с РФ), нежели чем в 2.4ГГц.

С точки зрения логики и здравого смысла, а также физики, имеет смысл пытаться использовать 5ГГц диапазон, если клиент его умеет, даже если уровень сигнала от конкретной AP заметно ниже, чем от неё же в 2.4ГГц.

И вот тут мы вспоминаем, что клиентские устройства у нас поголовно “тупые” и выбирают, куда будут соединяться, исключительно ориентируясь в RSSI.

Т.е. при одинаковых SSID в обоих диапазонах, большинство dual band клиентов банально будет использовать грязный и узкий 2.4ГГц диапазон, вместо того, чтобы работать в 5ГГц.

Правильным решением было бы наличие на клиенте логики, которая позволяет пользователю задать приоритет выбора диапазона.

Настройка band preffered на картах Intel

И такие клиенты есть. Например, многие радиокарты от Intel позволяют выбрать preffered band (предпочтительный диапазон). Плюс большинство радиокарт в ПК и ноутбуках позволяют просто отключить поддержку того или иного диапазона, что также можно использовать для решения проблемы. Обычно все эти настройки доступны в настройках драйвера (Windows) или на уровне wpa_supplicant (Linux).

С мобильными устройствами в виде смартфонов дела обстоят иначе. В 99% случаев нет не то что band preffered, но и даже возможности банально отключить поддержку 2.4ГГц диапазона. И именно с ними проблема встаёт в полный рост.

Казалось бы, проблема решается элементарно, путём внесения в следующую итерацию «стандарта» и сопутствующих спецификаций требования реализации логики «preffered band» для всех клиентов, претендующих пройти сертификацию на совместимость с очередным 802.11AN/AC/AX и т.д…

К сожалению, Wi-Fi альянс считает иначе, поэтому требования не было и нет. Т.е. с 1999 года, когда был представлен вариант 802.11a «стандарта» wi-fi, проблема хоть и была выявлена, но никаких действий для её решения ни со стороны WiFi Aliance, ни со стороны большинства производителей клиентского оборудования, сделано не было.

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

Но это лирика. Вернёмся к Band Steering.

Т.к. Wi-Fi альянс решил проблемой не заниматься, пришлось производителям беспроводных решений изобретать свой велосипед.

Первыми на лоне решения этой проблемы была Meraki. Именно они предложили первый в своём роде костыль и назвали его Band Steering https://documentation.meraki.com/MR/Radio_Settings/Band_Steering_Overview

Наглядное пояснение как работает band steering от Meraki

Основной смысл на тот момент заключался в том, что для нового клиента мы не сразу начинаем отвечать на probe request при активном сканировании и на стадии предшествующей ассоциации в 2.4ГГц диапазоне. А поставим клиента на hold и будем ждать несколько секунд, пока либо клиент не подключится к 5ГГц модулю, либо ничего не произойдёт, и тогда мы будем считать, что клиент у нас умеет только 2.4ГГц, и тогда мы его пустим.

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

Ок, подумали в Meraki и решили расширить логику. А давайте, AP будут слушать все probe req для всех AP от клиента, а не только для себя, и на основании этих данных мы сможем достаточно достоверно определить (еще до подключения клиента), умеет ли клиент 5ГГц, и если умеет, то вообще не отвечать на probe этому клиенту в 2.4ГГц. Тем самым, заранее сможем определить куда пускать, а куда нет.

И это был прорыв… Подход сработал (ну почти), это позволило даже как-то сожительствовать band steering совместно с бесшовным роумингом и всё было прекрасно, пока…

Пока в один прекрасный день, параноики из Apple и Google не задумались о том, что ведь на основании прослушивания эфира можно отслеживать положение того или иного устройства по mac в probe. И просто начали рандомизировать MAC адреса в probe запросах.

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

Плюс, клиенты почти поголовно научились использовать фоновое сканирование, а там на стадии сканирования вообще никакие probe не шлются, а значит клиент в любом случае будет видеть оба диапазона, и “спрятаться” от него не выйдет. И опять-таки, в лоб сравнивая RSSI, будет пытаться соединиться в 2.4ГГц.

Хорошо, сказали Meraki, раз решить проблему теперь исключительно на уровне probe не удаётся, давайте будем, как последний барьер, использовать assoc/auth req. Да, это не решает проблем с задержками при подключении/миграции, но позволяет хотя бы большую часть клиентов насильно заставить соединиться в 5ГГц.

Вот на этом уровне реализация Band Steering остановилась.

Конечно существуют и расширенные реализации, которые например разрешают клиентам переключаться в 2.4ГГц при падении уровня (как в Wive) или могут насильно спинывать (слать DEAUTH что приведёт к обрыву связи и с определённой долей вероятности переключения клиента на другой диапазон) клиента с 5ГГц диапазона при падении уровня ниже порога (как у MTK), но основной смысл от этого не меняется.

По факту, применять Band Steering сейчас имеет смысл разве что на хотспотах, где не критично, что часть клиентов получит проблемы, и где нет возможности использовать разные SSID для разных диапазонов, заставляя административными мерами пользователей с dual band устройствами использовать 5ГГц.

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

Исходя из этого, если на клиенте нет возможность задать приоритетный диапазон – стоит воспользоваться вариантом с разными SSID для разных диапазонов. И в самом крайнем случае – Band Steering. А если вы строите сеть с прозрачной миграцией, и ключевым аспектом является именно миграция, то band steering строго противопоказан.

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

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

Продолжение следует…

Первая часть. Третья часть.

Медиа: image / gif

Тестирование в типовых условиях 25 этажного муравейника.

Вот и настала очередь SNR-CPE-ME1 показать свои способности в радио. Подробно о начинке которого рассказано тут.

Условия тестирования – десяток сетей в 2.4ГГц с уровнями выше -75 и несколько штук 5ГГц сетей с уровнями выше -80 (микротик и убик орут где-то рядом судя по макам). Тестировалось в пределах одной комнаты – частично прямая видимость.

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

Начнём с 5ГГц, в ME1 установлен тот же чип что и в MD1 т.е. MT7610 (1T1R т.е. максимальный рэйт 433Мбит), но оборудован другим FEM от Skyworks (Front End Module, т.е. PA+LNA+RX/TX коммутатором в одном флаконе), что позволило полностью выбрать мощность заложенную законодательными ограничениями РФ, т.е. 23дБм (200мВт с недавних пор разрешили таки) в 5ГГц и улучшить чувствительность на приём т.к. новый FEM ещё и заметно менее шумный. Это в свою очередь почти уравняло 5ГГц и 2.4ГГц по зоне покрытия, однако не стоит забывать что клиентское оборудование обычно гораздо менее мощное, потому в 5ГГц при удалении от АП будет заметный перекос в скорости в с торону от АП к клиенту. Так же на каком-то удалении (при маломощном клиенте) АП просто перестанет его слышать и клиент будет отключен.

Intel 7260, 80МГц, Max Rate 433Mbit – iperf

iperf показывает 281мбит knemo говорит о 287Mbit RX и 6,5Mbit TX. iperf не учитывает подтверждения доставки и оверхид TCP. Поэтому и видим разницу около 7Мбит.

Едем дальше.

Intel 3160, 80MHz, Max Rate 433Mbit – iperf

i3160 mode in STA list

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

Очередь мобильных устройств. Под рукой из 5ГГц девайсов во время тестирования был только Samsung Galaxy A5, так же поддерживающий полосу в 80МГц SGI и прочее.

Galaxy A5 2017, 80MHz, Max Rate 433Mbit – iperf

Galaxy A5 2017, 80MHz, Max Rate 433Mbit – speedtest

Как видим по iperf получилось порядка 257Мбит. Адаптер в телефоне не умеет использовать длинные очереди агрегации (макс 8к) отсюда и разница с предыдущими.

Спидтест приведён исключительно для наглядности, т.к. подключение к оператору у меня 100Мбит и полученные скорости упираются в порт и магистрали до серверов тестирования и т.д. Плюс у оператора нет изоляции на L2 внутри дома, поэтому в сегменте постоянно стоит флуд порядка 5ти мегабит от соседей (Инсис, такой Инсис, лентяи…), отсюда и перекос в сторону Tx.

Что касается 2.4ГГц. SNR-CPE-ME1 оборудован новым 2T2R чипом MT7603, максимальный рэйт 300Мбит (40МГц полоса). Так же как и в 5ГГц используются внешние усилители от SkyWorks. Ограничение по мощности так же строго по законодательным нормам РФ 20дБм.

Одна из особенностей чипа 7603 это использование того же auto group rate alg (реализуется на уровне микрокода плюс драйвера) что и для AC чипов. Чип имеет поддержку AirTimeFairness, точнее её клиентонезависимую часть. Таким образом существенно сокращается вероятность возникновения ситуации когда удалённый и/или “низкоскоростной” клиент монопольно выбирает всю ёмкость не оставляя ничего своим соседям по АП.

Теперь тесты.

Intel 7260, 2T2R, 40MHz Max Rate 300Mbit – iperf

iperf 170MBit, knemo 174Mbit (выше объяснял почему так). Т.е. мы упёрлись в загруженность эфира чуть чуть не дотянув до расчётных 185Мбит (10Мбит разницы) в идеальных условиях.

Intel 3160, 1T1R, 40MHz Max rate 150Mbit – iperf

89Мбит iperf, т.е. тут тоже чётко видно, что лишь чуть чуть не дотянули (пары мегабит с учётом оверхида TCP и посыла подтверждений) до теоретически возможного максимума для 1T1R адаптеров работающих в полосе 40МГц.

Samsung Galaxy A5

У него в 2.4ГГц софтовое ограничение 20МГц полосой (как и у многих современных смартфонов), и он так же как и I3160 умеет лишь один стрим (1T1R это большинство мобильников на рынке, крайне редко встречаются 2T2R устройства, >2T2R вообще в природе не встречал).

Соответственно 1T1R 20MHz Max Rate 72Mbit

SGS A5 2.4GHz 1T1R 20MHz SGI – iperf

SGS A5 2.4GHz 1T1R 20MHz SGI – speedtest

Думаю тут всё ясно. 52Мбит (на самом деле 54 т.к. помним о оверхиде) это по сути предел для этого режима, т.е. упираемся в возможности клиента.

LG G2 mini

Самый куций и старый представитель в тесте. Умеет только 2.4GHz, только полосу в 20MHz и один стрим.

LG G2 mini 2.4GHz 1T1R 20MHz SGI – iperf

LG G2 mini 2.4GHz 1T1R 20MHz SGI – speedtest

Показания практически аналогичны Samsung Galaxy A5 т.к. по сути адаптеры идентичны с точки зрения возможностей с учётом софтовых ограничений заложенных самсунгом в A5.

Т.е. суммарная максимальная эффективная скорость (реальная максимальная скорость передачи данных) при использовании обоих диапазонов на клиентах умеющих всё что умеет роутер, в реальном эфире, примерно 460Мбит.

Максимальный суммарный рэйт при этом 733Мбит (именно его производители часто указывают на коробках суммируя максимальный рэйт в 2.4ГГц и в 5ГГц).

---

ВНИМАНИЕ!!! Оборудование SNR-CPE (ветка Wive-NG-MT) переведено в режим ограниченного сопровождения
включающего в себя только исправление уязвимостей. И только для оборудования купленного до 01.03.2019.
Корректная работа официальных сборок Wive-NG-MT на боле новых устройствах SNR не гарантируется.
Поддержка по новым устройствам SNR так же не оказывается.

Медиа: image / png

SNR-CPE – это линейка беспроводных маршрутизаторов и точек доступа, производимая и поставляемая компанией НАГ с использованием ПО Wive-NG-mt в качестве встроенной операционной системы.

Ценности, взятые за ориентир при создании линейки:

• Стабильное решение, не требующее регулярного обслуживания;
• Локализация разработки ПО в РФ. Оперативная реакция на репорты, постоянная актуализация кодовой базы, SDK , драйверов;
• Отлаженная аппаратная платформа. Оптимизация схемотехники устройств, отказ от использования готовых устройств “as is”;
• Следование стандартам, совместимость с любым оборудованием в рамках RFC, соответствие потребностям операторов связи в РФ и СНГ;
• Интеграция с сертифицированными сервисами авторизации, популярными в РФ и СНГ;
• Экономическая эффективность без потери качества и функциональности

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

Маршрутизаторы FE с поддержкой 802.11b/g/n (2.4 ГГц):

SNR-CPE-W4N (rev.M)

SNR-CPE-W4N (rev.M)

SNR-CPE-W2N

Маршрутизаторы FE и GE с поддержкой 802.11a/b/g/n/an/ac (2.4 ГГц + 5 ГГц):

SNR-CPE-MD1

SNR-CPE-MD1.1

SNR-CPE-ME1

Точки доступа FE с поддержкой одного (2.4 ГГц) или двух (2.4 ГГц + 5 ГГц) диапазонов:

SNR-CPE-Wi2

SNR-CPE-AP1

SNR-CPE-AP2

Подробнее….

Для организации корпоративной сети беспроводного доступа реализовано:

• Работа роуминга без внешней сущности – “контроллера”;
• Поддержка 802.11K (Radio Resource Management) на уровне драйвера;
• Поддержка 802.11R (Fast Transition), 802.1x Pre-auth, PMK cache ;(кэширование ключей) при переключении между AP;
• Гибкий набор параметров настройки HandOff
  

  Пример настроек Handoff

• Band Steering для распределения клиентов по частотам;
• Мониторинг состояния клиентов прямо на AP;
• Поддержка «WPA2 Enterprise» : авторизация на Radius сервере
  Подробнее….

Работа с радиотрактом , управление беспроводной сетью:

• Одновременная работа 2.4 и 5GHz (два независимых радиомодуля);
• Одновременная работа в режиме беспроводной клиент, WDS и Router/AP (в том числе в одном диапазоне);
• Графический анализатор эфира для удобства выбора канала
  

  Результат сканирования эфира в типовой квартире многоэтажного дома

• Автовыбор канала по ряду параметров (кол-во станций/степень загруженности);
• Широкий набор параметров настройки Wifi для администратора и продвинутых пользователей, доступный в web-интерфейсе

Работа с беспроводными клиентами:

• Развернутая информация о подключенных wifi клиентах, возможность их отключения посредством web-интерфейса
  

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

• Графическое и табличное отображение статистических данных работы беспроводной сети:
  RX/TX Bandwidth (+суммарный)
  TX Rate
  RSSI
  Quality
  

  График сетевой активности (RX+TX Bandwidth) клиентских устройств за 1 минуту

Для авторизации пользователей реализован ряд инструментов.

Авторизация с использованием Hotspot / Captive Portal:

• Встроенный Hotspot сервер NoDogSplash: Captive Portal прямо на роутере;
• Поддержка Chilispot (CoovaChili) для работы с внешними сервисами авторизации;
• Интеграция с сертифицированными по законодательству РФ сервисами авторизации;
• Возможность реализации интеграции с системой авторизации, используемой в сети заказчика;
• Предустановочные профили популярных сертифицированных сервисов авторизации для упрощения настройки при запуске в работу на объекте
  

  Профили сервисов Hotspot, доступные для быстрой настройки

  Подробнее….

Авторизация с использованием RADIUS (802.1x):

• Встроенный RADIUS сервер на базе Free radius для авторизации прямо на одном из маршрутизаторов в сети;
• Индивидуальные пары логин/пароль для каждого пользователя, создаваемые через web-интерфейс;
• Централизованная аутентификация в сети с использованием внешнего сервера на базе 802.1x EAP-TTLS-PEAP-MSCHAPv2 (WPA2-Enterprise)
• Организация легального временного Wifi-доступа в публичных сетях (гостиницы, кафе, предприятия с контролем пользователей интернет)

Для решения вопросов сегментирования и изоляции в сети, мы предлагаем:

• Выделение каждого SSID в VLAN;
  

  Пример настройки SSID to VLAN

• Изоляция между беспроводными клиентами;
• Зонирование локальной сети с помощью VLAN;
  

  Wive-NG-MT – Настройка VLAN

• Обеспечении изоляции на уровне L2 между зонами

Вопрос качественной работы с медиаконтентом стоит остро как в операторских сетях, предоставляющих услугу IPTV для домашних пользователей, так и в корпоративных сетях, нуждающихся в организации IP-телефонии и централизованного вещания видеопотока, а также в публичных сетях доступа (кафе, рестораны), где нередко ведется трансляция рекламного, музыкального или иного видео. Такая задача успешно решается устройствами серии SNR-CPE за счет возможностей:

• Работа IPTV (в том числе FHD) без артефактов, включая Wifi (но мы рекомендуем по возможности не использовать wi-fi как средство передачи iptv-трафика)
• Поддержка аппаратного IGMP Snooping , IGMP Proxy
• Конвертация Multicast to Unicast для LAN , WLAN
• Встроенный DLNA сервер xUPNPD с возможностью загрузки операторских плейлистов (в том числе автоматически обновлять их с сервера оператора)
• Поддержка UDPXY (mcast to http proxy) для повышения стабильности передачи данных в связке с медиаплеером на ПК / ТВ-приставкой (STB)
• Выделение портов для STB / SIP с или без тегирования (VLAN)
• Приоритезация Multicast трафика (WIreless MultiMedia);

Устройства на базе ПО Wive-NG-mt легко адаптируются под операторскую сеть, в которой используются. Причем, адаптация может быть произведена силами linux-администратора оператора связи и включает:

• Возможность модификации ПО под нужды сети без пересборки (включая полностью директорию /etc , т.е при необходимости это может быть дизайн и видимость полей web-интерфейса, конфигурация по умолчанию, набор скриптов, исполняемых при загрузке устройства, и т.д.);
  

  Пример кастомного web интерфейса от Net-By-Net

• Заливка собственного модуля через web, ssh , что снижает риск ошибок по причине человеческого фактора при настройке устройства монтажником;
• Доступность исходных кодов (GPL license);
• Roadmap SNR-CPE: профили web интерфейса с разным набором видимых полей («базовый» , «администратор»);
• Roadmap: профили операторов связи, позволяющие максимально снизить количество ручной настройки, выбрав профиль оператора связи, который “подтянет” за собой дефолтную конфигурацию, уникальную для данного оператора.

Также, удобство администратора обеспечивается широкими возможностями по удаленному управлению и мониторингу:

• Поддержка протокола cwmp (TR-069, TR-098), возможность реализации поддержки используемого в сети ACS сервера, уже реализованная интеграция с популярными ACS серверами (коммерческие вендорские продукты, свободные ACS серверы, операторские решения);
• Полноценная управляемость посредством SSH (Embedded Linux-based OS), возможность создания дополнительного пользователя для организации удаленного доступа по SSH с необходимого IP адреса (по умолчанию возможность отключена!);
• Поддержка SNMP;
• Собственная система мониторинга и управления для корпоративных сетей Wive-NG Control, позволяющая собирать данные о точках доступа, беспроводных клиентах, строить аналитические графики и диаграммы, осуществлять удаленное обновление ПО и конфигурацию (в том числе, по расписанию) и т.д.
  

  Диаграмма, наглядно демонстрирующая распределение клиентских устройств по точкам доступа , с указанием частот, на которых работают клиенты

  

  График сетевой активности (RX+TX Bandwidth) клиентов за интересующий интервал времени на всех AP, либо выбранной.

Не забыли и про домашнего пользователя. Для его удобства:

• Маршрутизатор поставляется с оптимальными и максимально безопасными настройками по умолчанию (минимум манипуляций от пользователя для обеспечения стабильной и безопасной работы);
• Разделы четко структурированы по типу настроек, разделены базовые и расширенные настройки;
  

  Группировка разделов , на примере настроек IPTV

• Уведомление о небезопасном использовании реквизитов по умолчанию;
  
• Просмотр пароля wifi в web (по умолчанию скрыт)
• Подтверждение пароля администратора при смене , для исключения опечатки;
• Наличие русского языка в web-интерфейсе (по умолчанию язык интерфейса – английский)

  Внимание!!! Сотрудничество между нами и компанией NAG завершено в феврале 2019г. Новые устройства с оригинальной Wive-NG-MT производиться не будут. По всем вопросам (включая доступность новых разработок и поддержку для юридических лиц, а так же переводу существующего оборудования на актуальную версию Wive-NG-HQ) обращайтесь по адресу info@wi-cat.ru .

Медиа: image / png

Делая доброе дело помни о его законности (с) …

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

Для решения этой задачи в Wive-NG встроен CoovaChilli.

CoovaChilli – это полноценный access controller (контроллер доступа) для captive portal, позволяющий работать с внешними сервисами авторизации (например, для организации авторизации через SMS и ведения необходимой отчётности).

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

Текущий набор профилей:
1) http://www.mywifi.com
2) http://saiwifi.ru
3) http://wifisystem.ru
4) http://hotspot.ots-net.ru
5) https://wifly.ru/

Данные сервисы подходят для решения проблемы авторизации по SMS и предоставления отчётности на территории РФ и СНГ.

Так же существует прекрасная биллинговая система интегрируемая с сервисами оплаты совместимая с Chillispot/CoovaChilli.

Готовая свободная платформа для развёртывания Radius сервера + LAMP поддерживающая интеграцию с Coova Chilli https://www.daloradius.com/.

Медиа: image / png

[Wive-NG-HQ:/]$ mount | grep opt
/dev/sda1 on /opt type ext4 (rw,noatime,data=ordered)		

[Wive-NG-HQ:/]$ entware_install.sh

Connecting to bin.entware.net (172.67.212.134:80)

writing to stdout

- 100% |*************************************************************| 2212 Info: Checking for prerequisites and creating folders...

 0:00:00 ETAWarning: Folder /opt exists!

written to stdout
Info: Opkg package manager deployment...
Connecting to bin.entware.net (104.27.177.50:80)
saving to '/opt/bin/opkg'
opkg 100% |*************************************************************| 163k 0:00:00 ETA
'/opt/bin/opkg' saved
Connecting to bin.entware.net (172.67.212.134:80)
saving to '/opt/etc/opkg.conf'
opkg.conf 100% |*************************************************************| 150 0:00:00 ETA
'/opt/etc/opkg.conf' saved
Connecting to bin.entware.net (172.67.212.134:80)
saving to '/opt/lib/ld-2.27.so'
ld-2.27.so 100% |*************************************************************| 155k 0:00:00 ETA
'/opt/lib/ld-2.27.so' saved
Connecting to bin.entware.net (172.67.212.134:80)
saving to '/opt/lib/libc-2.27.so'
libc-2.27.so 100% |*************************************************************| 1609k 0:00:00 ETA
'/opt/lib/libc-2.27.so' saved
Connecting to bin.entware.net (172.67.212.134:80)
saving to '/opt/lib/libgcc_s.so.1'
libgcc_s.so.1 100% |*************************************************************| 94428 0:00:00 ETA
'/opt/lib/libgcc_s.so.1' saved
Connecting to bin.entware.net (104.27.177.50:80)
saving to '/opt/lib/libpthread-2.27.so'
libpthread-2.27.so 100% |*************************************************************| 116k 0:00:00 ETA
'/opt/lib/libpthread-2.27.so' saved
Info: Basic packages installation...
Downloading http://bin.entware.net/mipselsf-k3.4/Packages.gz
Updated list of available packages in /opt/var/opkg-lists/entware
Installing entware-opt (227000-3) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/entware-opt_227000-3_all.ipk
Installing libgcc (8.3.0-9) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/libgcc_8.3.0-9_mipsel-3.4.ipk
Installing libc (2.27-9) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/libc_2.27-9_mipsel-3.4.ipk
Installing libssp (8.3.0-9) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/libssp_8.3.0-9_mipsel-3.4.ipk
Installing libpthread (2.27-9) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/libpthread_2.27-9_mipsel-3.4.ipk
Installing librt (2.27-9) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/librt_2.27-9_mipsel-3.4.ipk
Installing libstdcpp (8.3.0-9) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/libstdcpp_8.3.0-9_mipsel-3.4.ipk
Installing entware-release (1.0-2) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/entware-release_1.0-2_all.ipk
Installing zoneinfo-asia (2019c-1) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/zoneinfo-asia_2019c-1_mipsel-3.4.ipk
Installing zoneinfo-europe (2019c-1) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/zoneinfo-europe_2019c-1_mipsel-3.4.ipk
Installing findutils (4.7.0-1) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/findutils_4.7.0-1_mipsel-3.4.ipk
Installing terminfo (6.2-1) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/terminfo_6.2-1_mipsel-3.4.ipk
Installing libpcre (8.43-2) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/libpcre_8.43-2_mipsel-3.4.ipk
Installing grep (3.4-1) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/grep_3.4-1_mipsel-3.4.ipk
Installing locales (2.27-9) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/locales_2.27-9_mipsel-3.4.ipk
Installing opkg (2019-06-14-dcbc142e-2) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/opkg_2019-06-14-dcbc142e-2_mipsel-3.4.ipk
Installing entware-upgrade (1.0-1) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/entware-upgrade_1.0-1_all.ipk
Configuring libgcc.
Configuring libc.
Configuring libssp.
Configuring libpthread.
Configuring librt.
Configuring terminfo.
Configuring libpcre.
Configuring grep.
Configuring locales.
Entware uses separate locale-archive file independent from main system
Creating locale archive /opt/usr/lib/locale/locale-archive
Adding en_EN.UTF-8
Adding ru_RU.UTF-8
You can download locale sources from http://bin.entware.net/other/i18n_glib227.tar.gz
You can add new locales to Entware using /opt/bin/localedef.new
Configuring entware-upgrade.
Upgrade operations are not required
Configuring opkg.
Configuring zoneinfo-europe.
Configuring zoneinfo-asia.
Configuring libstdcpp.
Configuring entware-release.
Configuring findutils.
Configuring entware-opt.
Info: Congratulations!
Info: If there are no errors above then Entware was successfully initialized.
Info: Add /opt/bin & /opt/sbin to $PATH variable
Info: Add "/opt/etc/init.d/rc.unslung start" to startup script for Entware services to start
Info: Found a Bug? Please report at https://github.com/Entware/Entware/issues
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!NEED REBOOT DEVICE BEFORE USE!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[Wive-NG-HQ:/]$ fs save && reboot
Save curent date and current time to rwfs
Compress config files
tar: removing leading '/' from member names
Write RW-FS to flash (176kB of 256kB)
Unlocking RW-FS ...
Writing from /tmp/tgzfs to RW-FS ... [w]
Config saved. OK.

[Wive-NG-HQ:/]$ opkg install mtr
Installing mtr (0.93-1) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/mtr_0.93-1_mipsel-3.4.ipk
Installing libncursesw (6.2-1) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/libncursesw_6.2-1_mipsel-3.4.ipk
Installing libncurses (6.2-1) to root...
Downloading http://bin.entware.net/mipselsf-k3.4/libncurses_6.2-1_mipsel-3.4.ipk
Configuring libncursesw.
Configuring libncurses.
Configuring mtr.

Произвести проверку того, что всё прошло без ошибок, можно, запустив инструмент (например, командой mtr www.ru).

Медиа: image / jpeg

Медиа: image / png

Wive-NG-MT – это дальнейшее развитие встраиваемого ПО для маршрутизаторов для нового бюджетного чипа от Ralink/Mediatek MT7620 и середнячка – MT7621.

Вся информация на страницах по RT305х и RT3883 (ПО Wive-NG-RTNL) также актуальна и для Wive-NG-MT.

Wive-NG-MT является коммерческой открытой встраиваемой операционной системой (дистрибутивом), разработанной специально для предустановки в wi-fi маршрутизаторы, произведённые компанией NAG под торговой маркой SNR-CPE.

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

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

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

Мы не гарантируем корректной работы на устройствах, отличных от произведённых нашими заказчиками. Также, не несём никакой ответственности за порчу вашего оборудования. Помните, что после заливки Wive на стороннее устройство, вы потеряете индивидуальные калибровочные данные, а также – тот факт, что возможных конфигураций MT7620 в части радио существует несколько десятков, и под каждый из вариантов требуется корректно сконфигурировать ядро и откалибровать радиомодули, иначе можно ждать любых проблем вплоть до выхода из строя аппаратной части. К сожалению, реализовать автодетект наличия/отсутствия тех же PA/LNA невозможно, как и учесть индивидуальные особенности того или иного экземпляра без процедуры калибровки.

Новая ветка синхронизирована с 5.0.2.0 версией оригинального SDK. Базируется на 3.4 LTS ветке ядра (плюс множество бэкпортов из более свежих ядер). Включает в себя все актуальные исправления и актуальные версии драйверов. Также портированы все оптимизации и режимы оффлоада, доступные в RTNL ветке.

На данный момент Wive-NG-MT имеет статус стабильного релиза.

Официально поддерживаются только SNR-CPE-W4N (rev.M) / SNR-CPE-W2N, его двухдиапазонная версия SNR-CPE-MD1 / SNR-CPE-MD1.1, гигабитный роутер SNR-CPE-ME1, а также потолочные точки доступа SNR-CPE-AP1, SNR-CPE-AP2.

Однодиапазонная версия с поддержкой 802.11N – SNR-CPE-W4N (rev.M) – MT7620N/H rev206 8Mb FLASH 64MB DDR1 RAM without USB.
Двухдиапазонная версия с поддержкой одновременной работы 802.11N и 802.11AC – SNR-CPE-MD1.1- MT7620A/H rev206+MT7610NE 8Mb FLASH 64MB DDR2 RAM without USB.
Однодиапазонная потолочная точка доступа с поддержкой 802.11N – SNR-CPE-AP1 – MT7620N/H rev206 8Mb FLASH 64MB DDR2 RAM without USB.
Двухдиапазонная версия потолочной точки доступа с поддержкой 802.11N и 802.11AC – SNR-CPE-AP2 – MT7620N/H rev206+MT7610NE 8Mb FLASH 64MB DDR2 RAM without USB.

Обсуждение устройств SNR на MT762x (включая тесты, багрепорты, вопросы разработки и эксплуатации) у открыто у нас на форуме.
Описание от производителя SNR-CPE-W4N revM http://shop.nag.ru, SNR-CPE-MD1 http://shop.nag.ru
Наличие устройств на складе, а также цену можно уточнить по адресу: http://shop.nag.ru
По всем вопросам, связанным с приобретением устройств SNR-CPE-W4N-MT, обращайтесь по адресу sales@nag.ru
Вопросы поддержки (багрепорты, запросы функционала и прочие) – support@nag.ru
Вопросы кастомизации и прочие, не связанные с технической стороной или продажами – wifi@nag.ru

Заказывая данные устройства, вы поддерживаете серию прошивок Wive-NG. Именно это позволяет заказчикам вкладывать деньги в дальнейшее развитие проектов, а мне не отвлекаться и продолжать заниматься совершенствованием ПО.

На данный момент Wive-NG-MT поддерживает весь набор (и даже больше) возможностей, которые были в Wive-NG-RTNL. Подходит для использования при L2TP/PPTP/PPPOE/IPOE/KABINET AUTH вариантах доступа в сеть, на любом из используемых протоколов скорость ограничена только скоростью портов Ethernet коммутатора 100Мбит FDX по проводу. По wi-fi ограничена 802.11N 2T2R 40MHz SGI в 2.4ГГц (для MT7620) и 802.11AC 1T1R SGI 80МГц (для MT7610NE) режимами (в относительно чистом эфире с соответствующими клиентами, для 2.4ГГц вполне достижимы скорости в пределах 130-140Мбит/c RX+TX; для 5ГГц суммарное значение RX+TX равно скорости порта 100FDX для модели MD1 / MD1.1 и достигает 290Мбит/с полудуплекса для модели SNR-CPE-ME1).

Также, добавлена поддержка IPv6 (DHPCv6+RA / Static IPv6 или 6to4, включая варианты поверх VPN, другие варианты будут добавляться по запросу после организации тестового стенда).

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

Реализация WPA Enterprise позволяет развернуть сквозную аутентификацию (для каждого пользователя используется своя пара логин/пароль). При этом, в роли Radius сервера может выступать как одна из AP, так и RADIUS, развернутый на отдельном физическом сервере, что позволяет интегрировать управление доступом с другими сервисами, уже работающими на предприятии.

Поддержка Band Steering позволяет высвободить ресурсы 2.4ГГц сети, вынуждая Dual Band клиентов использовать соединение в 5ГГц диапазоне, если это возможно.

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

Поддержка HotSpot (coova chilli) с преднастроенными профилями позволяет быстро и в полном соответствии с текущим законодательством развернуть точки доступа Wi-Fi для клиентов вашей компании, гостей кафе или гостиниц.

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

Если вам требуется какой-то функционал и вы точно технически грамотно можете описать, что вам нужно и как это должно работать – вас всегда ждут в support@nag.ru

Текущие сборки.
Исходные тексты.
Список операторских сетей, в которых работает ПО Wive-NG
Руководство пользователя.

Медиа: image / png

В порядке запуска в серию:

1) SNR-CPE-W4N (rev. M) – однодиапазонный маршрутизатор
2) SNR-CPE-MD1 – двухдиапазонный маршрутизатор с поддержкой 802.11AC (модель выпускалась до 3 кв.2017 года, актуальная замена – SNR-CPE-MD1.1)
3) SNR-CPE-AP1 – однодиапазонная потолочная точка доступа
4) SNR-CPE-AP2 – двухдиапазонная потолочная точка доступа с поддержкой 802.11AC
5) SNR-CPE-MD1.1 – модификация модели SNR-CPE-MD1 в новом корпусе (более эргономичный дизайн). Маршрутизатор имеет 3 независимых антенны: 2 для 2.4ГГц и 1 для 5ГГц (как следствие отказа от сплиттера 2.4ГГц+5ГГц в версии “MD1”), что позволило несколько выиграть в чувствительности тракта обоих диапазонов. Также применён новый FEM (Front End Module) для 5ГГц диапазона с улучшенными параметрами, что благоприятно сказалось на работе 802.11AC клиентов.
6) SNR-CPE-W2N – однодиапазонный маршрутизатор, производная модель от SNR-CPE-W4N (rev. M). В отличии от старшей версии, оснащен 2 LAN портами и внутренними антеннами, а также имеет лимитированный flash 4MB , что позволило создать экономичное решение для малых операторов связи, содержащее весь необходимый базовый функционал
7) SNR-CPE-ME1 – двухдиапазонный гигабитный маршрутизатор с поддержкой 802.11AC и USB 3.0.

Все устройства комплектовались (до марта 2019) ПО Wive-NG-MT.

Внимание!!! Сотрудничество между нами и компанией NAG завершено в феврале 2019г. Новые устройства с оригинальной Wive-NG-MT производиться не будут. По всем вопросам (включая доступность новых разработок и поддержку для юридических лиц, а так же переводу существующего оборудования на актуальную версию Wive-NG-HQ) обращайтесь по адресу info@wi-cat.ru .

Результаты тестирования производительности беспроводного сегмента в реальных условиях вы найдёте по ссылке.

Основной упор при разработке сделан на беспроблемную работу в необслуживаемом режиме. Единожды настроенное и установленное устройство должно проработать весь срок эксплуатации без необходимости вмешательства со стороны.

Все серийные устройства на базе ПО Wive-NG-mt имеют поддержку Handoff со стороны AP, что позволяет балансировать нагрузку между множеством точек доступа, управлять миграцией клиентов, т.о. решение подходит для построения сетей масштаба предприятия.

Реализация WPA Enterprise позволяет развернуть сквозную аутентификацию (для каждого пользователя используется своя пара логин/пароль), при этом в роли Radius сервера может выступать одна из AP. Также Radius может быть развёрнут на отдельном физическом сервере, что позволит, например, интегрировать управление доступом с другими сервисами, работающими на предприятии.

Поддержка Band Steering позволяет высвободить ресурсы 2.4ГГц сети, за счет вынуждения Dual Band клиентов использовать соединение в 5ГГц диапазоне, если это возможно. Тем самым , достигается оптимальное распределение загрузки между двумя радиомодулями двухдиапазонного устройства.

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

Поддержка HotSpot (coova chilli) с преднастроенными профилями, позволяет быстро и в полном соответствии с текущим законодательством развернуть точки доступа WiFi для клиентов вашей компании, гостей кафе или гостиниц.

И многое, многое другое. Подробнее по ссылкам выше.

Медиа: image / png

Wive-NG – это надёжная, встраиваемая операционная система на ядре Linux для беспроводных маршрутизаторов, которая родилась как средство для обеспечения отказоустойчивости эксплуатируемого автором оборудования.

Wive-NG не является кастомизированной сборкой WRT или иных OSS дистрибутивов встраиваемых операционных систем. Wive-NG базируется на собственных подходах и идеологии, позволяющих добиться максимально эффективного решения конкретного спектра задач, не распыляясь на поддержку всего и вся: как существующего в мире многообразия железа, так и функционала.

В процессе развития система переросла в коммерческий проект, результаты которого использует заметное число интернет-провайдеров на территории РФ в комплекте с ADSL/WiFi маршрутизаторами Acorp / SNR-CPE (NAG) / FT-AIR (Fibertool) / Wi-Cat (Synertau).

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

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

C Web интерфейсом можно ознакомиться используя Demo UI.

Далеко не полный список операторских сетей, в которых работает ПО Wive-NG.
Краткое описание отличий Wive-NG-HQ ветки ПО (поставляемой с завода с новым оборудованием начиная с 2020г.) от предыдущих веток.

Немного о нас:

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

Наши компетенции:
Полный цикл разработки встроенного ПО для сетевых устройств (беспроводные маршрутизаторы);
Разработка систем мониторинга и управления сетевыми устройствами;
Подбор аппаратной платформы, аудит готовых решений с внесением рекомендаций по оптимизации, сопровождение производственного цикла на контрактных производствах

Наши проекты:
Разработка свободной встраиваемой OS (Wive-NG) для устройств на чипе RTL8186 (2006-2008г.);

Разработка коммерческой встраиваемой OS (Wive-NG-DSL поставляется с завода) для ADSL модемов производства Acorp LAN410_v2, LAN110_v2, USB_v3, W422G_v3 / W422G_v4 / W510N / W520N / 532N (2009-2012г.);

Разработка коммерческой встраиваемой OS (Wive-NG-RTNL поставляется с завода) для сетевых беспроводных маршрутизаторов Acorp WR-150N / 300N / 300NU (2012-2014г.);

Доработка заводского ПО для планшетов (Android) и STB (ROS) производства компании Digma (2014-2015г);

Комплексная разработка серии беспроводных маршрутизаторов SNR-CPE* (от идеи до производства и пост продажной поддержки) на базе чипов Mediatek, включающая подбор аппаратной платформы и разработку встраиваемой OS (Wive-NG-mt поставляется с завода) для оборудования компании NAG (2015-2019г.);

Разработка ядра системы мониторинга и управления для устройств SNR-CPE* на базе Wive-NG-mt (Wive-NG-Control)

Комплексная разработка серии беспроводных маршрутизаторов FT-AIR* на базе чипов Mediatek, включающая подбор аппаратной платформы и разработку встраиваемой OS (Wive-NG-HQ поставляется с завода) для оборудования компании Fibertool (2019г.-2022г.);

Разработка серии беспроводных маршрутизаторов Wi-CAT* на базе чипов Mediatek, включающая подбор аппаратной платформы и разработку встраиваемой OS (Wive-NG-HQ поставляется с завода) для оборудования компании Synertau (2022г.- по настоящее время);

Подробнее о наборах логики и моделях устройств можно прочесть по адресу http://wive-ng.ru

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

Стоимость определяется после согласования сторонами всех нюансов проекта и зависит как от необходимых доработок, так и от запланированных объёмов.

Медиа: image / png