mva113

5.2 Beta2 проблема устранена!

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

А, то есть это с самого начала так. Я то только сейчас альфу поставил не было времени до этого.

Я так предполагаю что получается в альфа-версии система по какой-то причине неверно определяет, что используется SAE-EXT, когда выбран только обычный WPA3-PSK. Это уже не просто «шум» — это баг валидации совместимости между контроллером и ретранслятором. При этом функционально всё работает (устройства подключаются и к Ultra, и к Air), а в смешанном режиме WPA2+WPA3 предупреждение исчезает — видимо, потому что проверка совместимости в этом случае идёт по другому, более «мягкому» сценарию. P.S. Хотелось бы понять: это баг валидации в альфе или так и задумано, что при чистом WPA3-PSK контроллер считает ретранслятор несовместимым? Если баг — ждём фикса, если нет — хотелось бы, чтобы предупреждение не пугало пользователей зря

Я не проверял WPA3-SAE-EXT, у Меня включен WPA3-PSK

Всем привет. После перехода на 5.2 Alpha 11 на ретрансляторе Air (NC-1613) в Mesh с Ultra (NC-1812) висит предупреждение: «Контроллер использует защиту сети расширенным ключом SAE (WPA3 SAE-EXT), не поддерживаемую данным ретранслятором» При этом Air в сети, устройства к нему подключаются нормально, скорость в порядке — функционально всё работает. Как воспроизводится: На Ultra стоит только WPA3-PSK → предупреждение есть. Ставишь WPA2-PSK + WPA3-PSK → предупреждение исчезает. Похоже, что «SAE-EXT» — это внутренний расширенный режим SAE для транспортной (backhaul) сети Mesh, который включается автоматически и не имеет отдельной галочки. Air его не поддерживает, отсюда и предупреждение. В смешанном режиме согласование идёт по другому пути, и до этого расширенного SAE дело не доходит. Учитывая, что это Alpha, скорее всего либо отладочный шум, либо известное ограничение совместимости между разными моделями на альфе. Вопрос: это просто косметика альфа-версии, или за этим стоит реальная потеря функций (например, бесшовного роуминга между Ultra и Air)? Стоит ли ждать фикса? UDP: 5.2 Beta2 проблема устранена!

