Albram

По идее и в 3.9.5 такого не должно быть. Вернее, в любой релизной версии.

Контент фильтры не выбраны. В профиле DNS "Системный" указаны DNS провайдера ipv4 и ipv6, и по ipv4 всё работает, т.е. клиенты получают в качестве ipv4 DNS только адрес контроллера (Ультры) и все запросы работают, на ipv4 адресе ретранслятора DNS запросы не работают, но меня это вполне устраивает. Надеялся, что с ipv6 будет тоже самое, но нет. Сейчас попробовал выбрать фильтрацию "Публичные DNS-резолверы и настраиваемы профили" и всем подключениям и устройствам выбрать профиль "Системный". Без перезагрузки ничего не изменилось. После перезагрузки контроллера и клиентского компа, подключенного к контроллеру проводом, комп получил в качестве адреса ipv6 сервера DNS ipv6 LL адрес контроллера, и DNS запросы отрабатываются. Понаблюдаю как будет дальше. Но на ретрансляторе (его позже тоже перезагрузил) остался "косяк" с отображением в CLI DNS ipv6, и таблицы статистики (в ней нет DNS ipv6). В веб-интерфейсе ретранслятора этот DNS ipv6 виден.

Приветствую всех! Ultra KN-1810 и Viva KN-1910 (версия KeenOS на обоих 3.9.5) объединены в Mesh, на Ultra настроен ipv6 от провайдера (префикс /56). Клиенты сети периодически получают в качестве DNS сервера LL ipv6 адрес Viva, которая является ретранслятором, и DNS запросы не работают. Думал, ерунда, добавлю в Виву LL ipv6 адрес Ультры в качестdе DNS сервера (как это сделано для ipv4), но не тут-то было: команда ipv6 name server <address> добавляет адрес, но как-то коряво, не отдельной строкой, а "подтягивая" к себе предыдущую строку конфига "norebind_ctl = on", и в таблице статистики ниже он не появляется, и ничего на клиентах не меняется, они по прежнему периодически получают в качестве DNS сервера LL ipv6 адрес Viva:

Вот отсюда начинайте, с установки Entware.

В сторону сетевого подключения смотрели? Драйвер сетевой в WIndiws 7 обновить (если доступен), кабель проверить, iperf запустить на компе и роутере, и сравнить с результатами iperf там, где Windows 10.

"Иногда, лучше жевать, чем говорить". Факты выложены в скрытом сообщении, но они не про Вашу честь.

Притом, что уходит в ступор от 5-8ГБ сохранения (примерно столько успевает перенестись за полчаса). И дело, скорее всего, не в Windows, просто в 10-ке процедура первого сохранения была давно, и ежедневно просто добавлялось понемногу, и возможно, если бы там запустить такой же объём, то было бы тоже самое.

