Wi-Cat / Wive-NG
212 subscribers
50 photos
6 files
43 links
Wireless Cat LLC (https://wi-cat.ru , https://wikidevi.wi-cat.ru).

Новости, статьи, анонсы относительно операционной сиcтемы Wive-NG, беспроводного оборудования, а так же темы затрагивающие Wi-Fi (802.11) в общем.
Download Telegram
to view and join the conversation
4.1.10 Публичный корректирующий релиз. Основные изменения:
1) полноценное решение проблемы с onlime из-за короткого lease time в dhcp v6 (15 минут) постоянно дёргался реконфигур сети со всеми вытекающими
2) пофикшен выявленный фузз тестированием эффект гонки в драйвере nvram, попутно отрефакторили большую часть его кода
3) в mt7613/mt7615 драйверах добавлена проверка все ли команды были переданы mcu из драйвера перед отключением радиочасти по команде пользователя, если очередь команд не пуста просто ждём ;)
Последний в этом году (скорее всего) плановый релиз 4.1.11 (синхронизация компонентов с апстримом и мелкие правки):
1) busybox 1.35.0
2) фикс крайне редко проявляющейся проблемы в dnsmasq приводящей к переполнению кэша из-за невозможности удалить старые записи. Проявляется только при работающем ipv6 и то неуловимо редко
3) исправления логики xt_time, правило должно добавляться до related/established иначе уже установленные соединения не смогут быть обработаны.

Если п2 и 3 вас не касаются, то обновляться особого смысла не имеет.

В новом бизибоксе в 1.35.0 релизе, основные изменения (из тех что нас касаются) коснулись реализации ash (инит у нас написан именно на нём + демон rcd на Си).
Видимо приближающийся новый год так сказывается, но вот именно в последние дни часть пользователей оживает и решает писать репорты. Нет, это прекрасно, особенно когда в репорте всё чётко и по полочкам, но почему в последние дни-то? =)) Шучу.

В общем 4.1.12:
1) обновлён libcurl до 7.80.0
2) в трансмишн пофикшено отключение проверки сертификатов пиров
Компания Wireless-CAT уходит на каникулы до 10 января.

Всех с Новым годом. А в качестве новогоднего подарка 4.1.13 релиз с реализацией UI серверной части Wireguard (не смотря на то, что не планировали для этих устройств, но новый год всё же).

Доступно в обновлениях для всех поддерживаемых железяк. 🎄
Как-то совсем тихо и незаметно прошла новость о совместных усилиях МТК и AMD сделать клиентский WiFi-6e для ноутов, где потребление это мегакритично.

Ну и видимо в отместку Intel AX201/211 ;)

Честно говоря, меня в этой новости заинтересовало иное. Наверняка исходники дров будут предоставляться и АМД. А значит это лишний аудит кода и улучшение качества последнего.

В любом случае такая кооперация ооочень радует.

https://corp.mediatek.com/news-events/press-releases/amd-and-mediatek-develop-amd-rz600-series-wi-fi-6e-modules-to-enhance-laptop-and-desktop-pc-connectivity-experiences
Не в первый раз слышу, что бесшовный (именно бесшовный) роуминг в wive настраивается люто сложно и сложнее чем у большинства. Пояснить в чём сложность великая так никто и не смог.

Так вот, что бы в Wive заработал бесшовный роуминг, минимально необходимо и достаточно:
1) соединить кабелем нужное число устройств не забыв перевести часть устройств в режим точек доступа
2) на всех узлах настроить одинаковый SSID, задать одинаковый тип шифрования и пароль, включить 802.11k/r
3) снизить мощность в 2.4 до «минимума» что бы при перемещении клиентов RSSI на их стороне падал до искомых -75 при котором обычно клиенты и запускают процедуру handover.

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

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

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

Есть даже термин такой - «радиообследование» которое проводят что бы правильно спроектировать сеть, включая размещение ТД. Соответствующие навыки, знания и оборудование при этом крайне необходимы.

В домашних условиях в сети из роутера и 2х АП (99,9% случаев) достаточно эксперимента. А в качестве контроля любой смартфон поддерживающий 802.11r и Aruba Utils из плеймаркета.