====================================================================== РЕЗЕРВНЫЙ DNS: РЕАЛИЗАЦИЯ ИДЕИ ИЗ ТЕМЫ ОТ 27 НОЯБРЯ 2025 ====================================================================== Тема-предложение: В той теме я предлагал идею: если все прописанные DoT/DoH не отвечают N раз — переключаться на обычный DNS, пока они снова не станут доступны. Опционально, галочкой. Штатными средствами Keenetic это не решается: DoH/DoT работает по принципу «кто первый ответил», и роутер не переключается на обычный DNS автоматически, если все DoH/DoT недоступны. Поэтому я реализовал это иначе — через BIND на роутере с fallback на корневые DNS + маршрутизацию через AWG Manager и HydraRoute Neo. Ниже — полный разбор, как это собрать. ====================================================================== РЕЗЕРВНЫЙ DNS НА РОУТЕРЕ KEENETIC/NETCRAZE + АВТОМАТИЧЕСКАЯ МАРШРУТИЗАЦИЯ ЧЕРЕЗ AWG MANAGER И HYDRAROUTE NEO ====================================================================== ВАЖНО: все команды ниже выполняются в Entware (через SSH-терминал роутера, в оболочке Entware). Не в веб-интерфейсе роутера и не в системной консоли Keenetic. Если вы не уверены, что находитесь в Entware — проверьте, что команда `opkg` доступна. ====================================================================== Зачем всё это ====================================================================== Задача простая: DNS-запросы не должны уходить провайдеру и не должны зависеть от одного канала. Решение состоит из двух уровней: 1. WG-туннель — основной транспорт для DNS. 2. BIND на роутере — резерв на случай, если VPS или туннель упадут. Почему WG, а не DoH/DoT Штатный DoH/DoT в Keenetic работает по принципу «кто первый ответил». Запрос уходит на все доступные резолверы одновременно, и используется тот ответ, который пришёл раньше. Отсюда две проблемы: 1. Свой DoH не факт, что успеет первым. Публичные резолверы (Google, Cloudflare) мощнее и отвечают быстрее — часть запросов уйдёт им, а не вашему серверу. 2. Если DoH/DoT перестаёт работать — роутер не переключается на обычный DNS автоматически. Интернет просто встаёт. Поэтому мы делаем иначе: DNS идёт через WG-туннель на свой резолвер, а BIND на роутере страхует на случай, если туннель или VPS упадут. WG уже шифрует весь канал, так что наворачивать сверху TLS (DoH/DoT) — это двойная обёртка без выигрыша, лишний оверхед и потеря ~20 мс на хендшейках. ====================================================================== ЧАСТЬ 0. ПРИМЕР VPS-СТОРОНЫ (не является задачей гайда) ====================================================================== На VPS развёрнут AdGuard Home в Docker с внутренним адресом 172.19.0.205 (пример). За ним — BIND, который ходит только в корень. Это лишь пример. У вас может быть любой другой резолвер: свой BIND, unbound, AdGuard Home напрямую, публичный DNS вроде 9.9.9.9 и т.д. Главное — чтобы он был ваш и не отдавал запросы провайдеру. Схема движения запросов: клиент → ndns → BIND (роутер) → WG → AdGuard Home (VPS) → BIND (VPS) → корень если WG упал: клиент → ndns → BIND (роутер) → корень напрямую ====================================================================== ЧАСТЬ 0.5. БЭКАП ENTWARE (СДЕЛАЙ ПЕРЕД НАЧАЛОМ) ====================================================================== Прежде чем что-то менять — сделайте бэкап Entware, если у вас там уже что-то установлено и настроено. Если Entware только что поставлен и в нём ничего нет — бэкапить нечего, можно пропустить этот шаг и идти дальше. СОЗДАНИЕ БЭКАПА: В Entware (через SSH) выполните: tar cvzf /opt/entware_backup.tar.gz -C /opt . ВАЖНО: точка в конце обязательна. Она означает «упаковать содержимое текущей директории». Без неё архив будет содержать саму папку opt, что при восстановлении даст неверную структуру. Если места на /opt мало — сохраните архив сразу на внешний диск: tar cvzf /tmp/mnt/ВАШ_ДИСК/install/entware_backup.tar.gz -C /opt . ВОССТАНОВЛЕНИЕ: 1. Подготовьте чистый накопитель (отформатированный в ext4) или освободите текущий. 2. Создайте папку install в корне накопителя. 3. Положите туда ваш архив entware_backup.tar.gz. В большинстве случаев переименовывать архив не нужно — система сама распакует то, что лежит в папке install. ЕСЛИ ВОССТАНОВЛЕНИЕ НЕ СРАБОТАЛО — попробуйте переименовать архив в aarch64-installer.tar.gz (для вашей модели роутера имя может отличаться, например mips-installer.tar.gz). Полный список имён смотрите в официальной инструкции Keenetic по установке Entware для вашей модели. 4. В веб-интерфейсе роутера: Приложения → OPKG → выберите ваш накопитель → Сохранить. 5. Роутер сам распакует архив в /opt. Всё вернётся на место. ПРИМЕЧАНИЕ: архив можно положить и во внутреннюю память роутера, в папку install. Тогда восстановление пройдёт без внешнего диска. ====================================================================== ЧАСТЬ 1. УСТАНОВКА BIND НА РОУТЕРЕ ====================================================================== opkg update opkg install bind-server bind-libs bind-tools ====================================================================== ЧАСТЬ 2. СОЗДАНИЕ ПАПКИ ДЛЯ КЕША ====================================================================== BIND требует папку для кеша, иначе не стартует. mkdir -p /opt/var/cache/bind chown -R root:root /opt/var/cache/bind chmod 755 /opt/var/cache/bind ====================================================================== ЧАСТЬ 3. СОЗДАНИЕ КЛЮЧА ДЛЯ rndc ====================================================================== rndc — утилита управления BIND (сброс кеша, статистика, перезагрузка). /opt/sbin/rndc-confgen -a -c /opt/etc/bind/rndc.key ====================================================================== ЧАСТЬ 4. ОСНОВНОЙ КОНФИГ BIND ====================================================================== cat > /opt/etc/bind/named.conf << 'EOF' # ====================================================== # ОСНОВНЫЕ НАСТРОЙКИ BIND # ====================================================== options { # Рабочая директория для кеша и временных файлов directory "/opt/var/cache/bind"; # Слушаем на всех IPv4-интерфейсах (порт 53) listen-on port 53 { any; }; # IPv6 ОТКЛЮЧЁН ПОЛНОСТЬЮ: # - listen-on-v6 { none; } — не слушаем входящие IPv6-запросы # - query-source-v6 none — не отправляем исходящие IPv6-запросы # Это убирает задержки при недоступном IPv6 и шум в логах. listen-on-v6 { none; }; query-source-v6 none; # Разрешаем рекурсивные запросы только для локальных сетей. # ПРИМЕЧАНИЕ: здесь указаны базовые сети. Остальные подсети # (WG-подсети, гостевые сети, дополнительные сегменты) каждый # дописывает под свою конфигурацию. allow-recursion { 192.168.0.0/16; 127.0.0.1; }; allow-query-cache { 192.168.0.0/16; 127.0.0.1; }; allow-query { 192.168.0.0/16; 127.0.0.1; }; # Максимальный размер кеша — 16 МБ max-cache-size 16M; # Основной DNS-сервер (forwarder) — внутри WG-туннеля. # Если он недоступен — BIND автоматически идёт в корневые DNS. # # ПРИМЕЧАНИЕ: сюда подставьте адрес своего резолвера. # Это может быть локальный адрес (172.x.x.x) или публичный # (9.9.9.9, 1.1.1.1). Главное — не DNS провайдера. # В моём случае это 172.19.0.205. forwarders { 172.19.0.205; }; }; # ====================================================== # УПРАВЛЕНИЕ ЧЕРЕЗ rndc # ====================================================== include "/opt/etc/bind/rndc.key"; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; }; # ====================================================== # ЛОГИРОВАНИЕ — ТОЛЬКО ОШИБКИ (WARNING) # ====================================================== logging { channel main_log { syslog daemon; severity warning; print-time yes; print-severity yes; print-category yes; }; channel queries_log { null; }; category default { main_log; }; category queries { queries_log; }; category query-errors { main_log; }; }; # ====================================================== # КОРНЕВЫЕ DNS-СЕРВЕРЫ (FALLBACK) # ====================================================== zone "." { type hint; file "/opt/etc/bind/db.root"; }; EOF ====================================================================== ЧАСТЬ 5. ЗАГРУЗКА ФАЙЛА КОРНЕВЫХ DNS-СЕРВЕРОВ ====================================================================== wget -O /opt/etc/bind/db.root https://www.internic.net/domain/named.root ====================================================================== ЧАСТЬ 6. ПРОВЕРКА КОНФИГА И ПЕРВЫЙ ЗАПУСК ====================================================================== named-checkconf /opt/etc/bind/named.conf /opt/etc/init.d/S09named start ====================================================================== ЧАСТЬ 7. ПРОВЕРКА РАБОТЫ ====================================================================== ps | grep named | grep -v grep dig @127.0.0.1 google.com +short /opt/sbin/rndc status ====================================================================== ЧАСТЬ 8. АВТОЗАПУСК BIND ЧЕРЕЗ fs.d И wan.d ====================================================================== fs.d срабатывает при монтировании диска (ранний этап загрузки). wan.d срабатывает при поднятии WAN-интерфейса (дублирующий механизм). ВАЖНО: запускаем не S09named напрямую, а rc.unslung, который правильно обрабатывает все S-скрипты Entware. cat > /opt/etc/ndm/fs.d/S99bind << 'EOF' #!/bin/sh /opt/etc/init.d/rc.unslung start EOF chmod +x /opt/etc/ndm/fs.d/S99bind mkdir -p /opt/etc/ndm/wan.d cat > /opt/etc/ndm/wan.d/S99bind << 'EOF' #!/bin/sh sleep 5 /opt/etc/init.d/rc.unslung start EOF chmod +x /opt/etc/ndm/wan.d/S99bind ====================================================================== ЧАСТЬ 9. CRON ДЛЯ ОБНОВЛЕНИЯ КОРНЕВЫХ DNS-СЕРВЕРОВ ====================================================================== mkdir -p /opt/etc/cron cat > /opt/etc/cron/update_root_servers.sh << 'EOF' #!/bin/sh LOG="/opt/var/log/update_root.log" TMP_FILE="/tmp/db.root.new" DEST_FILE="/opt/etc/bind/db.root" touch "$LOG" if wget -q -O "$TMP_FILE" "https://www.internic.net/domain/named.root"; then mv "$TMP_FILE" "$DEST_FILE" echo "$(date): Корневые DNS-серверы обновлены" >> "$LOG" else echo "$(date): ОШИБКА: не удалось обновить корневые DNS-серверы" >> "$LOG" fi EOF chmod +x /opt/etc/cron/update_root_servers.sh ====================================================================== ЧАСТЬ 10. СКРИПТ АВТОЗАПУСКА CRON ====================================================================== cat > /opt/etc/init.d/S60cron << 'EOF' #!/bin/sh ENABLED=yes PROCS=crond ARGS="" PREARGS="" DESC=$PROCS PATH=/opt/sbin:/opt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin . /opt/etc/init.d/rc.func EOF chmod +x /opt/etc/init.d/S60cron mkdir -p /opt/var/spool/cron/crontabs /opt/etc/init.d/S60cron start crontab -l 2>/dev/null | { cat; echo "0 5 1,14,27 * * /opt/etc/cron/update_root_servers.sh"; } | crontab - crontab -l /opt/etc/cron/update_root_servers.sh cat /opt/var/log/update_root.log ====================================================================== ЧАСТЬ 11. ОПЦИОНАЛЬНО: opkg dns-override ====================================================================== opkg dns-override system configuration save Необязательный параметр. BIND работает и без него, но с ним чуть шустрее: убирается один лишний хоп в цепочке резолвинга. ВАЖНО: включается в самом роутере (не в Entware). Меняет системный резолвер роутера на то, что указано в /opt/etc/resolv.conf. После включения обязательно сохранить конфигурацию командой system configuration save — иначе настройка не применится. На работу HydraRoute Neo не влияет — проверено на практике. Отключить (если понадобится): no opkg dns-override system configuration save После отключения также обязательно сохранить конфигурацию. ====================================================================== ЧАСТЬ 11.5. МАРШРУТ ДЛЯ DNS ЧЕРЕЗ WG-ТУННЕЛЬ ====================================================================== Чтобы BIND мог достучаться до вашего резолвера на VPS через WG-туннель, нужно добавить статический маршрут в роутере: Тип маршрута: Маршрут до сети Описание: DNS Адрес сети: 172.19.0.0 ← подсеть, где живёт ваш резолвер Маска подсети: 255.255.0.0 (/16) Интерфейс: выберите ваш туннель до сервера Галочки: Добавлять автоматически Эксклюзивный маршрут ПРИМЕЧАНИЕ: адрес сети подставьте под свою конфигурацию. Если ваш резолвер — 172.19.0.205, то сеть 172.19.0.0/16 подойдёт. Если резолвер публичный (9.9.9.9) — маршрут не нужен, он и так доступен напрямую. Режим «Эксклюзивный маршрут» означает: если туннель недоступен, трафик к этой подсети не пойдёт вообще (не утечёт через WAN). Для DNS это правильно — пусть BIND уйдёт в fallback на корень, чем запросы утекут провайдеру. ====================================================================== ЧАСТЬ 11.6. УКАЗЫВАЕМ DNS РОУТЕРА В ОСНОВНОМ ПОДКЛЮЧЕНИИ ====================================================================== В веб-интерфейсе роутера: Интернет → Основное подключение → Параметры IPv4 → IPv4 DNS 1: 192.168.1.1 Либо: Интернет → Фильтры → Настройки DNS → добавить как DNS по умолчанию ПРИМЕЧАНИЕ: если у вас IP роутера другой (например, 192.168.0.1) — укажите свой. ====================================================================== ЧАСТЬ 12. ЗАЧЕМ AWG MANAGER И HYDRAROUTE NEO ====================================================================== После установки BIND штатная маршрутизация по DNS в роутере перестаёт работать. Остаётся только маршрутизация по IP — она продолжает работать как обычно. Чтобы вернуть удобную маршрутизацию по доменам (а не вручную вести списки IP-адресов), сверху ставим AWG Manager и HydraRoute Neo. ====================================================================== ЧАСТЬ 13. УСТАНОВКА AWG MANAGER ====================================================================== Способ 1 — через официальный репозиторий разработчика (используется встроенный busybox wget, curl не нужен): opkg update wget -qO- http://repo.hoaxisr.ru/install.sh | sh Способ 2 — через GitHub (HTTPS, безопаснее; нужен curl): opkg update opkg install curl curl -sL https://raw.githubusercontent.com/hoaxisr/awg-manager/develop/scripts/install.sh | sh Оба варианта — официальные, с репозитория разработчика. Ссылки на источник: https://github.com/hoaxisr/awg-manager После установки в консоли появится адрес веб-интерфейса. Открываем его в браузере. Включаем авторизацию: Настройки → продвинутый режим → авторизация. Логин/пароль — те же, что для входа в веб роутера. ====================================================================== ЧАСТЬ 14. УСТАНОВКА HYDRAROUTE NEO ====================================================================== В AWG Manager: Настройки → Интеграция → HydraRoute Neo → Установить. Откроется страница проекта на GitHub. Копируем команду установки и выполняем в терминале: opkg update && opkg install curl && curl -Ls "https://git.zerrolabs.org/Ground-Zerro/release/pages/keenetic/install-neo.sh" | sh Ждём завершения. Возвращаемся в AWG Manager — в разделе «Интеграция» появится HydraRoute Neo. ====================================================================== ЧАСТЬ 15. ВАЖНО: ПОЛИТИКА HYDRAROUTE ДОЛЖНА БЫТЬ НЕПУСТОЙ ====================================================================== Политика HydraRoute создаётся пустой. Пока в неё не добавлен интерфейс — hrneo пишет в логах: PolicyOrder: policy 'HydraRoute' not found, skipping и маршруты не строятся. Решение: добавить интерфейс в политику через веб-интерфейс роутера, в разделе «Приоритеты подключений». После этого hrneo увидит политику и начнёт строить маршруты. ====================================================================== ЧАСТЬ 15.5. ГДЕ НАСТРАИВАТЬ МАРШРУТЫ ====================================================================== Маршруты настраиваются в разделе HR Neo (вкладка «Маршрутизация»). ВАЖНО: не в NDMS и не в «IP-адресах». Эти разделы в AWG Manager относятся к другим сценариям (системные NDMS-туннели и статические IP-маршруты соответственно). Для маршрутизации по доменам используется именно HR Neo. ====================================================================== ЧАСТЬ 16. ФИНАЛЬНАЯ ПРОВЕРКА ПОСЛЕ ПЕРЕЗАГРУЗКИ ====================================================================== reboot После загрузки: ps | grep named | grep -v grep /opt/sbin/rndc status dig @127.0.0.1 google.com +short crontab -l ps | grep -E 'hrneo|awg' | grep -v grep Проверить, что маршрут строится: Открыть сайт из правила. Если показывает IP туннеля — маршрут работает. Если реальный IP — маршрут не построился, смотреть логи. ====================================================================== ИТОГ ====================================================================== Что получилось: - DNS не уходит провайдеру. - Есть резерв: если VPS/WG упал — BIND уходит в корень. - Маршрутизация по доменам работает автоматически, без ручного ведения IP-адресов. - Всё поднимается после перезагрузки.

