Wi-CAT LLCЧт, 28 мар
Wireless Comprehensive Advanced Technology. Build your network now.

 
 
1. Что изменится в жизни с 2024 года ;)Вт, 26 дек 2023[-/+]
Категория(?)  Автор(?)

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

Happy New Year

Компания 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. Немного рекомендаций относительно Wive-NGПн, 25 дек 2023[-/+]
Категория(?)  Автор(?)

Эта тема навеяна многочисленными инструкциями по настройке роутеров. И касается далеко не только Wive.

Немного рекомендаций относительно Wive-NG

YOUR MUST READ THIS !!!

Обновление:
1) старайтесь использовать свежую версию ПО, доступную через встроенную систему обновлений т.к. кроме исправлений ошибок, влияющих на стабильность, периодически также правятся и проблемы безопасности в тех или иных компонентах (например, в dropbear).
2) перед обновлением обязательно отключите все устройства от USB роутера и перезагрузите его по питанию, это дополнительно обезопасит процесс обновления. Особенно актуально если используется Entware
3) не заливайте в устройство стороннее ПО или версии для других устройств (например, в устройство без 5ГГц модуля – ПО с его поддержкой, в лучшем случае получите полуработающий WebUI и кашу в калибровках, что ведёт к разнообразным глюкам, в худшем – устройство может выйти из строя аппаратно, а заливка стороннего ПО запросто повредит индивидуальные калибровки радио и, как результат, приведёт к проблемам работы по радиоканалу). Тем более, что обновления для современного оборудования работающего под Wive не публикуются в бинарных сборках и доступны только через систему онлайн обновлений через WebUI маршрутизатора.
4) если у вас есть UPS то роутер лучше подключить через него
5) после обновления с заводской версии (а лучше и при переходе с любой достаточно старой ветки) желательно выполнить сброс кнопкой reset на корпусе устройства, удерживая её около 10сек с последующей настройкой через WebUI (не заливкой назад backup`а)
6) по мотивам http://help.powernet.com.ru/157-nastroyka-marshrutizatora-snr-cpe-md1.html Галка сброса RWFS НЕ ПРИВОДИТ К СБРОСУ НАСТРОЕК , за исключением настройки xupnpd и ещё пары демонов, которые имеют собственный интерфейс конфигурации. Снимать эту галку при обновлении ПО крайне не рекомендуется, т.к. не будут обновлены init скрипты. Снимать галку следует только если вы чётко понимаете, что делаете, и что после этого не возникнет проблем с логикой инита (определить можно только самостоятельно отследив все изменения в git на эту тему).

Wi-Fi:
1) при настройке никогда не меняйте непонятные вам параметры
2) если у вас нет B only устройств, используйте режим G/N, или же чистый N, если все ваши устройства поддерживают 802.11N (не включайте поддержку 802.11B без нужды, за последние 8 лет я лишь один раз видел устройство, поддерживающее только 802.11B и это был древний телефон на WinMobile6)
3) всегда используйте только чистые WPA2+AES режимы шифрования, смешанные WPA1/2 и TKIPAES режимы следует использовать только если у вас есть устройства, не поддерживающие WPA2AES
4) не используйте автовыбор канала (см. тему рядом) или используйте автовыбор в режиме “по уровню шума”.
5) Выбирая канал в 5ГГц диапазоне всегда проверяйте, что все ваши устройства могут работать, и работают корректно на выбранной частоте. К сожалению очень часто устройства имеют старые региональные ограничения в составе драйверов wi-fi, что может приводить к разнообразным проблемам, в т.ч. устройство может вообще не видеть точку доступа работающую на том или ином канале
6) Контролируйте реальную эффективную скорость работы на том или ином канале (например с помощью iperf). Не редко эффективная скорость передачи и стабильность соединения будет выше на занятых каналах. О природе этого явления постараюсь доступно рассказать в будущих публикациях. Пока стоит запомнить, что единственное доступное пользователю средство проверки, это не сканер эфира, а тест реальной пропускной способности
7) при использовании Dual Band устройств (таких как MD1/ME1), старайтесь использовать разные SSID для разных диапазонов, это убережет вас от всевозможных подземных стуков вызванных разнородностью реализации выбора диапазона клиентскими устройствами. Подробнее о проблематике можно прочесть в статье

Сеть:
1) настраивайте только то, что действительно требуется для полноценной работы с вашим оператором
2) не включайте поддержку IPv6, если ваш оператор не предоставляет такую услугу, либо вам она не нужна (то же самое касается и всего остального, не следует включать то, что ваш оператор не поддерживает)
3) если у вас на доступе туннель PPPOE/PPTP/L2TP, то в настройках Port forward (проброс портов) следует выбирать интерфейс VPN, а не WAN, если вы желаете протянуть порты в Internet, а не в локальную сеть.
4) если ваш оператор использует на доступе PPPOE без DHCP (например, Ростелеком или Эр-Телеком) , в настройках VPN необходимо включить Pure PPPoE.
5) если у вас наблюдаются проблемы с multicast iptv (задержки подписки или потери подписки) скорее всего это связано с некорректной обработкой IGMPv3 (несоответствием rfc3376 п8.12 на вышестоящем оборудовании). В таком случае следует в misc->iptv ограничить автовыбор версии IGMP второй версией.
6) В некоторых регионах Ростелеком использует для доступа к архиву видео и видео по запросу протокол RTSP. Для правильной работы которого за NAT требуется включить поддержку соответствующего ALG в настройках фаервола. В противном случае не будет работать как минимум перемотка.
7) Если вы наблюдаете проблемы с приложениями использующими UDP (например некоторые игры), попробуйте отключить разгрузку UDP. Дело в том, что в блоке HW_NAT (PPE) от Mediatek существует аппаратная ошибка с обработкой контрольных сумм в UDP. Поэтому в большинстве устройств разгрузка UDP полностью удалена. У нас же эта разгрузка работает т.к. удалось устранить проблемы со всеми известными сервисами не отказываясь от неё. Так же решено не отказываться от разгрузки UDP т.к. это может существенно увеличить нагрузку например при использовании uTP протокола используемого торрентом и который используется гораздо чаще чем вероятность встретить проблемное приложение.

По сервисам:
1) никогда не включайте непонятные вам сервисы
2) никогда не разрешайте без нужды доступ к сервисам роутера из WAN (например, разрешив udpxy принимать соединения с WAN интерфейса, очень скоро вы попадёте в списки халявных IP-TV прокси, ещё быстрее всю вашу полосу в интернет выгребут халявщики, смотрящие через вас IPTV).

USB:
1) не питайте от USB роутера всевозможный хлам типа USB нагревателей кофе или вентиляторов, светильников и прочего
2) крайне желательно использовать HDD с отдельным сетевым питанием, некоторые HDD потребляют просто неразумно много, и штатный БП роутера может запросто не вытянуть такой нагрузки, как результат – проблемы со стабильностью самого роутера, выход из строя БП или даже порча данных на HDD
3) использование USB3 устройств может заметно влиять на качество и дальность обслуживания клиентов в 2.4ГГц диапазоне из-за интерференции (подробности https://www.intel.com/content/www/us/en/io/universal-serial-bus/usb3-frequency-interference-paper.html)
4) используйте только качественные USB кабели небольшой длины
5) если используете роутер как файл-сервер, крайне рекомендуется использовать ext4 как FS (подробности)

Общие рекомендации:
1) Первым делом смените пароль (а лучше имя пользователя и пароль) на вход. Иначе имеете все шансы стать участником бот-сети (несмотря на то, что в прошивке я старался минимизировать такие шансы, даже если устройство скомпрометировали)
2) Всегда используйте хотя бы номинально криптостойкие пароли (не менее 8 символов в разном регистре + 4-6 цифр).
3) Для настройки используйте браузеры, поддерживающие рекомендации W3C (Firefox/Chrome/и т.д.), Internet Explorer в зависимости от версии может вести себя непредсказуемо, в силу подхода MS к его разработке в частности и поддержки стандартов вообще.
4) Также, крайне полезно будет добавить адрес роутера в исключения антивирусов, контент-фильтров и баннерорезалок, ибо эти заразы частенько дропают часть JS или даже соединения до встроенного web-сервера, отсюда тормоза и глюки web-интерфейса.
5) При зависании устройства наглухо (т.е. не перезагрузка устройства, а именно зависание, когда устройство перестаёт отзываться по сети как по проводу, так и по радио) первым делом проверяем БП. Если после замены на заведомо исправный БП проблема не прошла – отправляем в сервис. Глухой вис по вине ПО в Wive-NG практически исключён, так как даже если ещё ничего страшного не произошло, но был замечен какой-то сбой на уровне ядра, это приведёт к панике ядра и моментальной перезагрузке устройства во избежание, например, его компрометации. Т.е., далеко задолго до того, как устройство потенциально могло бы зависнуть, логика его перезагрузит при первом же подозрении , что что-то пошло не так. Также, можно включить аппаратный ватчдог (находиться в MISC), который перезагрузит устройство даже если сбой произошёл из-за проблем с питанием, т.е. не программная часть привела к зависанию, а какая-то внешняя сущность типа перегрева или скачка напряжения.

Проблемы совместимости, на которые мы повлиять не можем т.к. проблема на клиентской стороне:
1) Некоторые устройства не могут корректно работать с каналами выше 11-го в 2.4ГГц диапазоне, или могут не работать с какими-то (одному вендору их известно какими именно) каналами в 5ГГц, поэтому если устройство не может соединиться или вовсе не видит AP (точку доступа), следует попробовать первым делом сменить канал.

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

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

2) Также, у некоторых мобильных устройств наблюдаются проблемы с 80МГц полосой в 802.11ac режиме. Например, Smasung Galaxy S5 (поправлено в последних официальных прошивках самсунга), часть яблочной продукции (iphone 6 и macbook air 2012-2013г выпуска). Всех их объединяет использование в качестве радио BCM4345x от Broadcom вкупе с драйвером версии, выпущенной до КРОС 2.0-17 (конец мая 2017) ;)

Выглядит это как отсутствие передачи данных при живом подключении или очень низкая скорость. От AP это не зависит. Решение – отключить поддержку 80МГц полосы для 802.11ac (естественно, у всех устройств, которые корректно работали с 80МГц полосой, реальная скорость передачи упадёт примерно вдвое).

Братья по несчастью живут тут:
a) https://discussions.apple.com/thread/6687368
b) https://discussions.apple.com/message/27134380#27134380
c) https://tinkertry.com/if-youre-using-a-802-11ac-wifi-device-you-may-want-to-avoid-80mhz-channel-width и тут http://forums.macrumors.com/threads/wi-fi-is-super-slow-on-80mhz.1861397/

Данная проблема не является проблемой роутера!
Ошибка кроется в драйвере BCM на клиентской стороне (см. ссылки выше по ровно тем же проблемам с роутерами других вендоров на абсолютно разных чипах).

В бяке замечена почти исключительно техника Apple. И несмотря на то, что проблема старая и яблоки могли бы её решить уже очень давно, заблокировав 80МГц полосу на клиентской стороне или просто обновив драйвер BCM для этих устройств (достоверно известно, что текущий драйвер для новых чипов, используемых в Iphone7, и более новых, не имеет этой проблемы и поддерживает чип, установленный в Iphone6) яблоки попросту забили на это. Видимо, с целью стимуляции пользователя к покупке новых устройств.
Впрочем, это не единственный метод – например, на старых девайсах можно принудительно уронить производительность (пруф: https://lenta.ru/news/2017/12/21/apple/). На мой взгляд, это называется кидалово. Но тут дело каждого.=)

Начиная с версии 6.1.5 (MT ветки) был добавлен воркэрануд : устройства Iphone6, huawei honor P8/P9 на тех же радио-чипах, что и iphone 6, и ряд других устройств , на которых проявляется проблема, будут автоматически лимитированы 40МГц полосой. Это меньшее из зол (позволяет не отключать 80МГц и позволить клиентам без данной ошибки использовать преимущество широких каналов).

Если у вас наблюдается подобная проблема – скиньте название устройства, год выпуска, MAC адрес (что бы выделить OUI, т.к. именно по нему определяется, для кого включать лимит) и детальное описание включая лог и Stalist с AP мне в приват.

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

3) У части устройств (например, Samsung J100F, на текущий момент самсунг устранил проблему с очередным обновлением) наблюдается ошибка реализации FastRoaming: они пытаются всегда использовать короткую процедуру при включенном FT на AP, хотя первое соединение обязано проходить по полной схеме. В итоге, не могут подключиться и просто пишут “сохранено”. Выход – отключить Fast Transition 802.11R (да и вообще не следует включать роуминговые расширения при использовании одной AP).

4) У старых устройств могут возникать проблемы с Protected Managment Frames из-за не полной реализации PMF на их стороне. Решение – отключить PMF, но лучше запланировать замену таких устройств. В современном мире безопасность играет очень важную роль, а отключение PMF снижает защищённость до уровня вашего старого роутера который PMF по просту не умеет (потому с ним и работало). К сожалению PMF редкий гость на домашних маршрутизаторах и обязателен только для WPA3, это и привело к плачебному положению дел с поддежкой PMF на клиентах (яркий пример младшая Yandex станция или их же розетки).

5) Ещё в более редких случаях и старых клиентах могут возникать проблемы при активированном BCN (Beacon Protection) Protect. Выглядит как подключение на несколько секунд с последующей деаутентификацией (замечено на одной из версий драйверов на карте i7260).

6) У SGS A01 (возможно у каких-то ещё моделей) замечена проблема в виде отсутствия соединения при включенном 802.11R и выключенной поддержки FT over DS. Выглядит как ругань на неверный пароль. Проблема в том, что устройство анонсирует поддержку обоих режимов FT (over DS и over AIR), но умеет по факту только over DS. В итоге не может соединиться вообще. Выхода 3. Первый – включить FT over DS на стороне роутера/ТД, что может сломать совместимость с некоторыми другими клиентами (увы есть преценденты). Второй – отказаться от 802.11r, что несколько ухудшит миграцию. Однако лучшее решение написать в самсунг с описанием проблемы, возможно они её починят ;).

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

Для тех кто дочитал до конца. Крайне рекомендуем приобрести UPS для роутера. Цена от $10 https://aliexpress.ru/w/wholesale-Wifi-router-ups.html, а пользы море. От 100% безопасного обновления, до возможности использования wifi при отключении электроэнергии (почти у всех провайдеров питание их домового оборудования в 2021г резервируется по питанию), снижение зависимости работы от качества сети питания (увы в РФ питающие сети оставляют желать лушчего)

P.S. Огромная просьба ко всем пользователям Apple. Прежде чем писать нам о ваших проблемах, проверьте, нет ли сходных проблем с роутерами других вендоров, работающих в тех же режимах. Почти все проблемы wifi в apple лежат на стороне Apple. Увы и ах. И именно у вас есть полное право долбить Apple до победного пока они не исправят свои косяки. Вы заплатили им денег за эксклюзивную игрушку – пусть отрабатывают. Иначе, получается так, что Apple косячит, а остальные вынуждены подстраиваться и городить воркэраунды, в простонародье обзываемые костылями, или ограничивать возможности радио, что неминуемо сказывается на производительности радиосегмента с нормальными клиентами.


Медиа: image / jpeg


3. Wi-Cat-AX – новый маршрутизатор под управлением Wive-NG-HQ.Сб, 23 июл 2022[-/+]
Категория(?)  Автор(?)


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

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

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

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

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

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

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

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

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

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

Wifi 6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В т.ч. расширенные средства диагностики беспроводного сегмента, дополнительные настройки радиомодуля (необходимые, например при построенииRadioinfo Page 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:

ЗагрузчикЗагрузка...
Логотип EADСлишком долго?

ПерезагрузкаПерезагрузить документ
| ОткрытьОткрыть в новой вкладке

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

Медиа: image / jpeg


4. Импортозамещение, куда же теперь без этого популярного нынче слова..?Пт, 15 июл 2022[-/+]
Категория(?)  Автор(?)

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

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

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

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

OutdoorCeil

Медиа: image / jpeg


5. Роуминг (миграция клиентов между ТД) в Wi-Fi сетях — Часть 6 — Пример критериев выбора кандидата для миграцииЧт, 10 фев 2022[-/+]
Категория(?)  Автор(?)
К сожалению 802.11 как стандарт не имеет явных требований к критериям выбора кандидата для миграции, в итоге каждый чипмэйкер (а то и вендор) реализует этот момент в силу своей фантазии. Этим и обусловлено различное поведение при миграции от устройства к устройству. Сегодня рассмотрим один из вариантов на примере кода клиентов от MTK. Этот код используется в проприетарных драйверах МТК (почти все планшеты и телефоны на МТК используют именно такие драйвера). Смыл его в том, что бы выбрать из списка сканирования кандидата для переключения/миграции. Т.е. именно выбор такой ТД на которую мы с большой долей вероятности сможем максимально безболезненно и с наименьшими затратами времени прыгнуть . Не когда, а куда Вот в чём вопрос ;) Функция FT_CheckForRoaming (используется в случае поддержки 802.11r с обеих сторон). Опустим все объявления и т.д. оставим только условия. if (pBss->bHasMDIE== FALSE) continue; /* skip legacy AP */ if (pApEntry MAC_ADDR_EQUAL(pBss->Bssid, pApEntry->Addr)) continue; /* skip current AP */ if (!FT_MDID_EQU(pBss->FT_MDIE.MdId, pAd->StaCfg[0].Dot11RCommInfo.MdIeInfo.MdId)) continue; /* skip different MDID */ if ((pBss->Rssi Channel== wdev->channel)) continue; /* skip RSSI too weak at the same channel */ if ((pBss->Channel != wdev->channel) (pBss->FT_MDIE.FtCapPlc.field.FtOverDs== FALSE)) continue; /* skip AP in different channel without supporting FtOverDs */ max_rssi= RTMPMaxRssi(pAd, pAd->StaCfg[0].RssiSample.LastRssi[0], pAd->StaCfg[0].RssiSample.LastRssi[1], pAd->StaCfg[0].RssiSample.LastRssi[2]); if (pBss->Rssi < (max_rssi + RSSI_DELTA)) continue; /* skip AP without better RSSI */ if ((pBss->AKMMap != wdev->SecConfig.AKMMap) || (pBss->PairwiseCipher != wdev->SecConfig.PairwiseCipher)) continue; /* skip different Security Setting */ И так. Мы в цикле (здесь он опущен, весь код выше собственно в теле цикла) перебираем всех кандидатов (они уже отсортированы по уровню) перемещая оных в отдельный массив. А выше условия исключения из подходящих. 1) пропускаем все ТД которые не анонсируют Mobile Domain 2) пропускаем собственную ТД (т.к. наш адаптер может быть и точкой доступа и клиентом одновременно) 3) пропускаем ТД с отличным от текущего MobileDomain 4) сразу отфильтровываем все ТД с уровнями ниже -85 работающих на том же канале, что и текущая 5) пропускаем ТД работающие на смежных каналах без поддержки Fast Transition Roaming over DS (подробнее о FT) 6) берём rssi, тот с которым слышим текущую ТД, и если у кандидата RSSI ниже чем текущий RSSI + 5dBm выбраковываем и его 7) ну и наконец сравниваем настройки шифрования и аутентификации, любое отличие в них приведёт к отказу в использовании FT для роуминга Едем дальше. А что если не нашлось кандидата для миграции с FT (802.11r)? Для этого есть отдельная логика которая попытается подобрать нам кандидата для миграции без использования 802.11r (да,сама фаза переключения будет чуть дольше т.к. фаза аутентификации должна быть снова пройдена целиком). Функция MlmeCheckForFastRoaming (так же опущено всё кроме критериев, тут их меньше): if ((pBss->Rssi Channel== wdev->channel)) continue; /* RSSI too weak. forget it.*/ if (MAC_ADDR_EQUAL(pBss->Bssid, pStaCfg->Bssid)) continue; /* skip current AP*/ if (!SSID_EQUAL(pBss->Ssid, pBss->SsidLen, pStaCfg->Ssid, pStaCfg->SsidLen)) continue; /* skip different SSID*/ max_rssi= RTMPMaxRssi(pAd, pStaCfg->RssiSample.LastRssi[0], pStaCfg->RssiSample.LastRssi[1], pStaCfg->RssiSample.LastRssi[2]); if (pBss->Rssi < (max_rssi + RSSI_DELTA)) continue; /* skip AP without better RSSI*/ фильтруем все ТД чей уровень ниже -50 (что-то они переборщили, я бы -60 выставил) работающих на том же канале, что и текущая фильтруем себя (ТД+Клиент режим) фильтруем ТД с отличающимися от текущего SSID берём rssi, т.е. тот с которым слышим текущую ТД, и если у кандидата RSSI ниже чем текущий RSSI + 5dBm выбраковываем и его Миграция по схеме без 802.11r конечно не говорит о том, что в таких конфигурациях прощай бесшовность. Абсолютно нет. Но процедура аутентификации будет при каждой миграции будет осуществляться целиком (все 4ре стадии). Плюс добавится критерий RSSI на кандидате > -50. Т.е. процедура миграции будет запущена заметно позже чем в случае с 802.11r. А вызывается оно вот таким вот макаром: #ifdef DOT11R_FT_SUPPORT if (pStaCfg->Dot11RCommInfo.bFtSupport pStaCfg->Dot11RCommInfo.bInMobilityDomain) rv= FT_CheckForRoaming(pAd, wdev); #endif /* DOT11R_FT_SUPPORT */ /* Add auto seamless roaming*/ if (rv== FALSE) rv= MlmeCheckForFastRoaming(pAd, wdev); Т.е. если включена поддержка FT и задан MD то дёргаем FT_CheckForRoaming. Если кандидат не найден пробуем дёрнуть MlmeCheckForFastRoaming. Если FT отключено, то сразу зовём MlmeCheckForFastRoaming. Следует обратить внимание на 4 момента: 1) в случае FT не сверяется SSID на текущей и кандидате, вместо этого всегда используется MobileDomain 2) без поддержки Over DS (что, из практики, почти всегда так) при миграции между ТД на разных каналах и тем более диапазонах никакого 802.11r не будет 3) режимы шифрования должны совпадать чётко на всех узлах ибо сравниваются в лоб 4) наличие R меняет не только процедуру миграции, но и критерии выбора кандидата, и как следствие целиком поведение клиента Вот такой вот бубуль гум. Это всего лишь один частный пример реализации. У QCA и BCM там собственные навороты. Не помню у кого (у QCA по-моему) там целая бальная оценка в зависимости от возможностей ТД. Надеюсь в будущем будет свободное время распишу с примерами кода. Но МТК при миграции рассуждает именно так ;) Всем удачи в строительстве качественных решений. P.S. К вопросу о пользе заглядывать в код клиента перед проектированием сети, жаль редко возможно. ;) Часть 5

Медиа: image / jpeg


6. ЗаMES`Шательство…Пт, 19 ноя 2021[-/+]
Категория(?)  Автор(?)

Hibryd Mesh Distribution SystemПричиной для написания этой заметки стала очередная итерация обсуждения с потенциальными заказчиками функционала ПО.

Когда в очередной раз я услышал, что Wive не умеет MESH, то сразу же задал встречный вопрос в формате «а что вы под MESH подразумеваете и какую задачу хотите им решить?».

Чем привёл оппонента в замешательство, “ну ведь все же знают”, казалось думал он, но боялся сказать в слух…

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


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

1. Терминология, реализация, маркетинг
2. Настройка сети с бесшовным роумингом (то что чаще всего, хотя и не верно, сейчас подразумевают произнося аббревиатуру MESH в слух) между узлами не зависимо от организации опорной сети (DS, хоть провод, хоть воздух). Т.е. целую статью о 3х (хорошо 5ти) галочках в Web интерфейса Wive необходимых для этого.
3. HandOff -> расширенный инструментарий для того что бы заставить мигрировать (пусть и не всегда бесшовно) старые (не умеющих handover) или особенно кривые (безродные китайцы с али как пример) клиентские устройства.

Networks Topology OverwievПоехали.

Открываем Wiki и сразу же попадаем на самую верную формулировку:
«Ячеистая топология(mesh-сеть) – сетевая топология компьютерной сети, построенная на принципе ячеек, в которой рабочие станции сети соединяются друг с другом и способны принимать на себя роль коммутатора для остальных участников. Данная организация сети является достаточно сложной в настройке.
Однако при такой топологии реализуется высокая отказоустойчивость. Как правило, узлы соединяются по принципу «каждый с каждым».
Таким образом, большое количество связей обеспечивает широкий выбор маршрута трафика внутри сети — следовательно, обрыв одного соединения не нарушит функционирования сети в целом.»

Optical Mesh Distribution SystemВажные отличия от просто плоской сети выделены жирным.

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

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

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

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

Ethernet Mesh Distribution SystemДля wifi принят как стандарт только один такой протокол 802.11s.

Правда уже мало похоже на то, что вы понимаете под MESH?

А всё потому, что смешивание мух с котлетами излюбленный муркетологами ход и ничего более….

Как муркетолухам удалось связать несвязуемое и впихнуть невпихуемое даже не спрашивайте. Но по факту аббревиатура MESH (из уст заказчиков и пользователей) стала означать по сути банальную MultiAP сеть. Почему-то обязательно с поддержкой роуминга (802.11k/r/v) и возможно ещё какими-то плюшками (часто с около нулевой полезностью)… Но об этом чуть ниже.

Вы наверное уже догадались, что большинство устройств с заявленной поддержкой MESH не подпадает под это определение данное в Wikipedia и не поддерживают 802.11s. Уже просто потому что не умеет ни выбора маршрутов сложнее чем просто переключиться провод/беспровод (используя STP или иные костыли, а часто и этого не умеет), а клиентские устройства не могут и близко быть полноценными участниками MESH сети и брать на себя какие-то доп функции.

В общем подробнее о True MESH можно почитать тут https://en.wikipedia.org/wiki/IEEE_802.11s , а мы будем разбираться с реалиями.

Wi-FI RoamingЧто же имел в виду пользователь/заказчик?

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

В 99% случаев (из моей личной практики и практики коллег в т.ч. интеграторов) все приходящие клиенты начинающие разговор с “мне нужен MESH” имели в виду MultiAP сеть с бесшовным роумингом.

И MESH тут как бы сбоку. Т.е. абсолютно. ;)

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

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

