Александр Рыжов

SmartBOX Turbo+ у Билайна выпускается с ZegBee-чипом. IMHO, присутствие этого чипа почти никто не заметил.

Ничего вы не поправили:(

opkg install gawk И поправить shebang в /opt/bin/egrep, как временное решение, в будущем мы подредактируем соответствующий пакет.

@Станислав Поветьев, кинетик устанавливает эти заголовки. А разбирает ли эти заголовки на своей стороне синолоджи?

С собственным доменом логично использовать собственный nginx.

Гляньте потом на https://netboot.xyz/ Вероятно, там уже есть всё, что вам надо.

В отличие от остальных это mesh. Т.е. выход на нужную ноду будет найден через посредников, если напрямую она не доступна. Нагрузка каналов между двух нод при прямом подключении никак не сказывается на остальных. Присоединять новую ноду можно по коду-инвайту. Что не исключает перечисленных минусов, включая тормознутость, невозможность аппаратного ускорения шифров и пр.

@Max Z, тут красивого решения нет. Изначально PID-файлы должны находиться в tmpfs и теряться при внезапной перезагрузке. Наличие pid-файла без процесса говорит лишь о том, что сервис не был остановлен правильно.

Спасибо за скрипт запуска, поместим в следующий релиз пакета. Недостающие папки создадим.

По сути, это Debian'овский пакет без каких-либо правок. Вероятно, подразумевалось, что RTC на больших компьютерах «тикают» всегда в UTC. Пока грациозного решения я не вижу, да и для кинетиков оно не сильно актуально.

Наш косяк. Поправил, обновите пакет.

Собран и находится в основном репозитории. opkg install nextdns Обратная связь и/или скрипт запуска приветствуются.

Образ флеша пожат, upx здесь не нужен.

Почему? В syslog-сервер события ложатся последовательно по мере прибывания, просто с разными time stamp'ами. Отнюдь. Это в т.ч. бережёт от следующей циклической ситуации: Имя NTP-сервера не может быть разрешено, т.к. пока не работает DNS, DoH/DoT DNS не может подняться, т.к. сертификаты пока не валидны по времени.

Зря цепляетесь, там затёрт IP-адрес. SSL-сертификаты будут невалидны, а так-то да. От железячечки без RTC чего-то серьёзного в плане точности времени можно не требовать. Если обратили внимание, после ребута роутер достаёт "текущее" время из последнего сохранённого конфига.

Сколько раз висеть?:) ~$ sudo grep -i synchronized /var/log/x.x.x.x-syslog … Jun 8 04:13:01 x.x.x.x ndm: Ntp::Client: time synchronized with "0.pool.ntp.org". Jun 9 19:25:41 x.x.x.x ndm: Ntp::Client: time synchronized with "3.pool.ntp.org". Jun 16 19:25:53 x.x.x.x ndm: Ntp::Client: time synchronized with "0.pool.ntp.org". Jun 23 19:26:44 x.x.x.x ndm: Ntp::Client: time synchronized with "3.pool.ntp.org". Jun 30 19:27:16 x.x.x.x ndm: Ntp::Client: time synchronized with "0.pool.ntp.org". Jul 7 19:27:47 x.x.x.x ndm: Ntp::Client: time synchronized with "1.pool.ntp.org". Jul 9 21:47:39 x.x.x.x ndm: Ntp::Client: time synchronized with "1.pool.ntp.org". Jul 14 19:41:03 x.x.x.x ndm: Ntp::Client: time synchronized with "2.pool.ntp.org". Jul 16 16:16:04 x.x.x.x ndm: Ntp::Client: time synchronized with "2.pool.ntp.org". Jul 23 16:16:15 x.x.x.x ndm: Ntp::Client: time synchronized with "3.pool.ntp.org". Jul 30 16:16:36 x.x.x.x ndm: Ntp::Client: time synchronized with "1.pool.ntp.org". Aug 6 16:16:47 x.x.x.x ndm: Ntp::Client: time synchronized with "2.pool.ntp.org". Aug 13 16:16:59 x.x.x.x ndm: Ntp::Client: time synchronized with "3.pool.ntp.org". Aug 20 16:17:10 x.x.x.x ndm: Ntp::Client: time synchronized with "0.pool.ntp.org". Aug 26 18:58:38 x.x.x.x ndm: Ntp::Client: time synchronized with "2.pool.ntp.org". Т.е. раз в несколько дней потенциально тратить на ожидание завершения синхронизации времени несколько дополнительных миллисекунд. Я бы не доверил роутеру автоматический выбор какого-либо внешнего сервиса, будь-то NTP или DNS или ещё что-то, если это потенциально может привнести доселе отсутствующие проблемы.

В конце статьи: Что-то я не уверен, что внутренний MIPS clocksource способен обеспечить такую точность. А при использовании CONFIG_RALINK_CPUSLEEP вообще суточный дрейф до нескольких секунд.

Роутер предназначен для работы с транзитным трафиком. Полагаться на показания скорости, намерянные с самого роутера не надо: CPU роутера слишком слаб для этого.

Entware-3x уже два года как заморожен и никакой поддержки по нему авторы не обеспечивают. Есть что-то специфичное, чего нет в Entware?

https://entware.net/2020/06/15/Changelog.html

Да, там хотели кое-что изменить в поведении. Полгода всё же прошло.

В случае L2TP будет отдельный сетевой интерфейс, маршрутизацию с которым вы сможете настроить как вам угодно.

Недостаток в том, что виден весь перечень существующих соединений?

На системе назначения не реализованы нужные sycall'ы, увы.

Именно поэтому и уточнял, потому что мне до сих пор непонятно: зачем между роутером и NAS'ом два гигабита, если дальше все соединения (все два:)) будут не шире одного гигабита. Отказоустойчивость, т.е. недоверие гигабитному кабелю? Тоже не понятно, простите. К клиентам дальше будет идти по одному вместо пары.