Включен как TLS-проверка порта TCP. При отключении основного интернета продолжает показывать что инет доступен, если выключить и включить (ползунком) Подключения к интернету по Ethernet-кабелю то тогда показывает что интернета нет. Из за чего получается что автоматом на резервное подключение не уходит. Так уже несколько версий предварительной.

Уже несколько версий не горит индикация при использовании резервного подключения. При выборе Индикатор FN1 (когда используется WISP 2.4) не горит, при этом если выбрать на Индикатор FN2 то загораются сразу все индикаторы и при этом когда выбираешь на Индикатор FN2 то так же меняться и Индикатор FN1. То есть например на Индикатор FN1 стоял 2,4ГГц, а на Индикатор FN2 стоял 5ГГц то после обновление страницы на обоих будет стоят 5ГГц. В логах при смене вот: Авг 19 00:11:52 ndm Core::Peripheral::Manager: clear LED power schedule. Авг 19 00:11:52 ndm Core::Peripheral::Manager: set LED shutdown mode to "none". Авг 19 00:11:52 ndm Core::Peripheral::Manager: "WLAN/click" handler removed. Авг 19 00:11:52 ndm Core::Peripheral::Manager: "WLAN/double-click" handler set. Авг 19 00:11:52 ndm Core::Peripheral::Manager: "WLAN/hold" handler removed. Авг 19 00:11:52 ndm Core::Peripheral::Manager: "FN1/click" handler set. Авг 19 00:11:52 ndm Core::Peripheral::Manager: "FN1/double-click" handler removed. Авг 19 00:11:52 ndm Core::Peripheral::Manager: "FN1/hold" handler removed. Авг 19 00:11:52 ndm Core::Peripheral::Manager: "FN2/click" handler set. Авг 19 00:11:52 ndm Core::Peripheral::Manager: "FN2/double-click" handler removed. Авг 19 00:11:52 ndm Core::Peripheral::Manager: "FN2/hold" handler removed. Авг 19 00:11:53 ndm Network::Interface::Led: selected WAN WifiMaster0/WifiStation0. Авг 19 00:11:53 ndm Network::Interface::Led: selected WAN WifiMaster1/WifiStation0. Авг 19 00:11:53 ndm Core::Peripheral::Manager: "SelectedWan" control bound to "FN_1" LED. Авг 19 00:11:53 ndm Core::Peripheral::Manager: "SelectedWan" control bound to "FN_2" LED. Авг 19 00:11:53 ndm Core::System::StartupConfig: saving (http/rci).