P.S. Handoff это не для бесшовного роуминга. Это для клиентов которые не умеют handover или когда требуется жёсткая балансировка клиентов по ТД ради оптимизации использования эфирного времени. Бесшовной такая процедура быть не может. Т.е. его в общем случае не трогаем.
Выше описан необходимый для дома минимум. Оптимизация сети в части даже выбора каналов или настройки handoff под задачу требует совсем иного уровня вовлечённости в 802.11 нежели которым обладает типовой домашний пользователь пожелавший настроить у себя бесшовную сеть. Да и не нужно ему это. ;)

Кому всё же интересно могут начать с курса https://www.cwnp.com/certifications/cwna После которого все вопросы типа "а что это за крутилка и куда вертеть" отпадут сами по себе. ;)
4.2.х ветка с выпуском 4.2.7 (для внутреннего тестирования) достигла стадии RC1, т.е. стадии когда все потенциально опасные изменения внесены, базово отлажены и пора прогонять тесты на добровольцах (родственники, друзья, коллеги) + ещё раз пройтись по всему автоматикой.

4.2.х кроме прочего, принесёт одну полезную фишку. А именно возможность временного развёртывания entware в tmpfs (без использования USB Drive).

Для чего? Например вам понадобился mtr или htop, strace или не бог весть что для например целей отладки или mc для удобства навигации по файловой системе. Теперь их можно временно установить в RAM, попользоваться и удалить. ;)

Доступные для установки пакеты можно видеть введя opkg list
Как пользоваться:

Подключаемся по ssh и смело командуем entware_install.sh RAM. Дожидаемся окончания установки библиотек, после чего система попросит перелогиниться.

Послушно перезапускаем ssh сессию.

Далее как обычно командуем, например, opkg install htop

После установки говорим htop и созерцаем красивый монитор ресурсов.

