AminDesu

Так а что реализовывать? - HTTPS шагает по планете, ресурсов, поддерживающих HTTP, с каждым годом всё меньше и меньше - URL (целиком, а не лишь домен) в HTTPS увидеть никак нельзя (кроме как MitM-ить, но если это делать на роутере, то станут недоступны все ресурсы с HTTPS pinning, начиная с гугловских) Складывая первое со вторым, получаем, что реализовывать тут нечего. Даже DPI у провайдеров видит лишь домен, про URL они не мечтают (в Казахстане помечтали, заставив пользователей ставить гос.сертификат для расшифровки трафика - это ничем хорошим не кончилось)

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

Суммирую: - настройка "Автоматическое обновление операционной системы" отвечает ровно за то, о чём написано - за автоматическое обновление, читай "замену прошивки роутера" - "Автоматическая проверка наличия обновлений" это другая функция, на данный момент не отключаемая - объединять их в одну не следует, поскольку это лишает пользователя возможности узнать о наличии обновления (например, через мобильное приложение), а также снижает число пользователей, своевременно устанавливающих обновления (пользователь лишается возможности оперативно узнать о наличии обновления и принять решение о его установке, а когда он полезет узнавать о нём руками - бог его знает, все пользователи люди и все они несовершенны) - к падению привело несчастливое стечение обстоятельств: одновременно наличие бага в прошивке, который приводил к падениям при получении некорректного ответа от сервера, и сбой на сервере, в результате которого сервер стал отдавать некорректные сведения. Любой из этих багов по отдельности совершенно безобиден - за всю историю Zyxel/Keenetic такого ещё не случалось, вдобавок, разработчики сделали вывод и настроили некий механизм, предотвращающий возникновение подобного на сервере Отключение проверки обновлений, в общем-то, мало что даст: 1) код, отвечающий за эту проверку только что подвергся пристальному вниманию и конкретно в нём вероятность повторения ниже, чем в прочих компонентах, обменивающихся данными с облаком 2) никто не мешает параноидально настроенным пользователям запретить роутеру обмен данными с сервером, указав, что доменное имя сервера должно резолвится, например, в 0.0.0.0 или 127.0.0.1 командой ip host

За раздачу обновлений. Роутер ходит туда проверить наличие новой версии прошивки (чтобы обновиться автоматически, если автоматическое обновление включено, либо показать пользователю, что есть новая версия прошивки, если автоматическое обновление выключено).

Нет, речь о проверке обновлений. Сервер в ответ по ошибке отдавал лабуду, от которой из-за ошибки в прошивке прошивка перезагружалась. У других производителей с этим проще - через годик-два модель снимается с поддержки и пользователь не получит обновления уже никогда, взамен, видимо, получая некоторое призрачное утешение, что никто никуда не рулит.

Да, набор компонентов один и тот же. Если сделать откат, то восстанавливается старое поведение.

Скрипты в папке /opt/etc/ndm/neighbour.d/ запускаются при каких-то событиях с каким-то устройством в сети, к примеру подключение-отключение. В качестве параметров скрипту передаются некоторые переменные, которые позволяют идентифицировать устройство и событие. В 3.7 что-то изменилось/сломалось и некоторые события не приходят. Вот скрипт /opt/etc/ndm/neighbour.d/010-run.sh #!/bin/sh echo $id >> /opt/etc/ndm/neighbour.d/1.txt echo $update >> /opt/etc/ndm/neighbour.d/1.txt echo $action >> /opt/etc/ndm/neighbour.d/1.txt echo $address >> /opt/etc/ndm/neighbour.d/1.txt Если в 3.6 после создания скрипта отключить/включить вайфай на телефоне, подключённом к роутеру, то в 1.txt будет что-то типа 13 none new ipv4 А в 3.7 получаем ip6list update ipv6 20 Вдобавок, события или не приходят, или (иногда, когда приходят) с огромной задержкой.