И что по итогу 7 месяцев спустя? То есть получается Мы Все оказались правы в том что Вы просто выбрали модель что по возмущаются и перестанут и ни чего с принудительным обновлением делать не надо?

5.1 Beta 4 проблема ушла!

Аналогично было.

не подключает ретранслятор (kn-1610 прошивка 4.3.6.2) основной NZ-1812 на вкладке горит ошибка в виде предупреждения (к сожалению не заскринил). ретранслятор пытается переподключиться и потом уходит в перезагрузку и всё по новой. после отката на beta 2 всё нормально. UDP: 5.1 Beta 4 проблема ушла!

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

UDP: 5.1 Beta 0.2 проблема ушла

Я уже два раза пробовал одно и тоже, просто тишина. Перехожу на 5.0.8 сразу всё работает. Устройство 1812. Странно вообщем Я даже пробовал компоненте переустанавливать не помогло.

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

Не работает ping check. При отключении основного интернета на стороне провайдера показывает что интернет доступен. Стоит проверка TLS-проверка порта TCP. При переходе на предварительный канал и прошивку 5.0.7 всё работает корректно.

При редактировании политики доступа после нажатия кнопки сохранить ушёл в перезагрузку. Делал изменения в трёх политиках и сохранял всё нормально, на четвёртой политике после нажатия сохранить перезагрузка. После работает штатно, изменения на котором произошла перезагрузка не сохранил. В логах ни чего нет. (NC-1812)