Если есть WiFi, то обычно добавляется требование что бы SSID на всех точках доступа был одинаковый, как и настройки авторизации/аутентификации/шифрования, что бы клиент при определённых условиях, используя handover смог переключиться на соседнюю AP и для него так же бы ничего бы не изменилось.

Кстати для этого желательно, что бы AP и клиенты поддерживали 802.11r, и особенно важно что бы AP анонсировали в этом ключе Mobile Domain который кроме того что является наравне с SSID фактором для выбора кандидата для миграции (MDIE как и SSID должны быть одинаковы на всех узлах ибо это в первую очередь признак что AP принадлежат одной сети) подсказывает клиентам что такие точки доступа не просто отдельные устройства, а единая сеть.

Ускорение аутентификации за счёт 802.11r в данном случае вторично и в PSK сетях (а дома у вас именно они) в общем-то почти ничего не даёт.

Так же не лишней была бы и поддержка 802.11k и 802.11v. Но это уже тема из других статей (см раздел роуминг).

Отмечу, выше не зря ни сказано ни слова о том как организована опорная сеть (DS). Ибо это не важно абсолютно.

Варианты могут быть как проводом (обычная эзернет сеть между всеми ТД собранная в один коммутатор, рекомендуемый вариант), так и беспроводом (APCLI/WDS/etc), смешанной, где часть узлов объеденные проводом, часть по воздуху.