Приветствую всех. Keenetic Ultra (KN-1810 версия ОС 3.8.5) работает в Mesh WiFi системе с Keenetic Viva (KN-1910 версия ОС 3.8.5). К Ultra к порту USB 3.0 подключен внешний HDD, к порту USB 2.0 флэшка с Entware. В такой конфигурации работает больше года. Ранее на ПК в Windws 10 было включено сохранение истории файлов на HDD, подключенный к роутеру, и работало. Недавно ОС была обновлена до Windows 11, и сегодня решил включить сохранение истории файлов на тот же диск, только в другой каталог. После примерно 30 минут копирования роутер стал очень сильно тормозить в web интерфейсе, ответа на любое действие приходилось ждать по 15-30 секунд. В логах успел увидеть сообщения: после этого роутер практически перестал отзываться. Веб интерфейс был пустой и не отвечал по 5 минут: Доступа в Интернет не было ни на одном устройстве, подключенном к роутеру. В браузере была ошибка конфигурации DNS: Отключение запущенного сохранения файлов в Windows в этой ситуации результата не давало. Кое-как удалось подключиться в CLI и набрать system reboot, роутер после этой команды перезагрузился через 20 минут. После перезагрузки всё стало нормально. Решил проверить случайность это была или нет. Опять включил сохранение истории файлов, и примерно через полчаса получил такую же картину. Минут за 5-10 до ухода роутера в полную "несознанку" скачал self-test, в этот момент роутер ещё отзывался в веб интерфейсе по 5-10 секунд. Всё повторилось, только войти в CLI уже не получалось, т.к. роутер отвечал access denied, хотя в веб интерфейсе на тот момент уже не был залогинен и войти в него тоже не было возможности, т.к. он открывался минут 5-10 и потом ни на что не реагировал. Два раза подряд, это уже не случайность, подумал я, и в третий раз "закинул невод". Перезагрузил роутер выключением питания, перезагрузил компьютер, и включил сохранение истории файлов. Всё повторилось и в этот раз, только я уже не стал ждать, пока роутер перестанет совсем отзываться, и отключил сохранение истории файлов когда он ещё отзывался по 5-10 секунд на команды и был доступ в Интернет, и после остановки сохранения истории файлов роутер ожил. Т.е. по симптомам - острая нехватка ресурсов. Компьютер подключен к роутеру по кабелю, и имеет гигабитный линк. Объём данных при первом сохранении истории файлов порядка 20-25 ГБ. На роутере также подняты Wireguard (на момент проблемы активных соединений не было), DLNA сервер (на момент проблемы активных потребителей контента не было), AdGuard Home, Transmission (на момент проблемы активных закачек/раздач не было), Entwate. К роутеру постоянно подключены по wifi порядка 12-15 устройств. В Windows 10 такой проблемы за всё время ни разу не было. Объём сохраняемых данных относительно небольшой, чтобы вызвать такой ступор роутера. Р.S.: Понаблюдал ещё, похоже на утечку памяти в роутере. После запуска сохранения истории файлов, использование памяти в роутере начинает постепенно расти по 1%, при этом загрузка процессора плавает в пределах 5-18%, изредка подскакивая до 60-80%. Когда использование памяти доходит до 86-88% начинается описанная выше ситуация, и загрузка процессора становится 95%. Копирование одного большого файла с этого же компьютера проходит без повышения процента использования памяти (оно находится постоянно около 50%). Т.е. проблема есть только при длительном копировании большого числа мелких файлов.

В файле smarthtml.conf открытым текстом написаны примеры использования. Для 12 часов это: 10 0,12 * * *

На первой странице пошаговая инструкция, перечитайте. Если вкратце, то: установить нужные пакеты (они все перечислены на первой странице и приведены команды для их установки), распаковать архив smarthtml_0.8.2.tar.gz (в нем два файла), положить файлы в указанные в инструкции на первой странице места, запустить файл smarthtml.sh (перед этим сделав его исполняемым, об этом тоже в инструкции написано).

Видимо из-за ошибки в файле smarthtml.sh Содержимое этого файла посмотрите, особенно первую строку.

Попробуйте сначала обновить микропрограмму диску, на сайте сигейта по вашему серийнику предлагает обновить, наверное не зря. Я нашёл в инете smart с такого же диска, там тоже нет поддержки SCT table command.

Похоже вот в чём дело. Не поддерживается, хотя и странно.

smartctl -iAHl scttemp /dev/sda

smartctl -a -d sat -l scttemp /dev/sda

smartctl -a -d sat /dev/sda что показывает?

Данные есть. После smarthtml makerrdgraph данные на графике не появились?

Посмотрите на вывод команды: rrdtool info /opt/var/smarthtml/rrd/sda.rra Там будет информация о данных в rrd и видны какие атрибуты сохраняются.

А почему вы решили, что не показывает графики? Если только установили, то каких графиков ждёте сразу? Для них пока данных нет. Можете пооткрывать файлы png и сравнить с тем, что показывает через web интерфейс, думаю будет одинаково. Можете попробовать запустить команду: smarthtml makerrdgraph Она создаст график, если в базе rrd есть какие либо данные для этого. А так, не ранее чем через 3 часа начнут появляться. Про крон: по каким признакам выяснили что он не работает? Убедитесь что он запущен: ~ # ps | grep cron 732 root 4436 S cron -s

Отлично.

Да. В файле /opt/etc/lighttpd/lighttpd.conf строка "server.port = 81" раскоментирована?

А через web сервер смотреть никак?

А в конфиге USE_CGI_MODULE включено?

А что показывает: smartctl -a /dev/sda

Ага, а если оно включено на девайсе за полсотни, или больше, километров, и он, обновившись, пропал с радаров, Кинетик со своей нацеленностью просто руками разведет 🤷‍♂️ Не всем подходит автообновление. И кому не подходит, те сами руками в состоянии проверить наличие новых версий, если в этом возникнет необходимость. Вот сейчас прилетело обновление, скорее всего в нём закрыли этот баг с перезагрузкой, но удалённые девайсы что-то страшно обновлять, т.к. говорят, есть поверье, что обновления удалённых устройств это к дальней дороге...