hellonow

@Dhampir113 в логе есть ошибки при выдаче IP по DHCP: [E] Dec 2 23:11:31 ndhcps: another client with that IP address 192.168.1.33. Это связано с хостом, чей МАС начинается на 30:83:9 Нужно проверить, нет ли еще одного DHCP-сервера в сети, либо адрес уже зарегистрирован за другим хостом в сети роутера. Но судя по конфигурацию, да, данный адрес уже зарегистрирован за ip dhcp host e0:70 192.168.1.33 По поводу зависаний. В этом self-test файле не понятны причины, нужно отключить OpenVPN, IPSec туннели, очень спамят в лог. self-test файл уже надо пытаться снять в момент зависания, пробовать получить доступ по telnet.

@t800 нет, по Preview (Beta) версиям вы можете писать в поддержку. 3.9 находится в активной стадии бета теста, поэтому ЖЕЛАТЕЛЬНО писать именно в поддержку.

@Alister Роутеры не управляют питанием накопителей, не инициализируют переход накопителя в режим ожидания \ сна, это прерогатива контроллера, микропрограммы жесткого диска. Касается всех версий KeeneticOS. Далее сразу приведу примеры управления режимом перехода в сон, режима ожидания. Для управления диском можно использовать приложение Dashboard от производителя диска Seagate. В нем присутствует возможность установки таймаута, как и множество других полезных функций. По данной аналогии можно проверить наличие фирменных утилит управления диском и у других вендоров. Также можно поискать утилиты от производителей, которое позволяют скорректировать тайминг перехода в режим сна - standby. Например, если у вас накопитель фирмы WD, то посмотрите в сторону следующих утилит - например WD Drive Utilities (например здесь https://support.wdc.com/downloads.aspx?DL), wdidle3 или WD Red tool. 26 страница с информаций: *Managing and customizing the drive> Setting the drive Sleep Timer https://products.wdc.com/library/UM/ENG/4779-705157.pdf В целом лучше избегать частых циклов запуска-остановки шпинделя HDD, данное действие может прямо влиять на общую выработку накопителя, прежде всего на ограниченное значение парковок головки https://qna.habr.com/q/13287 Также можно посмотреть в сторону Linux утилиты - hdparm из OPKG Entware - OPKG, которая позволяет смотреть и изменять аппаратные параметры HDD: Настройка накопителя на жестких магнитных дисках (НЖМД) может включать несколько параметров, управляющих режимом энергопотребления, в том числе и в зависимости от периода простоя (отсутствия обращений) к нему. В основном, современные модели дисков способны автономно определять простой и отключаться (останавливать вращение шпинделя и/или парковать систему головок для работы с данными). Рассмотрим на примере диска фирмы Seagate, в заводской конфигурации которого отключена функция такого энергосбережения, ее включение. В командной строке компьютера под управлением Linux выполним команду: <code>[alexander@silverado ~]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 931,5G 0 disk └─sdb1 8:17 0 931,5G 0 part /media/storage sr0 11:0 1 1024M 0 rom sdc 8:32 0 1,8T 0 disk └─sdc1 8:33 0 1,8T 0 part /run/media/alexander/Seagate Expansion Drive sda 8:0 0 149,1G 0 disk ├─sda2 8:2 0 1K 0 part ├─sda5 8:5 0 4G 0 part [SWAP] ├─sda1 8:1 0 48,5G 0 part / └─sda6 8:6 0 96,6G 0 part /home</code> Как видно, наш диск - это устройство sdc. Используя приложение hdparm, укажем устройству переходить в режим ожидания через три минуты простоя. <code>[alexander@silverado ~]$ sudo hdparm -S 36 /dev/sdc [sudo] password for alexander: /dev/sdc: setting standby to 36 (3 minutes)</code> Настройка сохранится и после отключения питания. Отключим диск от компьютера и подключим к интернет-центру.

@keenet07 self-test пожалуйста, чтобы понимать вашу конфигурацию.

@t800 у вас возникает перезапуск DHCP на Br0 контроллера, поэтому да, это может вызывать сообщения в Приложении. Напишите пожалуйста в поддержку, описав данную ситуацию.

@keenet07 да, отдельную тему пожалуйста, чтобы все в кучу не мешать.

@aug похоже на то, что провайдер начинает блокировать запросы DNS DoH. Также это может возникать после renew, но это уже поправлено. Пробуйте перейти на DNS over TLS.

@andrey_sys лог пожалуйста так не выкладывайте в тему, либо сюда https://pastebin.com, а еще лучше делать так https://forum.keenetic.com/announcement/4-как-правильно-добавить-self-test-и-прочую-отладку-в-тему/

@Winterborn Нужен self-test файл, когда работает туннель на версии 3.8.5.4 и когда не работает на версии 3.9.0

В логе self-test файла не зафиксирована данная ошибка, только остановка, загрузка демона mtkiappd: [I] Nov 25 11:22:46 mtkiappd: stopped. [I] Nov 25 11:22:46 mtkiappd: stopped. [I] Nov 25 11:22:48 mtkiappd: MediaTek IAPP daemon v2.0.9 started on br0. [I] Nov 25 11:22:48 mtkiappd: MediaTek IAPP daemon v2.0.9 started on br1.

@Winterborn корневые сертификаты IdenTrust DST Root CA X3 проверяли? https://habr.com/ru/post/580092/

@GeodE

@elesdrago спасибо, пока не нужно. Ситуация воспроизводится на столе 👍

@4c4127db756b4affbf2a2b3186 да, все верно, на данный момент настройка доступна в CLI, пример: dns-proxy tls upstream 2620:fe::9 domain dns.quad9.net system configuration save В будущих версиях ПО стоит ожидатьнастройку DoT DoH в веб.

@saffe на данный момент имеются трудности в работе Time Machine (Tuxera) KeeneticOS и macOS Ventura 13.0.1 От файловой системы не зависит. Ожидается исправление в будущих версиях ПО.

@t800 у вас явно линк падал и не был доступен шлюз: [I] Nov 24 10:20:47 ndm: Network::Interface::Switch: "FastEthernet0/1": switch link up at port 1 (100FD/AN). [I] Nov 24 10:20:47 kernel: br0: port 1(eth2.1) entered blocking state [I] Nov 24 10:20:47 kernel: br0: port 1(eth2.1) entered listening state [I] Nov 24 10:20:47 kernel: br1: port 1(eth2.2) entered blocking state [I] Nov 24 10:20:47 kernel: br1: port 1(eth2.2) entered listening state [W] Nov 24 10:20:50 ndm: Dhcp::Client: DHCP server is not responding. [W] Nov 24 10:20:50 ndm: Dhcp::Client: DHCP server is not responding. [I] Nov 24 10:20:50 ndm: Network::Interface::Ip: "Bridge1": IP address cleared. [I] Nov 24 10:20:50 ndm: Network::InternetChecker: Internet access lost (status: 0x0000). [I] Nov 24 10:20:50 kernel: br1: port 1(eth2.2) entered learning state [I] Nov 24 10:20:50 kernel: br0: port 1(eth2.1) entered learning state Далее аналогичное событие: [I] Nov 24 10:20:56 ndm: Network::Interface::Switch: "FastEthernet0/1": switch link down at port 1. [I] Nov 24 10:20:56 kernel: br0: port 1(eth2.1) entered blocking state [I] Nov 24 10:20:56 kernel: br0: port 1(eth2.1) entered listening state [I] Nov 24 10:20:56 ndhcpc: Bridge1: received OFFER for 172.16.1.21 from 172.16.1.1. [I] Nov 24 10:20:56 kernel: br1: port 1(eth2.2) entered blocking state [I] Nov 24 10:20:56 kernel: br1: port 1(eth2.2) entered listening state [I] Nov 24 10:20:58 ndm: Network::Interface::Switch: "FastEthernet0/1": switch link up at port 1 (100FD/AN). Поэтому срабатывает STP, так как есть MWS. При изменении топологии, дерево STP перестраивается и свитч в Keenetic проходит стадии blocking - listening - learning - forwarding, в такие моменты передача через все локальные порты блокируется на несколько секунд, поэтому приложение отрабатывает корректно, не похоже на "фейковые" пуши.

@Vladimir Belov не надо дублировать сообщения. self-test файл нужно скрывать, не выкладывать в паблик.

@koctik-2017 актуально в 3.9 Beta 2? Если да, то нужно подробное описание воспроизведения ситуации и self-test файл.

@t800 можно не обращать внимания, это системное сообщение никак не влияет на работу системы. Это мобильное приложение запрашивает информацию по http \ rci.

@bonlui возможно не хватает памяти ОЗУ, нужно больше информации по настройке системы и нужен self-test файл. В версии 3.9 Beta 2 актуально? Проверьте на данной версии.

Продолжение темы: Исправление в следующей версии 3.9

@il0x Нет подключения с удаленной стороной, возможно сессия зависает: [I] Sep 6 21:53:55 pppd_L2TP0: CHAP authentication failed: Too many connections [E] Sep 6 21:53:55 pppd_L2TP0: CHAP authentication failed [I] Sep 6 21:53:55 pppd_L2TP0: sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"] [I] Sep 6 21:53:55 pppd_L2TP0: rcvd [LCP TermAck id=0x2] [I] Sep 6 21:53:55 pppd_L2TP0: Connection terminated. В целом лучше перейти на IPoE и причиной обрывов может быть то, о чем вы упомянули. Из-за большого количества соединений со стороны клиента-хоста, шлюз Билайна перестает отвечать, в логе вы увидите сообщения: Internet access lost (status: 0x0000) или Internet access lost (status: 0x0007) Но тут надо уже собирать дамп трафика и напрямую их отправлять в поддержку провайдера.

@iggo данная опция отвечает за ip http security-level, когда делаете public или public ssl в controlPanel/diagnostics/General, то настройка будет распространенаи на controlPanel/remoteAccess/KeenDNS.