Или же вообще каждая ТД может иметь свой канал в мир (например через LTE модемы, причём даже разных сотовых операторов), а что бы получить единое L2 связное пространство может быть использован один из вариантов L2 туннелирования (L2TPv3 как пример) со сборкой сети на выделенном сервере (можно даже на VPS в зимбабве).

Единственное что нужно помнить при организации DS (кроме уже сказанного выше), так это то, что АП общаются между собой по средствам iaap (802.11f) и задержки тут критичны.

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

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

Seamless Roaming Wifi Network with Start DSТак что же по факту требуеТся с точки зрения организации и настройки:

1) маршрутизатор на входе который собсно будет предоставлять нам выход в мир, рулить по DHCP адресами и т.д.
2) коммутатор куда воткнуты все ТД (можно использовать коммутатор встроенный в маршрутизатор если портов хватает)
3) нужное количество ТД куда будут подключаться клиенты
4) на всех устройствах ТД и роутере должны быть заданы одинаковые параметры аутентификации, SSID. По возможности должна быть включена поддержка 802.11k/r/v (настройки на всех узлах для этих протоколов включая Mobile Domain) должны совпадать
5) там где нельзя (крайне редко, чаще просто лень) проложить кабель используем любую схему организации DS по воздуху (APCLI/WDS/etc), но лучше избегать DS по воздуху вообще.

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

Умеет ли всё это Wive-NG? Ну вообще-то да. Более того умеет как минимум 8 лет как (а может и больше). И именно мы предоставили поддержку 802.11k/r на младших чипах от МТК в сверх бюджетных маршрутизаторах из коробки первыми как минимум в РФ. ;)

Даже больше скажу. Wive-NG умеет много больше и некоторые вещи скрыты от глаз и вообще не требуют настройки, однако существенно повышают шансы на бесшовную миграцию между узлами под управлением Wive. ;)

Вся настройка сводится к переключению нужного числа устройств в режим АП и простым действиям описанным выше…

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

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

P.S. В Wive такие сети традиционно носят название Multi AP Networks. ;) И не требуют для обеспечения бесшовного роуминга никаких контроллеров, или “меш систем” с “проводными репитерами” и прочими маркетинговыми названиями для простых вещей типа точек доступа. Терминологический ад разводимый маркетологами к сожалению уже вышел за грани разумного. Будем по возможности избегать оного.

P.S2. После публикации коллеги подкинули мне ещё мнение. Типа MESH обязательно подразумевает что DS поднята по радио. Ну вообще-то DS по радио называется WDS ;) Во вторых MESH это топология сети, и в ней вообще может не быть радио. ;)

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

Кстати Самоорганизующиеся сети типа Yggdrasil тоже вполне себе MESH и они в разы ближе к MESH чем всё то, что представлено на рынке SOHO/SMB wifi. Но статья не о том, а о подмене понятий. А именно, что MESH, с подачи маркетологов, с точки зрения потребителя, обозначает всё что угодно, только не то что должно. ;)

Увы, но с этим придётся жить…

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

Существуют кейзы где MESH (в т.ч. гибридный провод, беспровод и ещё какой в кучу) применим и полезен. Но это не SOHO и не SMB. Ну и понимание того какую проблему решаем и почему именно так решаем, какие вылезут грабли (и т.д. и т.п.) быть обязано.

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

P.S3 Немного линков:
1) Стандарт https://en.wikipedia.org/wiki/IEEE_802.11s
2) Эволюция Mobile Mesh Networks https://www.researchgate.net/publication
3) SMS MESH сеть https://hackaday.io/project/176138-mesh-gateway Внезапно?;)
4) LAN MESH сеть https://techhub.hpe.com/eginfolib/networking/docs/switches/K-KA-KB/15-18/atmg/content/ch06s07.html
5) BT MESH https://en.wikipedia.org/wiki/Bluetooth_mesh_networking
6) Optical MESH https://en.wikipedia.org/wiki/Optical_mesh_network

Медиа: image / png


7. Заморозка кода и новые устройства.Пн, 15 ноя 2021[-/+]
Категория(?)  Автор(?)

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

В 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) множество более мелких изменений, а так же добавление функционала под заказ партнёров

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

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

Шутка ли, проект за 1,5Гб исходного кода (суммарно) перешагнул.

Комментарии к минорным выпускам (и другие заметки/анонсы) можно видеть на нашем телеграм канале.

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

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

Медиа: image / jpeg


8. Важный выпуск Wive-NG-HQВт, 26 окт 2021[-/+]
Категория(?)  Автор(?)

Fragattack

Ни для кого не секрет, что при разработке 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


9. Wireless-CAT в Telegram.Ср, 29 сен 2021[-/+]
Категория(?)  Автор(?)

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

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

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

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

Медиа: image / png


10. About Wive-NG-HQЧт, 09 апр 2020[-/+]
Категория(?)  Автор(?)

Wive-NG-HQ - новое поколение встраиваемых ОС семейства wive-ng / new embedded OS wive-ng-hqWive-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


11. Обзор двухдиапазонного FE роутера FT-AIR-DUO-F (Wave2 AC1200)Пн, 06 апр 2020[-/+]
Категория(?)  Автор(?)

wi-fi роутер FT-AIR-DUO-FFT-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


12. Обзор гигабитного роутера FT-AIR-DUO-G (Wave2 AC1300)Чт, 02 апр 2020[-/+]
Категория(?)  Автор(?)

wi-fi роутер FT-AIR-DUO-G

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


13. WPA-Enterprise в Wive-NG для работы в сетях с 802.1x (RADIUS) авторизациейВс, 06 окт 2019[-/+]
Категория(?)  Автор(?)

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

radius 802.1x scheme

Работа 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, что является дефолтным значением в рамках стандарта.

Wpaset

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

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

Android

Пример настройки 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, потому как именно она является наиболее универсальной и поддерживаемой на любых устройствах.

Radiusset

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

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

Медиа: image / png


14. Автоматическая проверка обновлений в Wive-NGВт, 28 мая 2019[-/+]
Категория(?)  Автор(?)

Wive-NG Firmware Auto Update

Чтобы всегда оставаться на актуальной версии ПО было ещё удобнее, мы запустили сервис автоматической проверки наличия обновлений (доступно начиная с 8.1.х версии). Теперь, чтобы обновиться, достаточно зайти в web-интерфейс Wive-NG и проверить наличие информации о доступности более “свежей” версии (либо та, что загружена на данный момент,- актуальна). Информация о наличии обновлений реализована в виде уведомления в верхней части интерфейса, а также содержится в соответствующем блоке на странице управления устройством. В случае наличия обновления достаточно нажать “Обновить“, после чего версия ПО, соответствующая модели устройства, будет автоматически загружена на маршрутизатор и установлена.

firmare update notification

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

Firmware update check

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

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

Медиа: image / png


15. Когда нет ipv6, но очень хочется. Настраиваем 6in4 через туннельного брокера ipv6.Чт, 14 мар 2019[-/+]
Категория(?)  Автор(?)

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

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

register at ipv6 brocker

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

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

successfully registered

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

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

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

6in4 details

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

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

6in4 details

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

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

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

ipv6 6to4 enable

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

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

6to4 settings at wive-ng

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

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

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

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

ipv6 enable at windows os

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

ipv6 status at windows os

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

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

ipv6 tunnel success

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

Медиа: image / png


16. Роуминг (миграция клиентов между ТД) в Wi-Fi сетях — Часть 5 — Организация опорной сетиСб, 02 мар 2019[-/+]
Категория(?)  Автор(?)

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

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

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

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

  • Самый частый (и правильный) случай – это банальная кабельная сеть, связывающая все AP и шлюз в мир в единую сеть.
  • Второй вариант – использование WDS/APCLI. По сути то же самое, но по воздуху без использования кабельной ифраструктуры (частным случаем является MESH — тут мы будем говорить о конкретном и единственном стандартизованном варианте 802.11s. По сути в нашем случае ничем не отличается от WDS, и дальше будет пояснено почему).
  • Гибридные схемы. Например, разные 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) , эти подходы не меняются и для полноценной прозрачной миграции являются необходимостью.

Пара слов О MESH

На текущий момент нет ни одного клиента (смартфона/ноутбука и т. д.), который может быть непосредственным участником MESH-сети. Таковые только заявлены, причём со стороны чипмэйкров. Например, MTK 8 января 2019г заявил, что новые SOC для телефонов (включающие в себя wifi) смогут быть непосредственно клиентами MESH сети. А значит, все те же требования накладываются и на MESH, что сужает его возможные преимущества до так называемого Smart WDS (как недавно было модно у чипмэйкеров) или, как это называет Asus, AI MESH. Т.е. MESH используется исключительно как WDS между AP (не стоит путать MESH как технологию реализации аплинка AP и механизмы, обеспечивающие миграцию клиентов между AP). Клиенты используют всё те же механизмы, AP точно так же гоняют IAPP между собой и всё так же необходима L2 связность между AP, в то время как клиентов между собой можно и изолировать. Как конкретно внутри устроен этот самый DS значения в таком ключе не имеет абсолютно, лишь бы соблюдались требования, изложенные выше.

Подробнее MESH (на примере 802.11s) в схемах с миграцией рассмотрим в одной из следующих статей.

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

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

Лучшая 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


17. Эмулятор Web интерфейса (WEB UI) Wive-NGВт, 26 фев 2019[-/+]
Категория(?)  Автор(?)

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

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

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

Медиа: image / jpeg


18. Настройка DNS сервисов Wive-NG – часть 2 – локальные DNS сервисы, DNSSEC, альтернативные DNSЧт, 21 фев 2019[-/+]
Категория(?)  Автор(?)

dnssec

Помимо контент-фильтрации на уровне 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.

local dns at wive-ng-mt

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

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

static MAC IP

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

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

locat dns entry

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

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

ping to check local access by domain name

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

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

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

redirect to local dns

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

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

Функционал DNSSEC

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

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

dnssec enable at wive-ng-mt

Включение 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. Схематически, процесс выглядит так:

scheme of dnssec

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

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

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

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

upstream dns for correct dnssec work

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

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

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

Медиа: image / png


19. Настройка DNS сервисов Wive-NG – часть 1 – Ad Blocking и фильтрация по доменуПн, 28 янв 2019[-/+]
Категория(?)  Автор(?)

adblock

Adblock это механизм основная цель которого — заблокировать рекламу, malware и другой нежелательный контент. Также стала доступна контент-фильтрация на уровне DNS.

Чтобы включить Ad Block, необходимо перейти в раздел Services -> DNS Services (Сервисы ->Службы DNS) и включить Ad Blocking (Блокировка рекламы).

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

Adblock / ads blocking feature enabled

Включение функционала Ad Blocking

При успешном запуске сервиса, помимо статуса work в web-интерфейсе, в логе появится запись:

Jan 22 15:03:09 adblock: Get ad hosts lists from https://schakal.ru/hosts/alive_hosts_ru_com.txt

Jan 22 15:03:11 adblock: Get ad hosts lists from http://winhelp2002.mvps.org/hosts.txt

Jan 22 15:03:13 adblock: Get ad hosts lists from https://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&showintro=0&mimetype=plaintext

Jan 22 15:03:14 adblock: Get ad hosts lists from http://www.malwaredomainlist.com/hostslist/hosts.txt

Jan 22 15:03:15 adblock: Filter records.

Jan 22 15:03:42 adblock: Remove duplicated records.

Jan 22 15:04:01 adblock: 66856 domains blocked by DNS.

Jan 22 15:04:01 adblock: Next adblock update after 24h.

Из лога видно, с каких ресурсов была взята информация о вредоносных хостах, количество доменов, заблокированных посредством DNS. Также, сообщается, что период обновления списка — 24 часа.

В консоли сформированный список можно просмотреть следующим образом:

[Wive-NG-MT@]# cat /etc/dnsmasq.d/ads.conf

– Есть ли исключения из блокировок?

Да, в основном это счётчики, отключение которых препятствует сбору статистик для SEO, а также нередко искажает отображение страницы. Исключения на данный момент такие:

unblocklist="liveinternet.ru|counter.yadro.ru|^yadro.ru|top100.ru|mc.yandex.ru|metrika|openstat.net"

unblocklist="$unblocklist|google-analytics.com|googletagmanager.com|^stats.g.doubleclick.net|clustrmaps.com"

– Что делать, если заблокировалось что-то нужное?

Предположим, после включения adblock перестали открываться какие-то используемые ресурсы, и вы обнаружили их в списке /etc/dnsmasq.d/ads.conf . Пример: если мы хотим просматривать сайт http://news.gnezdo.ru/ , то при возникновении проблем проверяем, не попал ли он в список блокировок командой:

