dchusovitin

Это поведение по умолчанию, практически на всех телефонах. На android уж точно, где у каждого производителя своя прошивка и тьма модификаций. Дергает внешний URL, если не доступен, то сразу переключает на моб. сеть (при этом wifi подключен, но трафик не идет через нее), либо может выскочить окно "продолжить использовать wifi" (но никаких гарантий). 3 разных телефона, все переходят на моб. в течении 30-60 секунд. Способ отключить есть, но не в обычных настройках

Спасибо, наконец настроил, после того как затер "лишний" файл конфигурации Еще было бы полезно добавить хук (вызов внешнего скрипта) после создания архива, чтобы можно было заливать бэкап в любое место (rclone, scp, ...), без правки скрипта. Плюс другие действия, вроде ротации бэкапов. Локально сделал. Если доберусь до меню настройки, то пулл-реквест отправлю =)

5.0 Alpha 12 - актуально. PS. Отправлю self-test в следующем сообщение, возможно дело в комбинации настроек (не только включение opkg). Смена языка не влияет.

На 5.0 A5 появилось такое же сообщение. При даунгрейде до 3 и 4 альфы повторяется. [C] Jun 22 23:51:36 ndm: Thread: "Opkg task queue": lock precedence violation: DNS_ENGINES (8) after OPTWARE (54). [C] Jun 22 23:51:36 ndm: Thread: "Opkg task queue" (839) backtrace: [C] Jun 22 23:51:36 ndm: Thread: Dns::Manager::EnableFilterEngine(CString const&)+0x30 [C] Jun 22 23:51:36 ndm: Thread: Opkg::(anonymous namespace)::Init_::Run()+0x48 [C] Jun 22 23:51:36 ndm: Thread: Task::Thread::Run_()+0x150 [C] Jun 22 23:51:36 ndm: Thread: Task::Thread::Run()+0x18 [C] Jun 22 23:51:36 ndm: Thread: Thread::StartRoutine_(void*)+0x2cc [C] Jun 22 23:51:36 ndm: Thread: start()+0x90 [C] Jun 22 23:51:36 ndm: Thread: __clone()+0x34 self-test в следующем сообщении

Установить можно так: # Заходим в аккаунт, создаем токен - https://my.zerotier.com/account export TOKEN=auth_token export NETWORK_ID=my_network_id # Получаем параметры сети и MTU curl -X GET "https://my.zerotier.com/api/network/${NETWORK_ID}" -H "Authorization: bearer ${TOKEN}" # Устанавливаем значение MTU curl -X POST "https://my.zerotier.com/api/network/${NETWORK_ID}" -H "Authorization: bearer ${TOKEN}" -d '{"config": {"mtu": 2800 }}'

При изменении настроек ZeroTier подключения через веб, они сохраняются, но не применяются к интерфейсу. MTU 2800 - значение по-умолчанию самой вирт. сети ZT (проставляется при создании, можно изменить через API), которое Keenetic умеет использовать. Предварительно изменил MTU на 1199, значение прописалось в настройки. Перезагрузил устройство, "реальное" MTU сбросилось в значение 2800. Через web меняю значение на 1299, MTU интерфейса осталось 2800. Через cli меняю значение на 2799. Команда отработала, MTU изменился. (* до первого вкл/выкл) Через web меняю значение на 1399, MTU интерфейса сбросилось в 2800. Тут cделал self-test (в следующем сообщении). Будет видно различия на предыдущем шаге. -- "no ip mtu" - отрабатывает корректно, но сбрасывает значение на 1500. Вопрос только в значении, т.к. оно должно быть 2800. Делал после self-test. После тестов мне кажется, что сначала устанавливается значение из конфигурации, потом подтягивается зашитый 2800 (где-то в клиенте/прошивке), потом меняется на значение сети ZT (если установлено отличное от 2800). Проскакивают изменения MTU, если периодически вызывать "show interface" в момент старта. "interface debug" не помог. -- Веб разрешает установить MTU только в диапазоне 576-1500. Но для виртуальной ZT сети разрешен диапозон 1280-10000 (ссылка), ведь это он меняется. C MTU>1500 проблем нет, пока пакеты ходят между двумя точками, где поднят ZT интерфейс. Сюрпризы могут начаться, когда они пересылаются далее (через маршруты в локальную сеть, например). Об этом можно сделать предупреждение в вебе. Отдельно существует PHYSMTU (ZT_DEFAULT_PHYSMTU=1432, "Default UDP payload size (physical path MTU)", ссылка). Который можно менять через local.conf (ссылка). Тут не уверен, не было особой необходимости менять оба значения. Использовать один или оба - решать вам 😃 -- Возможно сломалось при добавлении веба и/или недавнем обновлении клиента в прошивке до 1.14.2.

Я бы попробовал подобрать рабочий сервер, без использования asc. Шанс есть, но от провайдера конечно зависит. CloudflareWarpSpeedTest выдает список IP/порт с меньшей задержкой. И asc не забыть убрать.

Без dns-override. Тут на 5 раз все перепроверял, плюс в чистом окружении. Даже через strace смотрел за процессом ndnproxy 😀

