Mechanics

Была такая проблема на mipsel версии сервера 4.5.8 решал откатом на версию 4.5.4 Отправил в личку.

У меня точно такой же МФУ, через Virtualhere и печатал и сканировал на ура. Может проблема с драйверами? Сейчас сделал печать через CUPS, а сканирование через Sane и Scanservjs https://github.com/sbs20/scanservjs Такое возможно только на ARM64 устройстве, т.к. проприетарный драйвер от HP - Hplip есть только для arm, x86, для mips и mipsel нет.

У меня такая уже 2 года живёт с entware + хранилка без проблем. тьфу-тьфу.

Проблема в драйверах wifi вашего Nindendo. У вас вариантов практически нет. Попробуйте отключить 802.11r на контроллере Keenetic.

По поводу бесшовного WiFi. Его не существует. Смиритесь. Аксиомы: Клиент ищет точки, куда можно подключаться Клиент решает, когда переподключаться Клиент решает, куда подключаться Клиент инициирует переподключение Клиент выбирает, на какую частоту подключаться (2.4 ГГц или 5 ГГц) Точка доступа (роутер) может: Отвечать с задержкой на запросы аутентификации от клиента (как одна из реализаций band-steering, например). Отказывать в аутентификации клиенту (по силе сигнала, при большой нагрузке на точку доступа и т. п.). Де-аутентифицировать клиента (должно использоваться как «крайняя мера»). Предоставлять клиенту оптимизированный список соседних АП для роуминга — 802.11k. Предоставлять информацию о загруженности других точек доступа — 802.11v. Ускорять процесс роуминга, используя «быструю аутентификацию» вместо полного процесса переаутентификации — 802.11r. Выводы: Для работы 802.11k/v/r требуется поддержка этих стандартов и клиентом, и точкой доступа. Бесшовный роуминг не ограничивается 802.11k/v/r, он может быть реализован и без этих технологий. Весь бесшовный роуминг строится на том, что клиента уговаривают переподключиться. Либо добровольно, либо создавая условия, которые подстегнут его к этому. Именно клиент в конечном итоге решает, куда и как он хочет подключаться, а его решения могут целиком и полностью не совпадать с «рекомендациями и желаниями», полученными от точки доступа. Потому что так решили те, кто писал драйверы и прошивку модуля. Отсюда появляются типичные ситуации: Точка доступа де-аутентифицирует\не аутентифицирует клиента. Он продолжает попытки соединиться именно с этой точкой. Потому что хочет. Роуминга не происходит. Wi-Fi у клиента не подключается. Игнорирование клиентом одной из частот (2.4 ГГц или 5 ГГц) просто потому, что у него где-то внутри стоит приоритет. Итог: «бесшовного» роуминга в Wi-Fi не существует в принципе. Максимум — «быстрый роуминг на стероидах». Гарантированно повлиять на поведение клиента мы не можем, а можем лишь надеяться на адекватность его драйверов\прошивки. Если с ними не повезло, то роуминга не будет или он будет такой, что лучше бы его не было.

Вот, осталась в работе с 4G только Extra KN-1710 на 4.2.1.

Была аналогичная проблема на omni 2, extra 2, extra и hero 4g. ОПСОСы - Beeline, Yota. Решил проблему запретом использования DNS провайдера и назначением DNS yandex и google, 77.88.8.8 и 8.8.8.8 на старых моделях и DoT, DoH на новых. Пинг чек настроен на icmp ping. Вот уже как год проблем нет.

Столкнулся с аналогичной проблемой при добавлении в Mesh Extra 2 по проводу, невозможно поменять WiFi канал из Web. Режим работы был установлен «Точка доступа/Ретранслятор». Сбросил настройки и установил режим «Усилитель/Ретранслятор». Стало доступна возможность изменения канала WiFi. Так что это не баг, а фича.

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

4.2 Beta 3 1. При отключении/включении WiFi через cli, WiFi включается/отключается, но в Веб-интерфейсе состояние не меняется. Меняется только после команды system configuration save. При этом если это делать на контроллере, то на экстендерах входящих в Mesh в Веб-интерфейсе состояние меняется. 2. На экстендерах входящих в Mesh на странице системного монитора можно управлять состоянием WiFi, при этом на странице Мои сети и Wi-Fi это сделать нельзя.

Очень похоже на работу DPI провайдера. Было тоже самое с OpenConnect, решил переходом только на TCP. Попробуйте proto tcp.

Прошу пояснения функционала. KeeneticOS 4.2 Beta 2 Контроллер Mesh Wi-Fi-системы теперь передает сегменты без точек доступа Wi-Fi на ретрансляторы. [NDM-3210] Возможно ли создать отдельный сегмент на контроллере Mesh Wi-Fi-системы со своим SSID WiFi, и при этом на ретрансляторах этот сегмент должен быть без этого SSID или вообще отсутствовать? Сейчас эту задачу решаю через костыль - скрипт, отключающий на всех ретрансляторах WiFi в этом отдельном сегменте и LAN порты контроллере на время загрузки. Эта затея нужна для одного упрямого Tuya Smart Life WiFi домофона. Регистрация и привязка домофона к контроллеру MWS и запрет подключения к ретрансляторам не помогает, так же не помогают никакие настройки сегмента WiFi, 802.11r/k/v и Band Steering. Т.к. после включения питания домофон пытается подключиться к первой обнаруженной точке доступа WiFi с запомненным ранее SSID. И в случае недоступности контроллера, но доступности ретрансляторов он пытается подключится к ретрансляторам. Причем домофон игнорирует подключение к контроллеру при последующей его доступности вплоть до перезагрузки домофона по питанию.

VirtualHere USB Server for Linux (ARM64)

Есть же решение:

Устанавливал месяца три назад сервер по этой статье: Настраиваем OpenConnect - совместимый с Cisco AnyConnect VPN сервер на платформе Linux - Записки IT специалиста (interface31.ru) Клиенты - android (VPN Clieent Pro, OpenConnect), ОПСОС - Билайн, МТС. Вместо apt install .. , естественно opkg install ... Сертификат генерил самоподписанный, все работает. В конфиге пришлось отключить udp-port = 4433, оставил только tcp-port = 4433 иначе DPI проовайдера клиента просекал vpn и блокировал трафик.