[Wive-NG-MT@/]# cat /etc/dnsmasq.d/ads.conf | grep -i gnezdo
blocked host by ad block using ads list

Пример ресурса, автоматически заблокированного в соответствии со списками запрещенных хостов Ad Block

В этом случае, необходимо создать пользовательское исключение:

allow rule of content filter

Разрешающее правило контент-фильтрации

где в поле Domain Name / Доменное имя (1) указывается домен, который необходимо разрешить, в поле Action / Действие (2) указывается действие — в данном случае Allow (разрешить). Далее добавляем созданное правило соответствующей кнопкой (3).

Вновь созданное правило появится в блоке DNS Content Filter Exceptions (Исключения блокировки рекламы).

Чтобы сохранить изменения, необходимо нажать Apply внизу страницы. Для того, чтобы правило вступило в силу, необходимо дождаться перехода Ad Block в статус work (изначально, статус будет started) либо перезагрузить устройство.

allow rule at user list of content filterint

Пример разрешающего правила в списке пользовательских исключений контент-фильтрации

После этого интересующий нас ресурс станет доступен. Из списка ads.conf адрес-исключение (в нашем случае news.gnezdo.ru) исчезнет.

ads host unblocked by user allow rule

После добавления разрешающего правила ресурс вновь доступен

– Что делать, если нужно заблокировать конкретный домен?

Блокировка ресурсов по доменному имени производится также с помощью пользовательских правил DNS Content Filter Exception (Исключения блокировки рекламы). Пример: мы хотим ограничить доступ к сайту e1.ru. По аналогии с предыдущим примером вводится целевое доменное имя, только в качестве действия вместо Allow выбираем Block (Блокировать). После вступления правила в силу доступ к сайту e1.ru прекратится, причем как по http, так и по https.

– Как заблокировать рекламу на странице, которая не заблокировалась автоматически?

Предположим, нам не нужно блокировать полностью доступ к сайту. Но реклама, которой заполнена страница, значительно мешает просмотру контента. Автоматически при включении ad block реклама никуда не исчезла, из чего делаем вывод, что в списках блокировок DNS нет адресов, которые являются поставщиками рекламных баннеров.
Чтобы избавиться от такой рекламы, достаточно посмотреть адреса-источники нежелательного контента и внести их в список DNS Content Filter Exception (Исключения блокировки рекламы) с действием Block. Например, если нам докучает Яндекс.Директ, то создание правила an.yandex.ru / Block решит проблему.

– Что делать, если пользователь пропишет DNS локально на своем устройстве для обхода блокировок?

В этом случае ранее заблокированный e1.ru вновь станет доступен. Чтобы избежать такой ситуации, следует включить редирект всех DNS запросов на локальный DNS роутера. Тогда все запросы будут обрабатываться в соответствии с блокировками, включенными на роутере (понятное дело, что подобный метод не защищает нас от VPN и других ухищрений).

redirect to local dns

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

Список всех пользовательских исключений хранится в файле /etc/dnsmasq.d/userblock.conf

Медиа: image / jpeg


20. AUN D7 and AMPAK AP6255 (bcm43455c0) disconnects fixСр, 02 янв 2019[-/+]
Категория(?)  Автор(?)

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

Потратив несколько вечеров гуглежа и определившись с пределом ценника и хотелками, остановил свой выбор на 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


21. Антенны и дураки. Основы антенных устройств.Ср, 12 дек 2018[-/+]
Категория(?)  Автор(?)

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

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

Медиа: image / jpeg


22. Спамроутер! Очередная атака на домашние маршрутизаторы.Чт, 29 ноя 2018[-/+]
Категория(?)  Автор(?)
Исследователиrouter spam bot из группы Qihoo 360 обнаружили ботнет BCMUPnP_Hunter, заражающий роутеры на чипах BroadCom. Ботнет использует старую уязвимость UPnP, которая позволяет выполнить произвольный код с правами системы. Вирус занимается рассылкой спама, а также служит прокси для самих хакеров.

В списке уязвимых устройств есть в том числе и популярный в России D-Link DSL-2640.
Сейчас число зараженных роутеров превысило 100 тысяч.

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

Источники на русском:
https://www.linux.org.ru/news/security/14626066
https://xakep.ru/2018/11/12/bcmupnp_hunter/

Оригинал http://blog.netlab.360.com/bcmpupnp_hunter-a-100k-botnet-turns-home-routers-to-email-spammers-en/

Смотрим список заражённых:

ADB Broadband S.p.A, HomeStation ADSL Router 
ADB Broadband, ADB ADSL Router 
ADBB, ADB ADSL Router 
ALSiTEC, Broadcom ADSL Router 
ASB, ADSL Router 
ASB, ChinaNet EPON Router 
ASB, ChinaTelecom E8C(EPON) Gateway 
Actiontec, Actiontec GT784WN 
Actiontec, Verizon ADSL Router 
BEC Technologies Inc., Broadcom ADSL Router 
Best IT World India Pvt. Ltd., 150M Wireless-N ADSL2+ Router 
Best IT World India Pvt. Ltd., iB-WRA300N 
Billion Electric Co., Ltd., ADSL2+ Firewall Router 
Billion Electric Co., Ltd., BiPAC 7800NXL 
Billion, BiPAC 7700N 
Billion, BiPAC 7700N R2 
Binatone Telecommunication, Broadcom LAN Router 
Broadcom, ADSL Router 
Broadcom, ADSL2+ 11n WiFi CPE 
Broadcom, Broadcom Router 
Broadcom, Broadcom ADSL Router 
Broadcom, D-Link DSL-2640B 
Broadcom, D-link ADSL Router 
Broadcom, DLink ADSL Router 
ClearAccess, Broadcom ADSL Router 
Comtrend, AR-5383n 
Comtrend, Broadcom ADSL Router 
Comtrend, Comtrend single-chip ADSL router 
D-Link Corporation., D-Link DSL-2640B 
D-Link Corporation., D-Link DSL-2641B 
D-Link Corporation., D-Link DSL-2740B 
D-Link Corporation., D-Link DSL-2750B 
D-Link Corporation., D-LinkDSL-2640B 
D-Link Corporation., D-LinkDSL-2641B 
D-Link Corporation., D-LinkDSL-2741B 
D-Link Corporation., DSL-2640B 
D-Link, ADSL 4*FE 11n Router 
D-Link, D-Link ADSL Router 
D-Link, D-Link DSL-2640U 
D-Link, D-Link DSL-2730B 
D-Link, D-Link DSL-2730U 
D-Link, D-Link DSL-2750B 
D-Link, D-Link DSL-2750U 
D-Link, D-Link DSL-6751 
D-Link, D-Link DSL2750U 
D-Link, D-Link Router 
D-Link, D-link ADSL Router 
D-Link, DVA-G3672B-LTT Networks ADSL Router 
DARE, Dare router 
DLink, D-Link DSL-2730B 
DLink, D-Link VDSL Router 
DLink, DLink ADSL Router 
DQ Technology, Inc., ADSL2+ 11n WiFi CPE 
DQ Technology, Inc., Broadcom ADSL Router 
DSL, ADSL Router 
DareGlobal, D-Link ADSL Router 
Digicom S.p.A., ADSL Wireless Modem/Router 
Digicom S.p.A., RAW300C-T03 
Dlink, D-Link DSL-225 
Eltex, Broadcom ADSL Router 
FiberHome, Broadcom ADSL Router 
GWD, ChinaTelecom E8C(EPON) Gateway 
Genew, Broadcom ADSL Router 
INTEX, W150D 
INTEX, W300D 
INTEX, Wireless N 150 ADSL2+ Modem Router 
INTEX, Wireless N 300 ADSL2+ Modem Router 
ITI Ltd., ITI Ltd.ADSL2Plus Modem/Router 
Inteno, Broadcom ADSL Router 
Intercross, Broadcom ADSL Router 
IskraTEL, Broadcom ADSL Router 
Kasda, Broadcom ADSL Router 
Link-One, Modem Roteador Wireless N ADSL2+ 150 Mbps 
Linksys, Cisco X1000 
Linksys, Cisco X3500 
NB, DSL-2740B 
NetComm Wireless Limited, NetComm ADSL2+ Wireless Router 
NetComm, NetComm ADSL2+ Wireless Router 
NetComm, NetComm WiFi Data and VoIP Gateway 
OPTICOM, DSLink 279 
Opticom, DSLink 485 
Orcon, Genius 
QTECH, QTECH 
Raisecom, Broadcom ADSL Router 
Ramptel, 300Mbps ADSL Wireless-N Router 
Router, ADSL2+ Router 
SCTY, TYKH PON Router 
Star-Net, Broadcom ADSL Router 
Starbridge Networks, Broadcom ADSL Router 
TP-LINK Technologies Co., Ltd, 300Mbps Wireless N ADSL2+ Modem Router 
TP-LINK Technologies Co., Ltd, 300Mbps Wireless N USB ADSL2+ Modem Router 
TP-LINK, TP-LINK Wireless ADSL2+ Modem Router 
TP-LINK, TP-LINK Wireless ADSL2+ Router 
Technicolor, CenturyLink TR-064 v4.0 
Tenda, Tenda ADSL2+ WIFI MODEM 
Tenda, Tenda ADSL2+ WIFI Router 
Tenda, Tenda Gateway 
Tenda/Imex, ADSL2+ WIFI-MODEM WITH 3G/4G USB PORT 
Tenda/Imex, ADSL2+ WIFI-MODEM WITH EVO SUPPORT 
UTStarcom Inc., UTStarcom ADSL2+ Modem Router 
UTStarcom Inc., UTStarcom ADSL2+ Modem/Wireless Router 
UniqueNet Solutions, WLAN N300 ADSL2+ Modem Router 
ZTE, Broadcom ADSL Router 
ZTE, ONU Router 
ZYXEL, ZyXEL VDSL Router 
Zhone, Broadcom ADSL Router 
Zhone, Zhone Wireless Gateway 
Zoom, Zoom Adsl Modem/Router 
ZyXEL, CenturyLink UPnP v1.0 
ZyXEL, P-660HN-51 
ZyXEL, ZyXEL xDSL Router 
huaqin, HGU210 v3 Router 
iBall Baton, iBall Baton 150M Wireless-N ADSL2+ Router 
iiNet Limited, BudiiLite 
iiNet, BoB2 
iiNet, BoBLite

Как видим железки говорят сами за себя, и анализируя статью можно понять, что все они были скомпрометированы через какую-то древнюю уязвимость какого-то из компонентов ПО.
Если верить статьям, то для компроментации использовался древнейший баг в проприретарном UPNP сервере от Broadcom.

И судя по выборке таки да, всё это железо построено именно на BCM и никто из вендоров не удосужился просто выкинуть проприретарную поделку и использовать внятную OSS реализацию.

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

Так же интерес представляет наличие Eltex и QTECH в списке. Привет коллегам. ;) Мягко скажем неприятно удивили.

Хочется задать вопрос. Как так-то? Вы хвастаетесь огромными R&D, сотнями инженеров и т.д., но с 2008г (именно тогда UPNP в общем и реализация BCM в частности, подверглись изучению под микроскопом) не пофиксили известные баги?

Надеюсь у вас хватит сил, что бы поднять исходники и выпустить исправленную версию. Стыдно товарищи, ооочень стыдно!

Медиа: image / jpeg


23. Зло как оно есть (STB over WiFI)Пн, 29 окт 2018[-/+]
Категория(?)  Автор(?)

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

ТВ/Торрент по Wi-Fi зло

Дорогие операторы связи, пользователи и интеграторы. Ни для кого не секрет, что произошло за последние годы с эфиром в 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


24. О вреде дружественных интерфейсовВт, 25 сен 2018[-/+]
Категория(?)  Автор(?)

Windows Mouse BUG

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


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

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

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

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

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

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

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

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

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

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

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

Еще один недостаток “дружественного” интерфейса – восприятие разработчиками интерфейса пользователя как чего-то совершенно особенного. А между тем, еще тридцать лет назад был сформулирован принцип: “Если тебе лень читать вывод программы, заставь это делать другую программу”. Олицетворение данного принципа – программы 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


25. Руководство пользователя по установке и базовой настройке Wive-NGПт, 10 авг 2018[-/+]
Категория(?)  Автор(?)

Wive NgНиже представлено краткое руководство пользователя по быстрой установке и настройке маршрутизатора на базе 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 authorization at wive-ng

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

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

      language select at web of wive-ng

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

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

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

      model select of wive-ng firmware to update

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

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

      current status and firmware version

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

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

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

      start page of wive-ng

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

      firmware update

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

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

      firmware update timer

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

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

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

    1. Изменение реквизитов по умолчанию

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

      default data alarm

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

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

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

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

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

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

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

      wan settings

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

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

      static dns setings

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

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

      dns profile select

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

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

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

      vpn settings

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

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

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

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

      IPv6to4 tunnel settings

      Настройка IPv6to4

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

      static ipv6 settings

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

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

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

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

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

      basic wireless settinds

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

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

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

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

      wifi scan

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

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

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

      channel bandwidth settings

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

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

      wifi security wpa aes settings

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

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

      auto wpa2-psk set

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

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

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

      wifi clients connected list

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

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

      wifi throughput and clients diagram

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

    9. Настройка IPTV

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

      iptv settings of wive-ng

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

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

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

ЗагрузчикЗагрузка...
Логотип EADСлишком долго?

ПерезагрузкаПерезагрузить документ
| ОткрытьОткрыть в новой вкладке

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

