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

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

Судя по приказу https://cdnimg.rg.ru/pril/193/30/39/59195.pdf в РФ из WiFi 6E диапазонов разрешён только UNII 5. Т.е. 5925-6425МГц.

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

Будем пробовать ближе к лету, надеюсь уже на оборудовании наших заказчиков. ;)

Совсем упустил. В 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. Логика будет дорабатываться.

Почему в Wive нет и не будет автообновления по расписанию, а решение об обновлении всегда принимает пользователь или ISP (если последний управляет вашим устройством, тогда он несёт ответственность и дополнительно тестирует ПО перед обновлением)?

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

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

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

Как пример, обновляться ради повышения надёжности когда аптайм страдает только от потери питания как минимум странно и обновления в таком случае точно никак ни надёжность ни аптайм не увеличат. В отличие от UPS. ;)

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

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

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

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

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

P.S. Это всё базовые принципы известные любому сетевому администратору. Да и принцип разумной необходимости пока никто не отменял. ;)

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

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

И ещё одна статья на ту же тему вдогонку https://cbs.ru/lib/technical-articles/10594/ .

4.2.12 плановый релиз:
1) webui: PMF: исправлена установка режима "требовать"
2) webui: правка в логике network diagnostic которая могла приводить к недоступности UI (восстанавливалось самостоятельно)
3) webui: в сетевых утилитах добавлен etherwake (WOL)
4) тюнинг новой логики band steering (см предыдущий анонс) для 7615 и более новых чипов
5) обновления компонентов miniupnpd/haveged/dropbear

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

Корректирующий релиз (в основном косметика):
1) xt_time больше не использует флаг kerneltz (используйте UTC)
2) исправления русской локализации в секции настроек роуминга (handoff это принудительная балансировка, к настройкам бесшовной миграции отношения не имеющая)
3) рефакторинг complex qos
4) несколько не критичных бэкпортов с vanilla kernel

В догонку к заметке https://t.me/wicatllc/104 . Важно помнить, что в случае с бесшовной миграцией решение о инициировнии самой процедуры хэндовера принимает клиент. Причём чаще всего принимает он это решение исходя из измеренного им RSSI. И чаще всего порог срабатывания лежит около -75dB, причём RSSI должен быть ниже -75 некоторое время.

Так вот. Если поставить 2 ТД рядом, включить на них k/r и ждать что магически клиент начнёт мигрировать между ними достаточно наивно.

Нужно обеспечить тот самый триггер в виде падения уровня.

Часто, пользователи расставляют АП по комнатам и вместо роуминга получают пшик, клиент продолжает себе висеть на АП к которой зацепился. Причём клиент умеет K/R/V. А причина простая, уровни до -75 на стороне клиента падают только за пределами квартиры.

Особенно актуально для 2.4ГГц...

Выход (без замены оборудования на железо с отличной от OMNI диаграммой направленности)? Без вариантов, снижать мощность передатчика (особенно в 2.4ГГц) и играться с размещением.

Если вас не интересует бесшовность тогда можно добавить Handoff и жёстко, буквально пинками (kickout) забалансировать клиентов по ТД. Но как бы....

Больше информации буквально на пальцах можно найти тут https://wi-cat.ru/category/wi-fi-roaming/

P.S. Работа роуминга на примере IOS https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/iPhone_roam/b_iPhone-roaming.html#concept_EA3AF8F14F244478804B2D36C25F44C4 с наглядной демонстрацией проблематики (или почему 802.11k "полезнее" 802.11r =).

И ещё в догонку о BandSteering и его проблемах...

Основная проблема всплывает в MultiAP сети. Например, клиент у нас склонен к скатыванию по поводу и без в 2.4. Без бэндстиринга в сети где все ТД имеют одинаковый SSID он при первой же миграции съедет в 2.4 и более никогда не вернётся назад. И казалось бы включаем волшебный механизм и проблема решена.

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

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

В чём причина? Всё просто. Мы перемещаемся из зоны обслуживания одной ТД в другую, RSSI в 5ГГц (куда мы подключились изначально) упал до -75 и клиент решает что пора валить. Из кандитатов у него 2 SSID с уровнем в -50 в 2.4ГГц и -65 в 5ГГц. Помним что клиент у нас не умеет Band Preffered (иначе и стиринг был бы не нужен) и начинает усиленно долбиться в 2.4, а стиринг его не пускает, ибо не положено.

Для пользователя это выглядит как клиент залип на одной ТД.

И вот тут уже кто первый сдастся. Или клиент и съедет таки в 5ГГц хоть и с задержкой, или старая ТД кильнёт клиента по выросшему PER что приведёт к обрыву всех соединений, или пользователь запустит девайсом в стену. Ну ли стриринг пустит такого клиента в 2.4 На новой ТД.

Т.е. хорошего увы не произойдёт ничего как ни крути.

Выход? Если вы строите сеть с роумингом, и желаете бесшовности по максимуму, при этом у вас в наличии клиенты не умеющие выбирать оптимальный диапазон сами - не используйте одинаковые SSID в 2.4 и 5ГГц диапазонах, тогда и BandSteering вам не понадобиться и ситуация описанная выше не возникнет. ;)

Справедливости ради, стоит отметить, что ноутбучные карточки (как минимум точно все интелы) имеют важную крутилку (см скрин) позволяющую задать режим Band Preffered. Что стоит сделать обязательно установив предпочитать 5ГГц!

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

Это называется корректной поддержкой работы в Multi Band сетях ;)