dchusovitin

На 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 и выполняется резолв.