Медиа: image / jpeg


26. Фильтруем трафик по MAC/IP/портам. Нюансы Firewall.Ср, 20 июн 2018[-/+]
Категория(?)  Автор(?)

FW Portfilter

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

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

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

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

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

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

Настройка фильтрации трафика (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

Вывод 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, будут отброшены (в том случае, если мы точно знаем, с какого порта будет устанавливаться соединение).

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

Пример:

фильтрация трафика / фаервол / firewall / traffic filtering

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

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

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

фильтрация трафика / фаервол / firewall / traffic filtering

Создание двух противоречащих друг другу правил 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. Подключение к локальным сервисам

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

фильтрация трафика / фаервол / firewall / traffic filtering

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

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

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

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

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

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

udpxy / udp http proxy

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

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

udpxy / udp http proxy / filtering / firewall

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

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

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

Медиа: image / png


27. Проприетарные “радости” D-link или опять 25.Вт, 29 мая 2018[-/+]
Категория(?)  Автор(?)

NIL ADMIRARI — ничему не удивляться.routers backdoor

Исследователи “Лаборатории Касперского” обнаружили несколько уязвимостей в прошивке роутеров D-Link DIR-620. Проблема заключается в том, что данная прошивка широко распространена, поскольку некий крупный российский интернет-провайдер предоставляет эти устройства своим абонентам. При этом домашние роутеры находятся за NAT провайдера и не попадают в статистику.

Красота? Но это ещё не всё. Т.е. две из трёх уязвимостей позволяют получить полный доступ к системе без авторизации.

Подробнее прочитать можно тут http://nag.ru/go/text/101405/

Но самое страшное не то, что D-link насколько безалаберно относится к ПО, и даже не то, что это может быть сделано умышленно. А то, что когда наступает EOL, ответ у таких компаний следующий:

Представители D-Link в ответ на запрос исследователей заявили, что данная модель производителем больше не поддерживается, поэтому обновлений с исправлением уязвимостей ждать не стоит.

Опять-таки. Молодцы. Не поддерживается так не поддерживается. Репутация и безопасность клиентов их слабо интересует.
Единственная рекомендация, которую тут можно дать (и которую даёт Kaspersky lab) это:

  • ограничить доступ к веб-панели, используя белый список доверенных IP-адресов;

  • запретить доступ к Telnet;

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

Но вот беда. Вспоминаем новость, которая прошла буквально на днях: https://wi-cat.ru/others/o-vazhnosti-smenyi-rekvizitov-dostupa-ili-novaya-dryan-vpnfilter/ и, складывая дважды два, понимаем, что ограничение доступа по IP не даёт результата, как и полная блокировка со стороны Internet доступа к сервисам конфигурации. Почему? Всё просто. В сегодняшнем мире проще скомпрометировать Windows на ПК пользователя и с него уже провести атаку, автоматически обойдя все ограничения и фильтрацию (не будет же пользователь сам себе запрещать доступ к устройству).

Наверное, стоит подытожить. Сетевое оборудование, являющееся шлюзом в мир, просто обязано работать под открытыми операционными системами. Это важно для выявления проблем до того, как они могут быть выявлены «хакерами» и/или специалистами безопасности, например, конкурента. Важен также и момент возможности самостоятельного исправления, если вендор объявил EOL.

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

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

Что же касается D-link, то они далеко не в первый раз пойманы на бэкдорах. Ещё один недавний пример http://www.rootlabs.com.br/backdoor-dlink-dir-615/
Отметим, что по ссылке ПО от AthpaNetworks («дочки» d-link) и на рынок РФ оно практически не поставляется (в отличии от ПО, над которым работал Kaspersky lab). Однако, это подтверждает доводы некоторых людей об особенностях корпоративной политики d-link на эту тему.

P.S. Стоит отметить, что метод, используемый Kaspersky lab для выявления уязвимостей, очень топорный и покрывает лишь очень малую часть проблемных мест. За последний год закрыты сотни уязвимостей уровня ядра, не выявляемых таким методом.

PP.S. А вот уже и реакция D-Link на пост на NAG и на наш пост https://forum.nag.ru/index.php?/topic/140965-v-proshivke-routerov-d-link-dir-620-obnaruzhili-opasnye-uyazvimosti/&tab=comments#comment-1487036 . Как обычно, мы не виноваты, это всё заказчик. И вообще мы все такие хорошие и безопасность это наш приоритет. И вообще это не бэкдор. На мой взгляд подобный ответ полностью дискредитирует D-Link. И это всё вместо часовой работы инженера и выпуска исправленного ПО. От всей души рекомендую пользователям пострадавшим от этих действий подать коллективный иск, причём не только к D-Link, но и к оператору по заказу которого вшит бэкдор.

PP.SS. В продолжение темы:
1) https://threatpost.ru/popular-d-link-router-riddled-with-vulnerabilities/22273/
2) http://www.rootlabs.com.br/backdoor-dlink-dir-615/
3) https://pikabu.ru/story/odnim_nazhatiem_knopki_otklyuchit_ot_interneta_millionyi_polzovateley_yeto_realnost_4775096
4) https://habr.com/post/183314/
5) https://cryptoworld.su/
6) https://www.linux.org.ru/forum/talks/9710884
7) https://www.securitylab.ru/news/448257.php
8) http://itcom.in.ua/vzlom-parolya-d-link-dir-300-i-320/

Медиа: image / png


28. О важности смены реквизитов доступа или новая дрянь (VPNFilter).Сб, 26 мая 2018[-/+]
Категория(?)  Автор(?)

Router Trojan

В очередной раз, стопка уже до боли знакомых имён прогремела в очередном хаке домашних маршрутизаторов:

Троян VPNFilter заразил 500 тыс. роутеров в 54 странах мира

Эксперты по безопасности с тревогой наблюдают за растущей эпидемией вредоносной программы VPNFilter, которая успела за

относительно короткий срок заразить не менее 500 тыс. роутеров и иных сетевых устройств в 54 странах мира. Наибольшее количество

заражений наблюдается на территории Украины.

Подробнее: http://safe.cnews.ru/news/top/2018-05-25_novyj_troyan_napal_na_routerypolmilliona_ustrojstv

Так вот. Если попробовать прикинуть, как ей это удалось, то можно (на правах Ванги) предположить следующее.

Скорее всего, эта дрянь заражает Windows на ПК пользователя. Затем лезет по адресу шлюза, пытается выяснить, что за роутер используется, если выяснила -проверяет базу паролей по умолчанию на web/telnet, если не выяснила – неспешно брутфорсит.

Далее, после получения доступа в WEB/telnet, можно уже делать ооочень многое. Крайне сомнительно, что троян где-то там сохраняется и переживает перезагрузку. Скорее всего, используется постоянная подгрузка со скомпрометированного ПК. Как помогает сброс – не ясно. Скорее всего никак, вероятно просто сбрасываются какие-нибудь правила фильтрации и т.д.

Проще говоря, основные проблемы, которые были и остаются причинами таких взломов:

  1. Windows на ПК пользователя (славщаяся своей дырявостью) скомпрометировав которую, в итоге можно долго жить и насиловать всё доступное в сети пользователя железо, а если ввод перехватить, и пользователь решит порулить какой-то железкой в своей сети – пиши пропало (как пример одного из методов получения паролей от железяк)
  2. Пользователи часто не меняют пароли на доступ в интерфейс управления роутеров, ибо считают “а нафига, из инета же доступа нет?”, впрочем даже когда открывают доступ к web или telnet из мира – один фиг не меняют.
  3. Встроенные, вшитые в код сервисные учётные записи, излишняя автоматизация а-ля попытка загрузить по tftp фирмварь из локальной сети, даже если текущая нормально грузится и работает (а поскольку многие поделки без ребутов не живут, то поймать такой момент труда не составляет). Всякие сомнительные протоколы конфигурирования по L2, как, например, у микротиков, также могут являться просто зияющей дырой.

Проще говоря, всё от раздолбайства + невозможности аудита решений большинства вендоров на предмет закладок.

Использование устройств с OS Wive-NG позволяет полностью контролировать отсутствие закладок в ПО. А следование рекомендациями на нашем сайте позволит избежать вот таких вещей.

Обсуждение проблемы операторами РФ тут https://forum.nag.ru/index.php?/topic/140870-kto-to-na-etu-zarazu-popal-vpnfilter/
P.S. Справедливости ради, стоит отметить, что это не единственно возможный сценарий. Наверняка могут быть использованы и более сложные методы взлома, однако в 99% случаев именно вышеозначенные вещи приводят к подобным последствиям.

Медиа: image / jpeg


29. Пробрасываем порты. Нюансы Port Forward .Пт, 18 мая 2018[-/+]
Категория(?)  Автор(?)

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

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 forwarding / проброс портов

Включение проброса портов (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 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).

DynDNS

Настройка 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 можно будет увидеть на этой же странице в соответствующем списке.

dhcp static settings

Настройка статической пары 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 router settings

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

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

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

ALG conntrack nat helper

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

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

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

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

dmz settings

Настройка 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


30. ОС Wive-NG включена в Единый реестр российских программ для ЭВМ и БДВт, 17 апр 2018[-/+]
Категория(?)  Автор(?)

Минкомсвязь России, российское ПО

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

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

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

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

Медиа: image / png


31. Роуминг (миграция клиентов между ТД) в Wi-Fi сетях — Часть 4 — HandoffВс, 11 мар 2018[-/+]
Категория(?)  Автор(?)

Wi-Fi HandoffHandOFF дословно — передавать. Однако, в контексте 802.11 я бы скорее перевёл бы этот термин (применительно к AP) как “руки прочь”.

В третьей части цикла мы рассмотрели такую процедуру как handover, которую выполняет клиент для миграции внутри wi-fi сети.

А что делать, если клиент по какой-то причине отказывается инициировать переход? А если клиент вообще не умеет самостоятельно мигрировать?

Вот тут к нам на выручку придёт механизм HandOFF. Как обычно в 802.11, этот механизм не является частью стандарта, не обязателен к реализации и вообще не предусмотрен. Сюрпрайз!

wive-ng handoff parametrs

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

Ну что же, нам не привыкать.

В чём смысл? А смысл прост, AP мониторит уровни от клиентов, и при достижении минимального порога посылает DEAUTH сигнал клиенту.

Клиент благополучно «слетает» с AP, а дальше…

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

Кто-то разумно заметит, что DEAUTH фрэйм может быть послан с несколькими десятками reason code. Зачем слать StaLeave, если можно использовать что-то более «мягкое».

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

Как пример, вот что об этом говорит CISCO. Смотрим табличку https://supportforums.cisco.com/t5/wireless-mobility-documents/802-11-association-status-802-11-deauth-reason-codes/ta-p/3148055

Нас интересует 802.11 Deauth Reason Codes. Слегка офигиваем от NOT SUPPORTED и успокаиваемся.

Справедливости ради стоит заметить, что в 802.11 есть нужный reason за номером 12 – Disassociated due to BSS Transition Management. Однако, даже CISCO оный ризон не поддерживает. И вообще, по факту мне не удалось найти клиента, который бы его обрабатывал корректно.

Чаще всего клиент его обрабатывает так же как и 8 (sta leave) или же вовсе игнорирует, и в итоге получаем клиента, который до упора будет считать, что подключен к ТД, в то время как ТД считает, что клиент обработав сигнал ушёл на соседнюю AP.

В результате, даже если клиенты, умеющие 12 reason и существуют в природе, мы всё равно вынуждены, ради совместимости, слать всё тот же Sta Leave т. к. ТД не знает, что именно реализовано в клиенте.

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

Проще говоря, мы просто выпинываем (kick out) клиента с ТД и надеемся, что клиент переключится на более подходящую ТД, что не всегда так. А многие клиенты первым делом пытаются вернуться назад. Или вовсе впадают в ступор и ждут, пока пользователь снова ткнёт «подключиться». Благо, последний вариант всё же редкость. А против возвращенцев можно использовать временную блокировку на уровне probe/assoc/auth (как, например, это сделано в Wive).

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

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

В ближайшее время постараюсь расписать, как handover реализован у нас (в Wive-NG), как его настроить в зависимости от задачи и т. д.

P.S. По традиции немного веселья из мира Enterprise $). Описание настройки handoff для Ruckus : https://support.ruckuswireless.com/answers/000002277. Они называют это smart roam. Как всегда в мире Enterprise, любой костыль выдаётся за мегадостижение, а т.к. сейчас всё SMART, то и костыль должен быть Smart. Также по ссылке есть рекомендации по отладке роуминга, которые сводятся к обновлению софта (видимо для поддержки RRM) и настройке агрессивности роуминга на клиенте (говорил в первой части об этой опции). Ну и если совсем не помогло, включаем smart roam.=) Ну и обилие опций (аж одна штука) поражает воображение.=)

Часть 3 Часть 5

Медиа: image / jpeg


32. Настройка встроенного DLNA сервера xupnpd для работы IPTV без STB.Чт, 01 мар 2018[-/+]
Категория(?)  Автор(?)

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

Настройка встроенного DLNA сервера xupnpd для работы IPTV без STB.

Для чего это нужно: для просмотра контента 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

Настройка сервисов 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Раздел 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-ов

список созданных 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

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

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

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

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


33. Решение проблемы роуминга (миграции между ТД) Android клиентов в wi-fi сетях (без наличия root доступа).Сб, 17 фев 2018[-/+]
Категория(?)  Автор(?)

android wi-fi roaming fixТеперь немного праздника для владельцев 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