Вот ещё странная вещь😂 Включил всё по максимуму на 2.4 тоже (кроме мощности там 75%) и скорость стала стабильной. (до этого было выключено OFDMA DL/UL, на приём и Target Wake Time что по идее на стандарт AC влиять не должно). Но всё заработало, скорость держит стабильно.

Опытным путём: На 2.4 поставил b/g/n, а на 5 а/n/ac и это помогло стабильно держит скорость. Если ставишь 2.4 b/g/n/ax, 5 n/ac/ax скорость начинает прыгает. Оставил 2.4 b/g/n/ax на 5 поменял на a/n/ac без изменений просаживается, а когда вернул ещё и 2.4 на b/g/n нормализовалось. То есть нормально работает при условии 2.4 b/g/n, 5 a/n/ac. Если просто выключить 2.4, а на 5 поставить a/n/ac/ax скорость прыгает, если на 5 поставить n/ac/ax/be при выключенном 2.4 скорость стабильно держится, включаешь 2.4 рухает скрость. Если устройство ограничить выбором только 5ГГц но при этом 2.4 включено то скорость всё равно падает. А вот выключаю 2.4 и нормализуется. Как 2.4 к этому подвязано не знаю телефон работает на 5ГГц в доме постоянно.

Исходя из сегодняшних реалий ограничения и блокировки могут быть разные и как вариант: В случае не ответа всех прописанных DOT/DOH раз по пять, что бы роутер переключался на обычный DNS если Он прописан до того момента пока не станут доступны. Конечно ж что бы включалось опционально галочкой (например как игнорировать DNS провайдера) может кто то не защищёнными не хочет пользоваться (все не хотят конечно кто про это знает). А то не дай бог решат их все заблокировать и получится что без физического доступа к роутеру интернета на нём не будет. UDP: Реализовал так. Работает стабильно.