Для освобождения памяти достаточно удалить содержимое /opt (rm -rf /opt/*)

Если хочется хранить конфиги entware в rwfs (что бы каждый раз не править например) можно при установке сказать entware_install.sh RAM /etc/opt

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

P.S. Релиз (уже почти традиционно) будет примерно на 10м миноре.

PP.S. Что-то существенное увы установить можно только на устройствах с >64Mb RAM ибо только базовый набор библиотек занимает 12Мб. А например вместе с установленным MC всё это весит уже ощутимые 22Мб.
Релиз 4.2.10 основные изменения:
1) возможность развёртывания entware в RAM (см выше)
2) бэкпорт стопки исправлений касающихся сети и поддержки архитектуры mips из апстрима ядра
3) исправлен расчёт SNR в DBDC режиме для mt7615/mt79x5 устройств
4) mt7615: попытка решить не повторяемую у нас проблему с глухим зависанием устройства после длительной эксплуатации при выключенных радиомодулях (https://wi-cat.ru/forums/topic/707/) просьба проверить у кого повторялось
5) обновление pppd/udpxy/dnsmasq.
Лично я (sfstudio) в коем-то веке проспал неприятную регрессию с поддержкой usb модемов.

Для возобновления работоспособности стоит скомандовать по ssh последовательно:
ln -s /etc/rc.d/W85modemhelper /etc/init.d/modemhelper

fs save && reboot

Обновление для фикса работы модемов будет доступно в течении получаса.

На текущий момент обновления для DUO-G заморожены. Остальных устройств проблема не коснулась. Как и иных режимов. И связана с наибанальнейшей опечаткой.

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

Проблема затрагивала только поддержку USB модемов и никак не сказывается на ином функционале. Связана с опечаткой при проведении работ по рефакторингу сборочной среды с целью подготовки интеграции поддержки ARM чипов.
Как-то уж очень, на наш взгляд, Mediatek разогнался на фоне кризиса. То 4нм BBP для телефонов представил, то вот уже обещает продемонстрировать прототипы WiFi-7 на CES в живую.

https://corp.mediatek.com/news-events/press-releases/mediatek-shows-the-worlds-first-live-demos-of-wi-fi-7-technology-to-customers-and-industry-leaders

Тем временем из драфта стандарт 802.11be (wifi-7) выйдет дай бог в конце 2023, а все плюшки задуманные наверняка не заработают до Wave-2 версии (уже традиционно).

Чуть подробнее о WiFi-7 можно почитать по ссылкам:
https://en.wikipedia.org/wiki/IEEE_802.11be
https://habr.com/ru/post/501266/
https://www.cnews.ru/news/top/2020-10-28_teoreticheskij_potolok

Одной из самых интересных особенностей, на наш взгляд, в wifi-7 возможность передавать и принимать данные одновременно по разным каналам и/или в разных диапазонах, прощай BandSteering & Co.

Так же радует, что наконец озадачились повышением спектральной эффективности по всем фронтам.
image_2022-01-22_15-17-37.png
109.9 KB
Судя по приказу https://cdnimg.rg.ru/pril/193/30/39/59195.pdf в РФ из WiFi 6E диапазонов разрешён только UNII 5. Т.е. 5925-6425МГц.

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

Будем пробовать ближе к лету, надеюсь уже на оборудовании наших заказчиков. ;)
image_2022-01-22_17-10-52.png
19.6 KB
Совсем упустил. В 4.2.11 так же вошла правка разрешающая активный режим upsteer. Принудительное пересаживание уже подключенных клиентов с 2.4ГГц в 5ГГц.

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

Однако распространение no name китайских смартфонов с дуалбэнд радиомодулями которые съехав в 2.4ГГц уже никогда не возвращаются в 5ку (поголовно) нам пришлось пересмотреть этот момент. Как говориться из двух зол...

Подробнее о Band Steering рассказывал л тут https://wi-cat.ru/wi-fi-roaming/migraciya-rouming-v-wi-fi-setyah-chast-2-band-steering/

P.S. Логика будет дорабатываться.
image_2022-01-23_14-38-37.png
33.4 KB
Почему в Wive нет и не будет автообновления по расписанию, а решение об обновлении всегда принимает пользователь или ISP (если последний управляет вашим устройством, тогда он несёт ответственность и дополнительно тестирует ПО перед обновлением)?

Всё просто и сложно. Для ответа на этот вопрос следует сначала ответить на вопрос когда обязательно стоит обновляться. Таких случаев буквально несколько:

1) в первый раз после покупки при установке железа
2) если что-то не работает или работает не так
3) если была выявлена та или иная уязвимость
4) появился необходимый вам функционал

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

Как пример, обновляться ради повышения надёжности когда аптайм страдает только от потери питания как минимум странно и обновления в таком случае точно никак ни надёжность ни аптайм не увеличат. В отличие от UPS. ;)
Более того, любое обновление любого ПО чревато регрессиями, особенно в не типовых для этого ПО кейзах. Т.е. НЕПРЕРЫВНЫМИ тестами (ручными и автоматическими) покрываются те вещи которые гарантированно используются ЦА (ISP) на доступе и весь базовый функционал.

В то время как доп функционал (типа USB) проверяется гораздо реже т.к. на это тоже тратятся ресурсы, которые достаточно ограниченны. Правда и что-то меняется в этом функционале редко.

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

Это касается абсолютно любого ПО и не специфично для Wive.

Если будет выявлено что-то критичное (уязвимость например) мы отдельно акцентируем внимание на необходимости обновления на этом канале.

P.S. Это всё базовые принципы известные любому сетевому администратору. Да и принцип разумной необходимости пока никто не отменял. ;)
image_2022-01-24_16-03-57.png
147.8 KB
Прислали ссылку на относительно небольшую (без погружения в подробности) статью по теме "Радиообследование".

Однозначно в коллекцию https://wifi-solutions.ru/radioobsledovanie-wifi/

И ещё одна статья на ту же тему вдогонку https://cbs.ru/lib/technical-articles/10594/ .
image_2022-01-25_12-25-44.png
360.3 KB
4.2.12 плановый релиз:
1) webui: PMF: исправлена установка режима "требовать"
2) webui: правка в логике network diagnostic которая могла приводить к недоступности UI (восстанавливалось самостоятельно)
3) webui: в сетевых утилитах добавлен etherwake (WOL)
4) тюнинг новой логики band steering (см предыдущий анонс) для 7615 и более новых чипов
5) обновления компонентов miniupnpd/haveged/dropbear

Критичных (падения/уязвимости) правок нет (в т.ч. в обновлённых компонентах).