34. Бесшовный роуминг (миграция между ТД) в wi-fi для Android клиентов.Сб, 17 фев 2018[-/+]
Категория(?)  Автор(?)

android wifi roamingКак и обещал ранее, рассказываю, как заставить Android устройства с радио на atheros/qualcomm нормально мигрировать (в большинстве случаев).

Сначала хорошая новость. Достаточно давно atheros/qualcomm добавили в свои драйвера вполне внятную логику handover (миграции внутри плоской L2 сети, с точки зрения клиента, с множественными AP, на которых установлен один SSID). Собственно, тот самый роуминг, да ещё и бесшовный (ну если используемые AP не совсем плохи и умеют моментально пропихивать в опорную сеть критичные данные, например, ARP-ы для обновления arp таблиц на устройствах в сети + ещё ряд условий на тему кривости).

Теперь по проблеме. Handover есть, сеть с нормальными AP есть, но чтобы клиент мигрировал, по-прежнему требуется пинок, иначе висит до последнего… Что делать и кто виноват? И вот тут, по ходу рассмотрения крутилок, я это проясню.

Для продолжения нужно само устройство, обязательно рутованное, обязательно использующее радио на чипе qualcomm (например yota phone 2).

Перемонтируем разделы в RW, идём в /system/etc/wifi, видим там файлик WCNSS_qcom_cfg.ini – собственно, это основной конфигурационный файл, читаемый драйвером wifi.

Драйверы QCA сами реализуют слои SME/MLME, не экспортируя эти функции на плечи wpa_supplicant. И вся логика управления подключениями и миграцией возложена на них. Wpa_supplicant в Android собран с NO_ROAMING, а значит можно ожидать, что это сделано так же у всех абсолютно чипмэйкеров для Android (конфиги, естественно, разные, или же, как у Broadcom, интересующие нас параметры к исправлению задаются при компиляции, и изменить их на лету невозможно).

Первая крутилка, которая нас будет интересовать в конфиге, это:

# 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

Эта крутилка напрямую отвечает за то, когда клиент начнёт пытаться искать кандидата (форсирует сканирование, или запросит список ближайших AP по RRM и проведёт короткую процедуру скана для подтверждения). И значение у нас тут -78дБ… Как работает автоматика (когда в 0 выставлено значение), надо будет разобраться, как будет время.

И вроде бы всё хорошо, но… Мы как обычно забыли, что то, что слышит клиент и то, что слышит AP, может отличаться по уровню на десятки дБ… Обычно в android-клиентах передатчик в 20МГц полосе может выдать 16дБм, в 40МГц в лучшем случае 14дБм. Тогда как со стороны AP обычно имеем как минимум 20дБм дури даже в 40МГц полосе (обычно определяется законодательными ограничениями конкретной страны, для РФ 20дБм в 2.4ГГц и 23дБм в 5ГГц независимо от ширины, хоть в 80МГц эти 23дБм, хоть в 20МГц). Из опыта, при таком раскладе в среднем перекос по уровням в прямой видимости уже в 10 метрах будет составлять около 10-15Дб, а если есть преграды, то запросто перевалит и за 30.

Но возьмём 10дБ для простоты. Т.е. когда клиент видит AP с уровнем в -78дБ, AP видит клиента уже с уровнем около -88дБ. Стоит говорить, что нормальной работы при таком раскладе уже не будет (особенно в 2.4ГГц в зашумленном эфире офиса)? TCP, требующий подтверждения доставки, просто встанет колом, голос начнёт квакать и т.д.

Плюс, что бы этого избежать (плюс приземлить побольше клиентов, ведь для этого надо заставить всех работать на самой ближней AP, желательно с максимальными рэйтами и без повторов передачи), админ в сети наверняка на AP настроил handoff с уровнем эдак в -75дБ. Т.е. при -75дБ RSSI handoff со стороны AP застрелит такого клиента (при этом на клиенте уровень от AP будет аж -65дБ, т.е. далеко до заветных -78дБ, когда он решит подумать мигрировать). Т.е. будет link beat, сброс стэйтов и обрыв соединений на пользовательской стороне.

Ещё пример – когда AP видит клиента с уровнем в -75дБ, клиент видит AP с уровнем -65дБ!! Или, когда на клиенте видим -78дБ, то со стороны AP клиент будет слышен лишь с -88дБ уровнем.

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

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

А вот чтобы этого не происходило, достаточно выше обозначенную переменную поправить, выставив значение в диапазоне -65 ~ -70дБ.

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

Следующий блок:

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


CcxEnabled – это поддержка rrm ccx location-measurement, т.е. определения местоположения. Зачастую бесполезна и лишь будет расходовать батарею почём зря.

FastTransitionEnabled – собственно поддержка 802.11R, однако в старых драйверах не полная, но хотя бы умеет учитывать MDIE при миграции (работает всегда, если переменная в значении 1). Заметим, что FT, а именно ускорение фазы аутентификации просто при взводе значения переменной в 1 работать не начнёт, т.к. требуется ещё и Supplicant пропатчить + обвязку андроидную (как это делает, например, Samsung в своих топовых моделях). Однако, учёт MDIE – уже польза. Включаем.

Не забываем также отключить 802.11d, иначе встретим много чудес в 5ГГц с DFS каналами. Пусть использование или не использование оных лежит на совести админа сети.

# 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

Вот оно самое заветное. Включает собственно возможность миграции в любых сетях. Иначе, логика handover будет активироваться, только если клиент видит, что AP вещает поддержку 802.11R в IECAP. И/или используется WPA*-Enterprise (сюрпрайз)… Ну а как вы хотели?=)

Надо же как-то продавать Enterprise AP, вот и вырубим хэндовер между обычными, не анонсирующими поддержку 802.11R ни в каком виде. Муркетинг животворящий, блин.

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

В новых драйверах, поставляемых в SDK для Android 6.0.1, добавлена ещё одна прекрасная опция:

# Handoff Enable(1) Disable(0)

gEnableHandoff=0

Эта опция (если выставить в 1) позволяет обрабатывать handoff с пинком со стороны AP как сигнал к миграции, т.е. банально не генерируется LinkBeat при kickout со стороны AP, а сразу выполняется попытка перескочить на следующую подходящую выбранную сканом AP, и только если не получилось сгенерировать Link Beat системе (т.е. о том, что его выпнули, знает только драйвер, и сразу пытается мигрировать, если не получается, то тогда уже сообщает системе, что всё, связи с этой сетью больше нет, надо выбрать другой SSID из тех, которые знает android).

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

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

А вот ещё одна крайне полезная крутилка:

#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

Дельта уровней между AP для выбора кандидата при миграции. Больше значение – меньше вероятность прилететь назад на ту же AP, но более отложенный старт миграции. 5дБ дефолтовых ИМХО маловато. Нужно иметь дельту около 8-10дБ. Для начала выставим 8.

RoamRssiDiff=8

Ещё интересная штука:

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

Эта опция откидывает все маяки, если в этих фрэймах не взведён TIM бит, а клиент спит. Т.е. во сне клиент не может вести пассивный сбор данных о соседних AP. Хорошо для батарейки – вероятно, плохо для миграции (надо глубже копать драйвер).

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

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

RRM включается так:

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

Правда, я на доступных мне железках (в смысле, на тех, в которых было вырублено и включил, на SGS A5 2017 запросы есть, но там и так всё с миграцией более-менее) так и не дождался ни одного запроса с использованием RRM от Yota phone… Видимо, отключена поддержка при сборке драйвера.

Это основное, что касается миграции.

Да и ещё:

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

По дефолту обычно 0. В таком режиме клиент при переходе в режим сна (часто просто при выключении экрана) полностью тушит RF часть, временно просыпаясь только для того, чтобы AP его по таймауту не выпнула. При этом, реализация такова, что и роумингу зачастую становится туго. Следует установить его в 3, т.е. фильтровать броадкасты и мультикасты во сне, и только.

В конфиге ещё много интересных параметов. Например, куча энергосберегаек, если поотключать которые, миграция становиться более весёлой и точной, но батарея…

Ну и на закуску:

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

Поддержка широких каналов (>20МГц) + поддержка SGI. Зачастую для 2.4ГГц поддержка 40МГц отключена, т.е. gChannelBondingMode24GHz установлен в 0. Что, во-первых, не позволяет работать на максимальных рэйтах (150Мбит/с для 1T1R в 2.4ГГц при 40МГц, будет только 72). Увы, проблема в том, что видимо для первого соединения значение перекрывается откуда-то ещё, и даже выставив gChannelBondingMode24GHz=1, сразу мы 150Мбит/с не видит. Но после первой же миграции драйвер плюёт на всех и взлетает в 40МГц полосе.=))

Также установка gChannelBondingMode24GHz решает проблему совместимости с некоторыми 2.4ГГц AP на Xiaomi и One+ (как обычно, намутили с анонсами в зависимости от региона, в итоге AP и клиент не могут договориться, в какой полосе разговаривать).

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

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

PP.S. Естественно, всё это будет работать только если вендор не отключил поддержку этого счастья на стадии сборки драйвера. Так что тут как повезёт.

PP.SS. Кому не лень, может накидать приложение для правки этих параметров из GUI.

Медиа: image / png


35. Бесшовный роуминг (миграция между ТД) в wi-fi для Linux клиентов.Сб, 17 фев 2018[-/+]
Категория(?)  Автор(?)
Хорошая новость для Linux`оидов. С wpa_supplicant из GIT запросто настраивается прозрачная миграция. Т.е. iptv мультикастовое продолжает литься при миграции, iperf в большинстве случаев не умирает, а лишь деградирует по скорости в момент миграции и т.д. При этом даже корректно отрабатывает вариант с несколькими AP в разных поддиапазонах 5ГГц. Что для этого надо (на примере mageia linux v5) 1) wpa_supplicant из git (можно взять подготовленный мной src.rpm http://wive-ng.sf.net/downloads/wpa_supplicant-2.6-1.mga5.src.rpm и собрать по команде rpmbuild rebuild wpa_supplicant-2.6-1.mga5.src.rpm) 2) переключить его на использование nl80211 вместо wext, драйвер вашего wifi модуля должен полностью поддерживать nl80211 (при использовании wext всегда будут долгие периоды реконнекта с потерей соединений пользовательских приложений) т.к. требуется, чтобы SME был на уровне wpa_supplicant. Большинство дистрибутивов по умолчанию использует WEXT, т.е. до сих пор далеко не все дрова wifi, даже входящие в состав ядра, умеют nl80211 (iwlwifi точно умеют, ath*k тоже должны, rt28xxx хоть типа и умеют, но увы по факту даже сканирование не работает). Проверить, что используется на данный момент, можно, посмотрев, с какими опциями запущен supplicant (ps ax | grep wpa_supplicant должен выдать что-то типа 25201 ? Ss 0:01 /usr/sbin/wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf -D nl80211 -f /var/log/wpa_supplicant.log) Для этого редактируем /etc/sysconfig/network-scripts/ifcfg- Важно установить: WIRELESS_WPA_DRIVER=nl80211 WIRELESS_WPA_REASSOCIATE=no MII_NOT_SUPPORTED=yes USERCTL=yes В /etc/wpa_supplicant.conf отключаем рандомизацию mac везде, где найдём. Включаем фоновое сканирование: # bgscan: Background scanning # wpa_supplicant behavior for background scanning can be specified by # configuring a bgscan module. These modules are responsible for requesting # background scans for the purpose of roaming within an ESS (i.e., within a # single network block with all the APs using the same SSID). The bgscan # parameter uses following format: ":" # Following bgscan modules are available: # simple - Periodic background scans based on signal strength # bgscan="simple::: # " bgscan="simple:30:-65:200" Т.е. при уровне ниже -65 будем начинать время от времени щупать эфир на предмет наличия кандидатов для миграции и по возможности мигрировать. Также следует обратить внимание на используемый DHCP клиент. Важно, чтобы он не сбрасывал адрес на интерфейсе (иначе сбросятся стэйты соединений приложений) по сигналу от ifplugd. Я использую штатный Internet Systems Consortium DHCP Client 4.3.3-P1 . Ну и естественно, ваши точки доступа и опорная сеть должны нормально отрабатывать ситуацию с перемещением клиентов. Опять-таки, в Wive-NG для этого сделано абсолютно всё, что возможно. Больше ничего не требуется. Проверено на I3160/I7260. Выпинывать их принудительно не надо оно само инициирует переход без всяких проблем. Под виндой эти интелы ведут себя аналогично, т.е. без проблем мигрируют с сохранением пользовательских соединений, достаточно лишь в настройках драйвера увеличить агрессивность роуминга и вуаля. Вот вместо фонового сканирования можно было бы использовать данные из RRM, но этой логики в supplicant пока нет.

Медиа: image / png


36. Роуминг (миграция клиентов между ТД) в Wi-Fi сетях — Часть 3 — HandoverВс, 04 фев 2018[-/+]
Категория(?)  Автор(?)

The cat handoverХэндовер (англ. Handover) — в сотовой связи процесс передачи обслуживания абонента во время вызова или сессии передачи данных от одной базовой станции к другой.

Вот мы и подобрались непосредственно к миграции. В т.ч. в случае так называемого бесшовного роуминга.

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

Handover — процедура миграции между точками доступа, инициируемая и осуществляемая клиентом исходя из определённых (одному ему известных), не регламентированных “стандартом” критериев.

Самое важное в этом определении – то, что именно клиент инициирует процедуру перехода, и именно он решает когда, куда, как и по какой причине он решил мигрировать.

Когда клиент запускает процедуру handover? На этот вопрос нет однозначного ответа, т. к. «стандарт» 802.11 не определяет ни самой процедуры, ни критериев.

В самом простом (однако в самом часто встречающемся) случае происходит буквально следующее:

При каждом возникновении события RSSI changed происходит проверка уровня сигнала. И если сигнал низкий (обычно на клиентах низким считается RSSI < -75dB), то клиент:
– запускает процедуру сканирования,
– просматривает данные фонового сканирования, выполненного недавно,
– проводит опрос текущей станции по RRM на предмет наличия соседей с более высоким (обычно используется дельта порядка 5-10dB) уровнем сигнала. Собственно уровень сигнала в данном случае и является критерием выбора кандидата.

Также могут использоваться и другие критерии (например, драйвера Qualcomm для каждого кандидата начисляют очки исходя из данных загруженности, поддержки WMM, совпадения MDIE и др.). Пороги срабатывания handover могут быть динамическими или форсировать запуск handover исходя из оценки каких-либо критериев (например, ситуация, когда уровень и сейчас с большим запасом, но рядом есть точка доступа с уровнем многократно выше).

Однако, чаще всего критерий ровно один — падение уровня на текущей AP ниже порогового значения, которое чаще всего задано как -75dB.

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

Настройка агрессивности роуминга у Intel

Настройка агрессивности роуминга у Intel

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

Многие производители клиентских устройств вообще не заморачиваются и не включают поддержку handover при сборке (благо, сейчас почти всегда в SDK как минимум этот механизм включен по умолчанию).

Но вернёмся к вопросу.

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

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

Для ускорения этой процедуры используются следующие механизмы:
– если клиент уже ранее был на этой AP, и в кэше (PMK Chache) есть запись для него, то 4 шага аутентификации будут сокращены до двух, и клиент пройдёт по упрощённой процедуре реассоциации (Reassoc).
– также будет использована всё та же короткая процедура при использовании FT(802.11R)/OKC.
– процедура выявления кандидатов может быть ускорена с помощью (RRM)802.11K за счёт запроса у текущей AP списка работающих соседей без выполнения процедуры сканирования.

Однако, подавляющее число клиентов умеет разве что PMK Cache и OKC. Последний применим только в WPA2 Enterprise сетях.

Но сейчас не об этом. Да и основная проблема в другом.

Основной нюанс для осуществления именно бесшовности (на этом уровне, на L2,L3 есть свои не менее важные нюансы) – то, что в момент миграции клиент должен уложиться в тайм-аут TCP соединений системы, и что ещё важнее не сбрасывать эти соединения, т. е. на уровне операционной системы при успешной миграции не должно генерироваться событие link beat (Link down/up).

К сожалению, около 70% клиентов всегда генерят link beat и всегда сбрасывают соединения приложений. Именно это основная проблема при миграции на стадии переключения. Т.к. даже если всё прошло гладко, но система сбросила состояния соединения пользовательских приложений, то вместо кратковременного «квака» (например в VOIP) из-за небольшой потери пакетов получим гарантированную необходимость перезвонить.

На таких клиентах бесшовная миграция не возможна в принципе.

На других клиентах порог уровня, по которому инициируется Handover, задан ниже -80dB, и часто происходит так, что AP гораздо раньше перестаёт слышать клиента и отстреливает его, нежели клиент сам инициирует процедуру handover`а. И повлиять на это можно только одним способом — понижать уровень сигнала со стороны AP, чтобы AP не теряла клиента до момента срабатывания handover. Обычно уровень в 2.4ГГц при этом приходится выбирать ниже 16дБм, что заметно сказывается на SNR и приводит к заметной деградации сервиса (к сожалению мы не одни в эфире).

