HuduGuru

Добавочка: С дефолтными настройками chronyd работает только как клиент. Чтобы он начал работать как сервер времени (т.е. отвечал другим клиентам на запросы), нужно В конфигурацию добавить строчку с разрешениями, в простейшем варианте - разрешить всем: allow или подробнее см. man chrony.conf в Интернете Перезапустить службу.

fake-hwclock для сохранения времени использует команду date с ключём -u, т.е. время сохраняется как UTC (от московского это -3 часа). При восстановление тоже используется ключ -u, но время при этом восстанавливается без учёта часового пояса, т.е. те же -3 часа от московского. Рекомендация в больших Linux-ах - время в аппаратных часах должно быть UTC, а "программное время" - в соответствии с локалями. Как это соблюсти пока не придумал, просто убрал ключи -u в сценарии fake-hwclock для порядка.

В наборе пакетов OPKG появился пакет chrony (демон chronyd) - альтернатива NTP, в настоящее время рекомендованная к применению в "больших" Linux-ах вместо ntp. В частности, chronyd, в отличие от NTP: не умирает молча, обнаружив слишком большое отклонение времени, а пытается исправить ситуацию; работает в ситуациях, когда порт 123 закрыт для исходящих запросов (т.к. для своих запросов использует непривилегированные порты, а в ntp порт 123 для исходящих запросов зашит жёстко). Установка стандартная (перед установкой не забудьте удалить ntp, если он был установлен): opkg insta

Да, у меня это выглядело примерно так же, а трафик был. Важный нюанс я, однако, забыл упомянуть в первом сообщении: у меня роутер с белым адресом в Интернете торчит.

Обнаружил у себя аналогичную проблему - огромный исходящий трафик, видимый в странице "Системный монитор" в WEB-интерфейсе. Методом исключения нашёл виновника: dnscrypt-proxy2. Нашел эту ветку на форме. Никакие указанные здесь команды типа "tcpdump port 53 -n -nn -v" никакого ненормального трафика не показывают, показывает только "Системный монитор". После чтения темы добавил через WEB-интерфейс "первыми" два правила запрета входящих пакетов на 53-й порт: 1) для TCP и 2) для UDP. Исходящий трафик исчез.

Для ускорения генерации ключей рекомендую перед запуском скрипта ставить пакет haveged - генератор энтропии. opkg install haveged /opt/etc/init.d/S02haveged start

Восстанавливаю Entware, пара копеек про установку dnscypt-proxy2 на "чистую" систему: Для того, чтобы блэклисты нормально скачивались, сначала нужно установить пакет ca_certificates: opkg update && opkg install ca_certificates

Вроде заработало.

После замены sources на opennic всё перестаёт работать.

ndmq -x -p "more flash:startup-config" | sed -e "/^[[:space:]]*<.*>[[:space:]]*$/d"

Перезагрузил роутер, dropbear поднялся автоматически, всё работает. Непонятный глюк. Спасибо за помощь.

В логах про dropbear есть только, что он работал утром. Ага, ps говорит, что не работает. Перезапустил через web-морду. Заработало. Спасибо! Остается понять, что сделать дальше во избежание повторения.

1. В логе много чего, но ничего про подключения. И с Кинетиком, собственнно, ничего - работает, я через него пишу. Логи видно через работающий web - работают, tail -f всё исправно показывает. 2. Утром обновил прошивку Кинетика, выше написано на какую. Обновил после этого всё OPKG через командную строку update/upgrade. Была одна ошибка - mosquitto сказало, что файл новой версии не соответствует старому, проигнорировал. После этого - отключал питание. Полный набор 3. Через web-морду доступ есть, понять бы, куда смотреть. Можно ещё вынуть флешку, посмотреть, что там. Тоже - а куда

Нет, то же самое, refused, версия там постарше.

Не могу войти из самой распоследней утром обновлённой Убунты через мате-терминал на Keenetic Giga II с тоже утром установленными обновлениями говорит, что connection refused При этом OPKG работает, XMail отвечает, web:88 рабтает, и, что для меня самое удивительное - даже можно войти в командную строку через web:88, и убедиться, что всё работает. Но отвалился расшаренный под Windows USB-flash Прошу подсказать, что это, куда копать, чтобы восстановить SHH?