Если DNS запрос поступает от локального клиента и апстрим возвращает ошибку, то DNS сервер (ndnproxy) не возвращает ответ клиенту. Проверялось с 4.3.2, 5.0 Alpha 3 Воспроизводится, если запрос идет от 127.0.0.1 и апстрим возвращает - SERVFAIL, NXDOMAIN, REFUSED. Если запрос поступает с любого другого IP (127.0.0.2, 78.47.125.180, 192.168.1.1), то сервер (ndnproxy) возвращает ответ. Можно воспроизвести, если установить 1.1.1.1:53 в качестве апстрим DNS (через системный профиль, либо у ethernet подключения) и запрашивая домены - ftp.ru.debian.org, www.rshb.ru Либо любой несуществующий домен, чтобы был ответ NXDOMAIN. PS. Некоторые NS серверы заблокировали подключения из вне (РФ) и забанили Cloudflare. CF для примера и воспроизведения (возвращает SERVFAIL для указанных доменов). Проверялось на чистом entware. Дополнительно с тестовым сервером в локальной сети, для определения кодов ошибок. Примеры dig + tcpdump: self-test в следующем сообщении (5.0 Alpha 3).

Проверял в разных браузерах, а про самое главное забыл. Дело во включенном opkg и "opkg dns-override" 😃 Запускаем роутер с вышеуказанными настройками ("Интернет-фильтр" на главной странице у WAN интерфейса - OPKG). В списке отображается "undefined". Заходим в раздел "Интернет-фильтры" - "Контентный фильтр". "Режим фильтрации" пустой. Выбираем "Публичные". В нужном нам списке пропал "undefined", т.е. все отображается нормально. Перезагружаем роутер, "Интернет-фильтр" сбрасывается на OPKG (что нормально). И в списке опять появляется "undefined". "undefined" каждый раз глаза мазолит 😃 Либо скрыть выбор профилей со страницы, как при выключенном интернет-фильтре.

Список клиентов -> Настройки для незарегистрированных клиентов "undefined" в выпадающем списке, вместо названия раздела. Первый скриншот. Список "Интернет-фильтр" для зарегистрированого клиента отображается нормально, без этого "подраздела". Второй скриншот. PS. На 5.0 Alpha тоже самое. Насколько помню, это уже давно так, как минимум с тестовых 4.2.

Отлично 👍 Проблема больше не повторялась. Были попытки воспроизвести (методом "тыка"), но не получилось.

Вдруг посыпались огромное количество ошибок, хотя за неделю не заметил особых проблем с данной версией прошивки. Перед появлением ошибок: Были проблемы с подключением (позже переключился на WISP) Включал WISP (5 ггц) Изменил политику подключения у одного клиента self-test в следующем сообщении.

4.0.6 preview: оригинальная проблема исправлена ("Dns::InterfaceSpecific: system failed [0xcffd0525], unable to find TunnelSixInFour0. ")

Немного дополню оригинальный пост. В данном случае важен только "Origin" заголовок. Добавить опцию, чтобы была возможность передавать заголовок "как есть", без изменения / удаления. Для раздела "Доступ к веб-приложениям домашней сети". Видимо сделано из соображений безопасности, но хотело бы (в некоторых случаях это нужно) иметь контроль над настройкой. Требуется для возможности отправки запросов с другого домена, "из браузера" (CORS). Разрешенить упраление через CLI. По аналогии с опициями "preserve-host", "x-real-ip" в разделе "ip http proxy xxx".

Воспроизводится на 4.1 Alpha 11. Сделал даунгрейд до 4.0.5 (preview) - также появляется сообщение в логе. Возможно дело в конфигурации (после даунгрейда с той же конфигурацией), но не очень похоже. Dns::InterfaceSpecific: system failed [0xcffd0525], unable to find TunnelSixInFour0.

4.1 Alpha 9 Видимо какие-то правки делали для этой версии. Изменился "код ошибки" и добавилась доп. информация. Интерфейс TunnelSixInFour0 присутствует в системе и работает. Dns::InterfaceSpecific: system failed [0xcffd0525], unable to find TunnelSixInFour0. Self-test в следующем сообщении

После обноления со стабильной 4.0.4 до 4.1 Alpha 7 начало переодически появляться сообщение в логах: Все сообщения с одним "кодом" (0xcffd0523), каких-то проблем с DNS не заметно. Используются DoH сервера. Возможно когда DNS не в кеше dns-proxy и выполняется резолв.

Какой бот? Вполне вероятно, что ему только для сборки нужна 19 версия, а работать он может и на старых версиях. Либо версию поставили от балды. Немного действий и скоре всего заведется.

А если заменить "cloudflare-dns.com" на "one.one.one.one", то такие же ошибки? Либо просто в браузере проверить. У меня провайдер (точнее кто-то чуть выше) часто "блокирует" этот домен (и его адреса). Ping, traceroute, tcptraceroute проходит, но ответ не приходит и все отваливается по таймауту. В вашем случае больше похоже, что провайдер блокирует. Если 1.1.1.1 / 1.0.0.1 / one.one.one.one прописать, то никаких проблем.

Должны исправить, писал в поддержку. Воспроизведелние ошибки у другого пользователя помогло 😃 NDM-2784