Вот так, в двух словах, можно описать всё, что происходит на L1 уровне в процессе handover и основных проблемах. Крайне упрощённо, но достаточно для понимания. В одной из частей мы вернёмся к проблемам (их значительно больше и не только на L1 уровне) и рассмотрим их подробнее.

Что из сказанного обязательно к запоминанию:

1) handover всегда инициирует клиент исходя из собственных соображений;
2) в 802.11 нет ни одного механизма сказать клиенту форсировать процедуру handover или просто внепланово «посмотреть вокруг», выполнив сканирование; ОБНОВЛЕНИЕ: В новых редакциях 802.11v предусмотрен механизм BTM, но поддерживается увы менее чем на 50% клиентов собственно умеющих этот самый 802.11v.
3) в 802.11 нет чёткого набора требований к алгоритмам реализации handover — всё отдано на откуп третьим лицам, потому существует далеко не одна реализация разной степени кривости;
4) на весьма большом числе клиентов процедура handover не подразумевает бесшовности, т. е. всегда приводит к сбросу соединений приложений;
5) немалый пласт клиентов вообще не умеет процедуры handover, и попытка соединения к новой AP будет выполнена только тогда, когда соединение с текущей будет утеряно, или же текущая AP пошлёт клиенту DEAUTH фрэйм;
6) единственное критичное требование к AP для функционирования процедуры хэндовер на клиенте – это её нормальная работа. Грубо говоря, она просто должна гарантированно пустить нового клиента без каких-либо аномалий.

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

Исследование CISCO на тему критериев запуска процедуры handover можно увидеть тут https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/device_classification_guide.html

Исследование CISCO стадии сканирования в процессе миграции и использование 802.11k (RRM) для сокращения этой фазы https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/iPhone_roam/b_iPhone-roaming.html на примере iphone6

Определение роуминга от wi-fi alliance https://www.wi-fi.org/knowledge-center/faq/how-does-a-client-roam

Вторая часть. | Четвёртая часть.

Медиа: image / jpeg


37. Проблемы Intel Wireless после WPA2 Crack FIX в wpa_supplicant (3160, 3168, 7260, 7265, 8000C, 8265).Сб, 03 фев 2018[-/+]
Категория(?)  Автор(?)

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

После обновления 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


38. Роуминг (миграция клиентов между ТД) в Wi-Fi сетях — Часть 2 – Band SteeringЧт, 25 янв 2018[-/+]
Категория(?)  Автор(?)
Band steering глазами инженера

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

Настройка 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

Наглядное пояснение как работает 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


39. Производительность радио сегмента SNR-CPE-ME1 в реальных условияхВт, 23 янв 2018[-/+]
Категория(?)  Автор(?)

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

SNR-CPE-ME1

Вот и настала очередь 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

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

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

i3160 mode in STA list

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 – iperf

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

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

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

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

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

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 – iperf

SGS A5 2.4GHz 1T1R 20MHz SGI - speedtest

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 – iperf

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

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


40. Обзор линейки оборудования SNR-CPE на базе Wive-NG-mtПн, 22 янв 2018[-/+]
Категория(?)  Автор(?)

snr-cpe md1.1SNR-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-W4N (rev.M)

SNR-CPE-W4N (rev.M)

SNR-CPE-W2N

SNR-CPE-W2N

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

SNR-CPE-MD1

SNR-CPE-MD1

SNR-CPE-MD1.1

SNR-CPE-MD1.1

SNR-CPE-ME1

SNR-CPE-ME1

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

SNR-CPE-Wi2

SNR-CPE-Wi2

SNR-CPE-AP1

SNR-CPE-AP1

SNR-CPE-AP2

SNR-CPE-AP2

Подробнее….

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

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

    Пример настроек 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 минуту

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

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

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

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

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

    Подробнее….

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

  • Встроенный RADIUS сервер на базе Free radius для авторизации прямо на одном из маршрутизаторов в сети;
  • Индивидуальные пары логин/пароль для каждого пользователя, создаваемые через web-интерфейс;
  • Централизованная аутентификация в сети с использованием внешнего сервера на базе 802.1x EAP-TTLS-PEAP-MSCHAPv2 (WPA2-Enterprise)
  • Организация легального временного Wifi-доступа в публичных сетях (гостиницы, кафе, предприятия с контролем пользователей интернет)

Для решения вопросов сегментирования и изоляции в сети, мы предлагаем:

  • Выделение каждого SSID в VLAN;

    SSID to VLAN

    Пример настройки SSID to VLAN

  • Изоляция между беспроводными клиентами;
  • Зонирование локальной сети с помощью VLAN;

    Wive-NG-MT - Настройка 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 интерфейса от 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, либо выбранной.

    График сетевой активности (RX+TX Bandwidth) клиентов за интересующий интервал времени на всех AP, либо выбранной.

Не забыли и про домашнего пользователя. Для его удобства:

  • Маршрутизатор поставляется с оптимальными и максимально безопасными настройками по умолчанию (минимум манипуляций от пользователя для обеспечения стабильной и безопасной работы);
  • Разделы четко структурированы по типу настроек, разделены базовые и расширенные настройки;

    Группировка разделов , на примере настроек IPTV

    Группировка разделов , на примере настроек IPTV

  • Уведомление о небезопасном использовании реквизитов по умолчанию;
  • Просмотр пароля wifi в web (по умолчанию скрыт)
  • Подтверждение пароля администратора при смене , для исключения опечатки;
  • Наличие русского языка в web-интерфейсе (по умолчанию язык интерфейса – английский)

    Внимание!!! Сотрудничество между нами и компанией NAG завершено в феврале 2019г. Новые устройства с оригинальной Wive-NG-MT производиться не будут. По всем вопросам (включая доступность новых разработок и поддержку для юридических лиц, а так же переводу существующего оборудования на актуальную версию Wive-NG-HQ) обращайтесь по адресу info@wi-cat.ru .

Медиа: image / png


41. Роуминг (миграция клиентов между ТД) в Wi-Fi сетях — Часть 1 – Scan and connectСб, 20 янв 2018[-/+]
Категория(?)  Автор(?)

Wi-Fi roamingЭто первая статья из цикла посвящённых миграции (роумингу) в сетях wi-fi (802.11).

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

Для начала стоит определиться с тем, как вообще происходит соединение в wi-fi. Точнее, что именно ему предшествует.

Первое, что мы должны сделать – это выяснить, какие точки доступа (далее , access point – AP) ведут вещание. Данная процедура может быть осуществлена двумя способами:

1) активное сканирование
2) пассивное сканирование.

Процедура активного сканирования сама состоит из нескольких фаз:
1) Смена канала
2) Посылка probe request
3) Ожидание ответа

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

Сканирование одного канала (включая ожидание ответа) занимает около 20мс. Так, например, активное сканирование 2.4ГГц диапазона, доступного в РФ (1-13 каналы), займёт 260мс.

Сканирование всего 5ГГц диапазона, доступного в РФ (36-48, 52-64, 132-144 , 149-165), – 960мс.

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

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

Вариант пассивного сканирования сводится к прослушиванию эфира на предмет маяков, которые рассылает AP (обычно раз в 100мс). Никакие запросы в этот момент клиент не посылает. Это крайне важно понять и запомнить.

Т.е., нам нужно опять-таки перебрать все каналы, на каждом находиться и слушать эфир минимум 100мс (на самом деле больше, чтобы гарантированно услышать все AP, ведущие вещание).

Исходя из этого мы можем посчитать время, затрачиваемое на такой вариант сканирования – оно будет минимум в 5 раз больше (100/20), нежели в активном режиме. В 2.4ГГц – 1300мс, в 5ГГц – 4800мс.

Казалось бы, такой режим не имеет права на существование, т.к. в разы уступает варианту активного сканирования. Но это только кажется. ;)

Эти 2 варианта доступны нам, когда клиент ещё не подключен к AP.

Если мы подключены к AP, то нам становится доступен ещё один – третий способ определения того, какие AP ведут вещание. А именно, мы можем послать текущей AP, к которой подключены, запрос neighbor report request, используя протокол 802.11k radio resource management (RRM). В ответ мы получим как минимум список соседних AP.

К сожалению, этот протокол поддерживается, на текущий момент, лишь небольшим числом AP. Хорошая новость в том, что Wive-NG имеет поддержку RRM. Подробнее о RRM мы поговорим при рассмотрении средств ускорения миграции в сетях 802.11. Пока просто запомним, что такой механизм у нас есть, и он, в отличии от сканирования, не требует остановки передачи данных с текущей AP, а также занимает минимум эфирного времени.

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

Модификация добавляет в схемы сканирования ещё 2 шага к уже имеющимся.

А именно:
1) перед сменой канала мы должны перейти в режим PSM (Power Saving Mode), что заставит текущую AP начать буферизацию данных в сторону нашего клиента;
2) переключить канал и выполнить один из вариантов сканирования, описанных выше, вернуться на свой канал;
3) выйти из PSM режима, после чего AP очень быстро должна сгрузить нам данные.

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

Для пассивного режима существует исключение. Если нам требуется получить данные только об AP на том же канале, на котором работаем и мы, то необходимость в шагах 1 и 3 отпадает, как и переключение канала. Как результат, в пассивном режиме мы можем получать данные о соседних AP, работающих на том же канале, без остановки передачи данных с текущей AP. Это очень полезное свойство пассивного режима.

Итак, используя один или все методы, мы получили данные об AP, ведущих вещание. Что дальше?

А дальше мы должны выбрать кандидата для подключения.

Обычно это происходит просто банально выбором AP с максимальным уровнем и SSID, совпадающим с выбранным пользователем. Различия тут будут лишь при использовании каких-либо дополнительных механизмов. Например, band preffered или 802.11r, который добавляет, кроме SSID ещё поле MDIE. Но об этом в следующих статьях.