Как Я правильно понимаю роутер это собственность человека который его купил. ПО в роутере используется на основе Лицензионного соглашение которые владелец принимает при его первоначальной настройке в котором есть пункт 6, а именно 6.3 на который так ссылаются все. Где написано: ".... При включённой функции «Автоматическое обновление ПО» Ваше Оборудование периодически загружает и устанавливает Обновления автоматически. Если Вы решите отключить функцию «Автоматическое обновление ПО», Вы сможете проверять наличие новых Обновлений в разделе меню «Общие настройки системы» и устанавливать их, нажав на кнопку «Установить обновления».". Весь вопрос в том, обновлять Сами не могли. Понять, простить и забыть🤣. Люди просят только одно сделайте полный запрет на обновления и полный запрет на взаимодействие с какими либо службами из вне которые не управляются не посредственно с роутера и его не посредственным владельцем (то-есть что бы компания производитель не могла удалённо что либо делать как бы экстренно по их мнению это не было.). Вы уже написали что над обновлениями думаете, будем ждать Вашего решения и очень надеемся что это не из разряда " что обещанного три года ждут". Так как не всегда обновления встают так как Всем хочется (без сбоев).

Доказывает ("...Ни кто не вспомнит о заслугах, после небольшой не удачи"), но вызвало не понимания почему не дали внятного разъяснения, что продукт оказался под угрозой и что бы избежать дальнейшего распространения на большую часть устройств было принято не простое решение задействовать экстренный механизм. Ни каких других скрытых возможностей Он не несёт кроме как дать команду на обновление. Понимаем что из за сложной ситуации доставили не удобства некоторым пользователям. В дальнейшем продумаем функционал этого. (Так как говорить о бизнес продуктах с такой функцией не приходится ни кто сознательно не согласится. Только гос заказ или знакомые, где первые будут крайне не довольны если такое не дай Бог произойдёт). Так что надо было просто разъяснить. По факту это закрыло возможность для не сознательных пользователей игнорировать свою же безопасность. Устройства которые пострадали они уже пострадали ведь этот патч слава богу не сбросил все устройства до заводских. Фиг знает как это сделать, но это точно нужно, не хорошие люди всё равно всегда найдут возможность, так как слабое звено это пользователь, а люди которые на этой системе офисы строят они осознают риски и по этому обновляют руками.

Вот второй день пошёл этой ситуации, все задают конкретный вопрос как это отключить (способ есть правда топорный и кажется совсем не надёжный) и нет ли других скрытых функций удалённого использования Наших устройств компанией производителем. И нам второй день отвечают на что угодно только не на это. Извинения от Ильи это хорошо конечно но Мне кажется что Он вообще к этому отношения не имеет Он и ещё два человека в ТГ отдуваются за всю компанию при этом как кажется по собственной инициативе и спасибо Им за это! (Когда и как будет отключена эта возможность, есть ли другие скрытые функции всё больше ни чего не интересуют.) То что достаточно много людей получило проблемы с пустого места это все поймут и забудут, а вот то что функционал пытаются заболтать вряд-ли. Через cli что было бы логично что бы Ваши не наглядные домохозяйки не пострадали или в интерфейсе сделаете критические обновления / обновления это не важно. Скажите по пунктам сделаем не сделаем, как если да и то что ни чего другого сделать удалённо компания не может. Утром бы статью на сайте сделали бы и вопрос закрыт был бы, так нет пошли путём повозмущаются и перестанут. Не хорошо это.