Denis P

1. При создании статического ipv4 маршрута он не отображается и не сохраняется в running-config, хотя отображается в списке действующих и продолжает работать. 2. При создании ipv6 маршрута в выпадающем списке отсутствуют интерфейсы типа TunnelSixInFour это же касается и пинхолинга ipv6 3. При создании ipv6 маршрута обязательным является указание шлюза - через cli таких ограничений нет + при указании любого шлюза получаем ошибку "IP-адрес из другой подсети"

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

Тут больше и не будет.

Что делали? Что не получается? Управление портами ретранслятора есть на вкладке Wi-Fi система на контроллере, отмечаем чекбоксом нужный ретранслятор и вуаля

это не так устроено, в этом случае у вас бы не работал ни кинднс, ни приложение/облако, ни сервера обновлений.

в данный момент выглядит это довольно своеобразно, еще и с сайд скролом, на fhd

потому что для локальных сегментов включен ip nat по умолчанию, это можно увидеть в конфиге, например ip nat Home его нужно отключить и делать уже выборочно, в необходимые интерфейсы

Эта ругань не относится к проблеме и вызвана тем что вы используете opkg и скрипт в netfilter.d который вносит изменения в iptables, а сам iptables у вас не обновлен.

специфику работы конкретно вашего телефона исключаете? на других пробовали? специально выше приводил пример устройства которому 10+ лет, что на нем что на современных устройствах лично я проблем не вижу, проверял минимум на 5 телефонах и даже при initial setup. Разработчики вам скажут то же что и я - приложение должно работать локально без доступа в интернет, это заложено в его логику, с частными случаями нужно разбираться в частном порядке, по этому и предложил вам проследовать в техподдержку

Вы смешали в кучу open connect и openVPN это два разных протокола и настраиваются они отдельно

Другие, которые взаимодействуют с локальными устройствами?

невозможно приложение заставить работать напрямую если сам телефон не хочет использовать это подкючение, это логика на уровне системы, а не приложения вот даже картиночка со старого андроида и последнего актуального приложения, на котором спокойно можно отключать все интерфейсы для чего ему не требуется "интернет". а за официальными ответами всегда можно сходить сюда, если "пользовательские" вам кажутся не убедительными https://support.keenetic.ru/

это были не предположения, а факты приведенные не только мной но и другим участником дискуссии, у самого на руках несколько телефонов с "тупым андроидом" самый старый на android 9, на котором локальный доступ тоже работает, как раз по озвученному выше сценарию, на нем достаточно убрать "передачу данных в мобильной сети, для этого отдельная кнопочка есть, не обязательно дергать симку. В этом момент вы с этого самого телефона в веб кинетика попасть можете?

Скорее наоборот)

дело как раз в этом (наблюдаются при запрете транзита даже при использовании только адресов от провайдера) , но техподдержка уверяет что ошибки вызваны блокировкой dot/doh и других публичных серверов, в том числе и plaintext. с чем я в корне не согласен потому что в этом случае ошибки были бы и с разрешенным транзитом, тем более речь о request т.е query, а не response upd нашел подтверждение своим предположениям, какой-то софт на телефонах шлет соответственно, если перехвата нет, пакет улетает и кинетик не при делах а если стоит перехват запросов, dns-proxy не понимает чего с ним делать и сыпет ошибками в лог, а иногда видимо и умирает, в следующем скрытом сообщении дампы трафика. соответственно никакое ТСПУ/dpi и не может трогать наши пакеты в локалке

Вот так и влияет, телефон не видит "интернета" по Wi-Fi и ломится через мобильную сеть, в которой конечно же никого и нет. Отключите передачу данных и увидите что локальный доступ работает по wifi

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

она там уже есть

да, извиняюсь, действительно в beta0 теперь ip nat не слетает если задать его вручную на интерфейсе сервера. В предыдущей версии при изменении состояния интерфейса параметр пропадал. Спасибо.

да что вы говорите? не может этого быть

@eralde@Le ecureuil по поводу ip nat отдельную тему заводить? она вроде как и веба касается и самой логики, клиентов по прежнему нельзя нормально пустить в интернеты на 5beta0 да и qr код в темной теме по прежнему отсканировать нельзя, вот для примера как это сделано у тплинков, qr код в рамке, как раз подходящее решение для того чтобы телефоны не сходили с ума в попытках его считать

Действительно, одна лишь заграница, никакого праздника) speed-vld.vtt.net speed-vgd.vtt.net speed-nn.vtt.net speed-sma.vtt.net speed-sar.vtt.net speed.vtt.net speed-ufa.vtt.net spd-rudp.hostkey.ru

с последнего обновления пакетов прошло 3 месяца, вы куда-то торопитесь?

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

потому что это не статические маршруты, а маркировка пакетов и последующих соединений (CONNMARK) подпадающих под определенные ipset'ы, т.е совсем другая логика