Как только кандидат определён, мы посылаем ему probe req с указанием MAC клиентского устройства, т.е. такой целевой probe запрос. Во-первых, на этом этапе мы проверяем готова ли эта AP нас принять и/или жива ли она вообще, во-вторых, получаем дополнительные данные о режимах работы (алгоритм аутентификации, алгоритм шифрования).

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

Время на фазы ассоциации+аутентификации (в случае, если всё прошло без проблем) в режиме WPA2 PSK составляет около 110мс.
Для режима WPA2 FT-PSK (с использованием 802.11r) время сокращается примерно до 10-20мс.

WPA2 802.1x (WPA Enterprise) без использования FT (802.11r) или OKC (opportunistic key caching) зависит от загруженности radius сервера, к которому AP должна обращаться, чтобы выяснить, пустить или не пустить пользователя. В особо тяжёлых случаях может занимать секунды.

При использовании WPA2 802.1x (WPA Enterprise) + FT/OKC время сокращается примерно до тех же 10-20мс, что и в режиме FT-PSK.

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

Но важно не это. Важно, что фаза аутентификации, на фоне фазы сканирования во всех случаях, кроме голого WPA Enterprise без FT/OKC, достаточно короткая, чтобы добавить проблем с миграцией, или чтобы пользователь заметил этот момент.

Банальное сканирование 2.4ГГц диапазона – 260мс. А если нужно оба диапазона (радиомодуль в клиенте обычно один), то это уже все 260мс + 960мс= 1220мс в лучшем случае при активном сканировании.

Плюс есть ложка дёгтя. Для работы механизмов FT/RRM (802.11r/k) требуется их поддержка как на клиенте, так и на AP.

По факту же, AP, умеющих эти протоколы, в SOHO сегменте почти не наблюдается, а клиентов с их поддержкой – вообще минимум. Из более-менее массовых устройств, это свежие Samsung Galaxy S и A серий, а также свежие устройства от Apple.

Проверить, умеет ли ваше устройство хотя бы один из этих протоколов (замечу, один другого не заменяет), можно косвенно, попытавшись найти ваше устройство на сайте Wi-Fi Альянса и убедиться, что он прошёл сертификацию по программе “Voice-Enterprise: Voice quality and bandwidth management tools for the enterprise”.

Подробнее: https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-voice-programs

Однако, нахождение устройства в списках сертификации не гарантирует фактическую работу (часто ломают после первых же обновлений). И наоборот, отсутствие устройства в списках не говорит о том, что оно 100% не умеет 802.11k/r. Однако, если у вас устройство под Android и его нет в списке программы сертификации, то это 99%, что устройство не умеет ни K, ни R.

Напомню, что Wive-NG умеет 802.11 K/R, хотя мы и не проходили сертификации у альянса.

Исследование CISCO стадии сканирования в процессе миграции и использование 802.11k (RRM) для сокращения этой фазы https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/iPhone_roam/b_iPhone-roaming.html на примере iphone6

Часть 2.

Медиа: image / jpeg


42. Wive-NG, публичные хотспоты и соблюдение законодательства.Ср, 17 янв 2018[-/+]
Категория(?)  Автор(?)

Делая доброе дело помни о его законности (с) …

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

Для решения этой задачи в 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


43. Что может USB ?Ср, 17 янв 2018[-/+]
Категория(?)  Автор(?)

Wive-NG на устройствах с USB поддерживает следующие возможности.

wive-ng usb Работа с накопителями:
1) Поддержка установки внешних приложений из репозитория Entware
2) Поддержка swap (актуально при использовании приложений из Entware, которым мало встроенной RAM)
3) Файловые серверы (SAMBA/FTP)
4) DLNA сервер (XUPNPD)

Поддерживаемые FS:
1) ext2/3/4 (рекомендуется ext4, как нативная для Linux и актуальная для всех современных Linux дистрибутивов FS). Рекомендуем использовать именно Ext4.
2) FAT32 (нативно, но не умеет *nix расширений и имеет ограничения на длину файла)
3) NTFS (через NTFS 3G userspace fuse реализацию, в разы медленней выше приведённых)
4) ExFAT – файловая система от MS для flash накопителей. Поддержка нативная, а значит быстрая. ОДНАКО. Категорически не подходит для организации файлового хранилища если планируется запись по сети. Проблема в том, что ExFAT всегда сначала выделяет место на накопителе под файл и только потом начинает запись данных. Такой подход, на длинных файлах может приводить к задержкам (вплоть до часов в зависимости от размера и накопителя) перед началом записи и вря тли ваша OS дождётся отклика от SAMBA в роутере…

Автомонтирование осуществляется по меткам:
1) swap раздел с меткой swap
2) optware метка на разделе EXT* заставит смонтировать его в /opt для использования Entware
3) media метка говорит системе использовать этот раздел как файловое хранилище для FTP/SAMBA/DLNA
4) если метка не совпадает ни с одной из вышеперечисленных, то раздел будет смонтирован в /media/sd*

Другие возможности:
1) Сервер печати (p910nd)
2) Поддержка USB модемов 3G/LTE

Установка и использование Entware:

Для работы потребуется маршрутизатор на базе ПО Wive-NG-HQ с USB портом – например, FT-AIR-DUO-G флэш или USB HDD в роли накопителя.

Подготовка накопителя сводится к созданию на нём раздела ext4 с меткой optware. Это можно сделать любыми доступными средствами, например используя gparted под Linux.

После подключения накопителя к маршрутизатору, следует подключиться к нему по ssh. Проверяем что раздел optware корректно смонтировался введя mount | grep opt. Если видим соответствующую строку – всё Ок. Продолжаем.

[Wive-NG-HQ:/]$ mount | grep opt
/dev/sda1 on /opt type ext4 (rw,noatime,data=ordered)		

Командуем entware_install.sh и ожидаем окончания процедуры:

[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!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

По окончанию операции командуем fs save && reboot:

[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.

После перезагрузки снова подключаемся по ssh и проверяем что получилось. Пробуем установить например MTR (My traceroute), командуем opkg install mtr:

[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).

Полный список пакетов можно увидеть по ссылке.

Стоит оговориться, что мы не контролируем этот репозиторий, и не все пакеты могут работать на SNR-CPE-ME1. Все контакты относительно Entware – тут.

Медиа: image / jpeg


44. Подробнее о SNR-CPE-ME1Ср, 17 янв 2018[-/+]
Категория(?)  Автор(?)

SNR-CPE-ME1SNR-CPE-ME1 первый гигабитный, высокопроизводительный, высоконадёжный (как с точки зрения ПО, так и с точки зрения электроники), беспроводный маршрутизатор, поддерживающий 802.11a/b/g/n/an/ac от компании NAG.

Построено устройство на CPU MT7621AT. 2 ядра по 2 потока, работающих на частоте 880МГц. Производительность MT7621AT, относительно используемого в предыдущих моделях MT7620, выше примерно в 4 раза.

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

Также установлена оперативная память DDR3 объёмом 256Мб. И быстрый SPI флэш объёмом 16Мб.

Встроенный блок PPE позволяет выполнять маршрутизацию и NAT на скорости портов, т.е. для режимов IPOE/PPPOE по проводу, скорость будет ограничена не CPU, а физическими возможностями порта.

Поддержка USB3 с программным управлением питанием (т.е. можно программно физически снять питание с порта USB) и защитой от КЗ, позволяет использовать маршрутизатор как небольшой файл/принт сервер и использовать 3G/4G модемы. А также, расширять функционал, используя приложения из репозитория EntWare, устанавливая их на внешний накопитель (HDD/Flash).

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

В качестве радиомодулей использованы микросхемы MT7610 (1T1R 802.11a/an/ac, max rate 433Mbit) и MT7603 (802.11b/g/n, max rate 300Mbit).

Все ВЧ цепи экранированы.

В качестве усилителей используются микросхемы от SkyWorks, зарекомендовавшие себя на рынке как один из лучших производителей СВЧ компонентов.

Выходная мощность точно соответствует требованием законодательства РФ и составляет 20dBm (100мВт) для 2.4ГГц и 23dBm (200мВт) для 5ГГц (в MD1/1.1 максимум 20dBm для обоих диапазонов, т.е. зона покрытия ME1 в 5ГГц заметно шире).

Производительность беспроводного сегмента можно видеть тут.

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


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

Статью считать устаревшей. В 2019г. уже нет никакого смысла приобретать Wave-1 устройства.

Медиа: image / png


45. About Wive-NG-MTСр, 17 янв 2018[-/+]
Категория(?)  Автор(?)

wive-ng scangraphWive-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


46. Устройства, поставлявшиеся с OS Wive-NG-MT с завода (2015-2018г.)Пн, 15 янв 2018[-/+]
Категория(?)  Автор(?)

snr-cpe md1В порядке запуска в серию:

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


47. Who is Ms. Wive-NG ?Пн, 15 янв 2018[-/+]
Категория(?)  Автор(?)

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

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

В процессе развития система переросла в коммерческий проект, результаты которого использует заметное число интернет-провайдеров на территории РФ в комплекте с ADSL/WiFi маршрутизаторами Acorp / SNR-CPE (NAG) / FT-AIR (Fibertool) / Wi-Cat (Synertau).

Wive-NG interfaceВ отличие от большинства встраиваемых систем для 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



 
Каталог RSS-каналов (RSS-лент) — RSSfeedReader
Top.Mail.Ru
Яндекс.Метрика
© 2009–2024 Михаил Смирнов
Сайт использует cookie и javascript. Никакая личная информация не собирается
Всего заголовков: 47
По категориям:
• Все заголовки
• 2024 (1)
• 3G/4G/LTE/EDGE/GPRS (1)
• 802.11 aka wi-fi (8)
• 802.11ax (1)
• 802.11i/802.11r/802.11k/802.11v/OKC (6)
• 802.1x (1)
• adblock (1)
• Android (3)
• AP/CPE (19)
• backdoor (1)
• BandSteering (1)
• content filter (1)
• CWMP/TR-069 (1)
• dns proxy (2)
• dnssec (1)
• enterprise (1)
• Entware/Optware (1)
• firewall (1)
• freeradius (1)
• handoff/handover (2)
• HotSpots (1)
• i3160 i3168 i7260 i7265 i8000C i8265 Intel Wi-Fi cards (1)
• IPTV/DLNA/MULTICAST/HLS/RTSP (цифровое телевидение) (4)
• ipv6/6to4/6in4 (1)
• Linux (3)
• local dns (1)
• Mesh (9)
• OpenSource (3)
• port forward/проброс портов (1)
• radius (1)
• Russian embedded router OS (2)
• SAMBA (1)
• Seamless wi-fi Roaming (9)
• SNR-CPE (3)
• torrent (1)
• Wi-Cat-AX (1)
• Wi-FI (17)
• wi-fi 6 (1)
• wi-fi маршрутизатор (роутер) (21)
• Wi-Fi роуминг (10)
• Wive-NG (24)
• Wive-NG - настройки (9)
• Wive-NG Project (14)
• wive-ng-hq (4)
• WPA2 CRACK (1)
• wpa2-enterprise (1)
• антенны (1)
• Бесшовный wi-fi роуминг (миграция) (10)
• встраиваемое программное обеспечение (1)
• домашний интернет (1)
• Законодательство (1)
• заметки (11)
• импортозамещение (3)
• история успеха (2)
• корпоративная сеть (1)
• Новое оборудование (2)
• новый год (1)
• Обзоры (9)
• обзоры (4)
• онлайн обновление (1)
• ООО Вайрлесс КЭТ/Wireless CAT LLC (3)
• Открытые исходники (3)
• пакет яровой (1)
• предложение (1)
• Проблемы, решения, рекомендации (6)
• Прошивка/Firmware (19)
• Разное (5)
• Российская операционная система (2)
• Рукалицо (3)
• спамбот (1)
• тестирование (1)
• Точка доступа (4)
• файловое хранилище (1)
• фильтрация/filtering (1)
По датам:
• Все заголовки
• 2023-12-26, Вт (1)
• 2023-12-25, Пн (1)
• 2022-07-23, Сб (1)
• 2022-07-15, Пт (1)
• 2022-02-10, Чт (1)
• 2021-11-19, Пт (1)
• 2021-11-15, Пн (1)
• 2021-10-26, Вт (1)
• 2021-09-29, Ср (1)
• 2020-04-09, Чт (1)
• 2020-04-06, Пн (1)
• 2020-04-02, Чт (1)
• 2019-10-06, Вс (1)
• 2019-05-28, Вт (1)
• 2019-03-14, Чт (1)
• 2019-03-02, Сб (1)
• 2019-02-26, Вт (1)
• 2019-02-21, Чт (1)
• 2019-01-28, Пн (1)
• 2019-01-02, Ср (1)
• 2018-12-12, Ср (1)
• 2018-11-29, Чт (1)
• 2018-10-29, Пн (1)
• 2018-09-25, Вт (1)
• 2018-08-10, Пт (1)
• 2018-06-20, Ср (1)
• 2018-05-29, Вт (1)
• 2018-05-26, Сб (1)
• 2018-05-18, Пт (1)
• 2018-04-17, Вт (1)
• 2018-03-11, Вс (1)
• 2018-03-01, Чт (1)
• 2018-02-17, Сб (3)
• 2018-02-04, Вс (1)
• 2018-02-03, Сб (1)
• 2018-01-25, Чт (1)
• 2018-01-23, Вт (1)
• 2018-01-22, Пн (1)
• 2018-01-20, Сб (1)
• 2018-01-17, Ср (4)
• 2018-01-15, Пн (2)
По авторам:
• Все заголовки
• sfstudio (1)
• wi-cat (46)