Периодическое зависание GIGA II 2.16.D.12.0-1 (отваливается выход в интернет и недоступен веб-интерфейс)

[Le ecureuil]

3 часа назад, drugold сказал:

А может быть аппаратная проблема (что-то начало помирать)?

Ничего неясно.

Вообще я бы еще поискал кто генерирует клонированные skb, вероятно это у них skb_shared_info в конце вредит. Как будет время добавлю трейс именно в места создания клонов, по идее их быть не должно в текущем конфиге.

[Тарас]

Добрий вечір.
Проблема не апаратна. Та ж версія прошивки, проте інший девайс.
Теж Wireguard, теж відвалюється інет та веб-морда; при переході назад на l2tp/ipsec - все ок (але швидкість вдвічі менша).

(все приховано за <hidden>).self-test0.txt

Изменено 17 сентября, 2021 пользователем Тарас
file

[diqipib]

@Тарас, печальная и радостная новость одновременно. Печально, что проблема не только у меня, но рад, что теперь я не одинок + есть больше уверенности, что проблема не аппаратная и вроде бы становится яснее где её искать.

@Le ecureuil, очень странно, но видимо, есть какие-то "траблы" с Wireguard. Заметил, что когда цепляю свой роутер через WISP на соседский wifi, то у меня зависаний нет. При этом у соседей такая же схема подключения - Wireguard поверх 4G соединения (сам им настраивал). И там такой же модем как у меня e3372h с такой же прошивкой и идентичными настройками. Разница только в том, что у меня GIGA II, а там GIGA III. И там всё работает стабильно и у меня через них (через WISP) работает стабильно. Чудеса....🤨

Изменено 18 сентября, 2021 пользователем diqipib

[Тарас]

@diqipib, інет по кабелю, без модема.
Доповню - в мене ще через VPN прокинуті порти для qBittorrent.

[diqipib]

В 17.09.2021 в 22:12, Le ecureuil сказал:

Как будет время добавлю трейс именно в места создания клонов, по идее их быть не должно в текущем конфиге.

 @Le ecureuil, насяйника, есть надежда на лечение бага ?

Я пока что смог только добиться, чтобы нехватка памяти не приводила к полному зависанию. Обновился на последнюю прошивку, удалил все компоненты, которые только можно. Оставил только Wireguard и всё что нужно для 4G модема. В Wireguard подключении отключил "Подстройка TCP MSS" и выставил "MTU 640" (чисто проверить, а что будет если его уменьшить в 2 раза от значения, которое указано в конфиге).

При этом, видимо, переполнение памяти происходит, так как ошибки в логе по прежнему появляются, но веб-морда роутера не отваливается, а интернет иногда пропадает на пару секунд.

Но всё-таки хочется верить, что это можно поправить. 😵  Оченьа на даче интернета ма хочеся. 😏

[Тарас]

UPD: однозначно проблема з торрентами. Upload/Download та прокинуті через впн порти не мають значення - у всіх випадках роутер падає.
Під час проблеми роутер не може ініціювати нові з'єднання, але в деяких існуючих з'єднаннях торрент-клієнт продовжує завантажувати.

[Le ecureuil]

@diqipib попробуйте > no ppe пока.

[diqipib]

7 часов назад, Le ecureuil сказал:

@diqipib попробуйте > no ppe пока.

@Le ecureuil, попробовал. Пока не помогло. Если торренты не качать, то ошибка долго не появляется, но стоит запустить qBittorrent и сразу завал. 😔

[diqipib]

В 17.09.2021 в 22:12, Le ecureuil сказал:

Ничего неясно.

Вообще я бы еще поискал кто генерирует клонированные skb, вероятно это у них skb_shared_info в конце вредит. Как будет время добавлю трейс именно в места создания клонов, по идее их быть не должно в текущем конфиге.

@Le ecureuil, и снова здравствуйте ! 😉 Что-нибудь ещё проверить можем ? По добавлению трейсов - пока нет возможности добавить ?

[diqipib]

@Тарас, приветствую. Видимо @Le ecureuil пока не успел добраться до нашей проблемы. Хотел узнать - в вашем случае помогает смена MTU в Wireguard на 640 ?

Скрытый текст

Я заметил, что у меня при этом отвалы становятся гораздо реже. Интересно сработает ли это в вашем случае. По поводу подстройки TCP MSS я пока не понял - влияет ли она как-то или нет. Попробуйте проверить в разных состояниях.

[diqipib]

@Тарас, дополню. С отключенным TCP MSS работает лучше.

[Тарас]

@diqipib, Так, проблема в MTU.
На сервері було 8920. Виставив 1440 - все супер.

/etc/wireguard/wg0.conf:

[Interface]

MTU = 1440

 

*для ipv6 - 1420 (default), для ipv6+pppoe - 1412.

[diqipib]

@Тарас, супер ! Получается всё-таки временное решение найдено. Я тоже пробовал c разными значениями. Какой MTU при этом на сервере, к сожалению, не знаю, так как сервер не мой, а Cloudflare. Возможно есть способ это узнать удалённо ? Найти в документалке на их сайте тоже не смог. В конфиге, который создаётся утилитой wgcf указано 1280:

Скрытый текст

[Interface]
PrivateKey = ***********
Address = 172.16.0.2/32
Address = fd01:5ca1:ab1e:8ba5:5636:dffb:2312:c944/128
DNS = 1.1.1.1
MTU = 1280
[Peer]
PublicKey = bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=
AllowedIPs = 0.0.0.0/0
AllowedIPs = ::/0
Endpoint = engage.cloudflareclient.com:2408

С 1280 у меня как раз заваливается. 

Если верно понял, то у вас WG поверх PPPOE ? У меня получается WG поверх модемного соединения. Интересно как рассчитать MTU в таком случае ?

Погуглил по Wireguard MTU

https://keremerkan.net/posts/wireguard-mtu-fixes/

https://discourse.linuxserver.io/t/wireguard-pppoe-mtu-issue/1687/3

https://www.linux.org.ru/forum/admin/14757400

Везде Вижу разные значения для разных подключений - 1400, 1480, 1420, 1412. Проверил несколько - через какое-то время роутер виснет. Остановился на своих 640 (найденные экспериментально), при которых вроде бы достаточно стабильно работает... Но всё же надеюсь гуру @Le ecureuil прокомментирует как должно быть правильно. И нужно ли включить TCP MSS. И вообще тогда баг ли это (имею в виду завал по памяти) ? 🙄

Изменено 27 сентября, 2021 пользователем diqipib

[Le ecureuil]

На самом деле любой, который работает, является правильным. Минимальный определен в 576 для IPv4 и 1280 для IPv6.

[diqipib]

@Le ecureuil, ура ! ) Гуру добрался до нашей темы ! 🙂 Пока вопросов больше чем ответов:

1) А как-то 100% верно MTU вычислить можно ? Хочется понять как должно быть на самом деле, а не выставлять значение наобум. У меня, например, при разных значениях MTU часть сайтов перестаёт открываться в Google Chrome, но при этом Firefox их открывает нормально.

2) TCP MSS надо включать ? Он же по идее MTU подстраивает по ситуации ? У меня при его включении начинаются сбои по памяти даже при значение MTU 640

3) Баг с переполнением памяти из-за этого или в чём-то ещё причина ? И баг ли это ?

4) Заметил, что у меня зачастили сообщения типа Network::Interface::WebCaller::Huawei: "CdcEthernet0": session is expired, reinit. Так и должно быть или это сбой ? Или с этим новую тему стоит завести ?

Скрытый текст

Сен 27 17:04:07

 

ndm

Network::Interface::WebCaller::Huawei: "CdcEthernet0": session is expired, reinit.

Сен 27 17:04:17

 

ndm

Network::Interface::WebCaller::Huawei: "CdcEthernet0": connection established.

Сен 27 17:05:51

 

ndm

Netfilter::Util::Conntrack: flushed 2 IPv4 connections for 192.168.4.83.

Сен 27 17:08:09

 

ndm

Network::Interface::WebCaller::Huawei: "CdcEthernet0": session is expired, reinit.

Сен 27 17:08:20

 

ndm

Network::Interface::WebCaller::Huawei: "CdcEthernet0": connection established.

Сен 27 17:12:11

 

ndm

Network::Interface::WebCaller::Huawei: "CdcEthernet0": session is expired, reinit.

Сен 27 17:12:23

 

ndm

Network::Interface::WebCaller::Huawei: "CdcEthernet0": connection established.

Сен 27 17:13:21

 

ndm

Netfilter::Util::Conntrack: flushed 4 IPv4 connections for 192.168.4.83.

Сен 27 17:15:22

 

ndm

Network::Interface::WebCaller::Huawei: "CdcEthernet0": connection dropped.

5) Инет на модеме иногда отваливается, но вроде гораздо реже. И ошибки с переполнением памяти вроде ушли. Второй день их пока не вижу.

[Тарас]

@diqipib, для визначення mtu вашого підключення потрібно з роутера пропінгувати будь-який сервіс (що пінгується) вказавши розмір пакету. Зазвичай це 1500. Пінгується - віднімаємо 60 для ipv4 або 80 для ipv6 і отримуємо необхідне. Не пінгується - понижати доки не почне.

Spoiler

Очевидно, маршрут повинен бути напряму через провайдера, а не через VPN.

 

UPD: TCP adjust mss залишив дефолтним - вкл.

Изменено 27 сентября, 2021 пользователем Тарас

[diqipib]

@Тарас, последовал вашей рекомендации. Выставил в Wireguard MTU 1500 и включил TCP MSS. В проверке сетевого соединения, при размере пакета 1500 - пинга нет. При значениях 1440, 1380 и т.п. ping есть, но всё время c пометкой truncated. Т.е урезается ? Так должно быть ?

Скрытый текст

sending ICMP ECHO request to google.com...

PING google.com (216.58.209.174) 1472 (1500) bytes of data.

 

--- google.com ping statistics ---

5 packets transmitted, 0 packets received, 100% packet loss,

0 duplicate(s), time 5003.10 ms.

sending ICMP ECHO request to google.com...
PING google.com (216.58.209.174) 1412 (1440) bytes of data.
96 bytes from google.com (216.58.209.174): icmp_req=1, ttl=60, time=51.72 ms. (truncated).
96 bytes from google.com (216.58.209.174): icmp_req=2, ttl=60, time=48.82 ms. (truncated).
96 bytes from google.com (216.58.209.174): icmp_req=3, ttl=60, time=54.74 ms. (truncated).
96 bytes from google.com (216.58.209.174): icmp_req=4, ttl=60, time=57.87 ms. (truncated).
96 bytes from google.com (216.58.209.174): icmp_req=5, ttl=60, time=53.07 ms. (truncated).
--- google.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss,
0 duplicate(s), time 4055.30 ms.
Round-trip min/avg/max = 48.82/53.24/57.87 ms.

sending ICMP ECHO request to google.com...
PING google.com (216.58.209.174) 1352 (1380) bytes of data.
96 bytes from google.com (216.58.209.174): icmp_req=1, ttl=60, time=55.42 ms. (truncated).
96 bytes from google.com (216.58.209.174): icmp_req=2, ttl=60, time=57.88 ms. (truncated).
96 bytes from google.com (216.58.209.174): icmp_req=3, ttl=60, time=75.28 ms. (truncated).
96 bytes from google.com (216.58.209.174): icmp_req=4, ttl=60, time=57.94 ms. (truncated).
96 bytes from google.com (216.58.209.174): icmp_req=5, ttl=60, time=58.69 ms. (truncated).
--- google.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss,
0 duplicate(s), time 4061.91 ms.
Round-trip min/avg/max = 55.42/61.04/75.28 ms.

 

Изменено 27 сентября, 2021 пользователем diqipib

[Тарас]

@diqipib

Quote

Очевидно, маршрут повинен бути напряму через провайдера, а не через VPN.

Якщо простіше - спочатку треба виключити VPN.

Але проблема не вирішена повністю. Сьогодні знову помітив... Але цей раз вже без торентів.
log.txt

[krass]

25 минут назад, Тарас сказал:

@diqipib

Якщо простіше - спочатку треба виключити VPN.

Але проблема не вирішена повністю. Сьогодні знову помітив... Але цей раз вже без торентів

Скройте логи согласно посту: https://forum.keenetic.ru/announcement/4-как-правильно-добавить-self-test-и-прочую-отладку-в-тему/   

 

self-test и логи могут содержать непубличную информацию, потому их не стоит прикреплять к постам бездумно. Однако, слать селф-тесты в личку абсолютно неправильно, поскольку это усложняет координацию между разработчиками и отрывает диагностику от темы с проблемой.

Изменено 30 сентября, 2021 пользователем krass

[Le ecureuil]

Проверяйте на 2.16.D.12.0-6.

[Fantazer]

Здравствуйте!

Являюсь малоопытным юзером и многое из терминологии, которую использовали в постах выше, пока не понимаю.

В августе 2019 года стал "счастливым" обладателем Keenetic Giga, который в общем и целом до 25 февраля 2023 года работал без особых проблем. Прошивки обновлял регулярно. Сейчас установлена 3.9.3

Но с 25 февраля столкнулся с той же проблемой, что и автор темы: периодически роутер стал зависать и пропадает доступ к web-интерфейсу. На некоторое время помогает переподключение к розетке ))

Подключение к Интернету через езернет и оптоволокно. Раздача по проводам и вай-фай. Роутер дополнительными сервисами не нагружен. Куда копать? Версия роутера KN-1010, файлы селф-теста и т.п. могу скинуть по необходимости.

Изменено 27 февраля, 2023 пользователем Fantazer

[project_fcc]

1 час назад, Fantazer сказал:

Куда копать? Версия роутера KN-1010,

В этой теме про старую версию роутера Giga II и совсем другую версию прошивки.

Пишите в официальную поддержку, например на почту help@keenetic.ru

Можете попробовать поставить версию 3.9.4 из ''предварительного канала'', там были исправления связанные с зависанием роутера.

В разделе общение настройки меняете канал обновлений на ''предварительный'' и обновляете онлайн.

Изменено 27 февраля, 2023 пользователем project_fcc

[Sano]

Тоже начались проблемы с KeenetikII. Отваливается интернет и нет доступ в морде, дальше чем запрос логин/пароль. 

Роутер старенький. Особых чудес не жду, но вдруг )))

Спойлер

I [Jan 27 11:20:52] ndhcpc: FastEthernet0/Vlan2: received ACK for 192.168.5.2
                    from 192.168.15.1 lease 25200 sec.
I [Jan 27 11:20:53] ndhcpc: WifiMaster0/WifiStation0: received ACK for
                    192.168.0.114 from 192.168.0.1 lease 7200 sec.
I [Jan 27 11:24:14] kernel: wireguard: Wireguard2: handshake for peer
                    "SesP9nrsmVJ0bA8DqWBRgOi6oaXad7ZwLmNz/iZ4Px0=" (13)
                    (188.233.42.49:1280) did not complete after 5 seconds,
                    retrying (try 2)
I [Jan 27 11:24:19] kernel: wireguard: Wireguard2: handshake for peer
                    "SesP9nrsmVJ0bA8DqWBRgOi6oaXad7ZwLmNz/iZ4Px0=" (13)
                    (188.233.42.49:1280) did not complete after 5 seconds,
                    retrying (try 3)
C [Jan 27 11:47:41] kernel: CPU 1 Unable to handle kernel paging request at
                    virtual address 43ee5b09, epc == 8026d90c, ra == 80271198
W [Jan 27 11:47:41] kernel: Oops[#1]:
W [Jan 27 11:47:41] kernel: Cpu 1
W [Jan 27 11:47:42] kernel: $ 0   : 00000000 11000301 fffffffe 00000001
W [Jan 27 11:47:42] kernel: $ 4   : 43ee5b00 8581d7a0 43ee5b00 00000001
W [Jan 27 11:47:42] kernel: $ 8   : fffffffe 00000020 83dcecb4 00000000
W [Jan 27 11:47:42] kernel: $12   : 00000000 00000000 00000000 00000000
W [Jan 27 11:47:42] kernel: $16   : 83dcec80 83d25710 00000000 00000001
W [Jan 27 11:47:42] kernel: $20   : 8581d7a0 00000001 00000000 82a17140
W [Jan 27 11:47:42] kernel: $24   : 00000000 8581c9dc
W [Jan 27 11:47:42] kernel: $28   : 85b98000 85b99b28 00000001 80271198
W [Jan 27 11:47:42] kernel: Hi    : 000002aa
W [Jan 27 11:47:42] kernel: Lo    : 000514c5
W [Jan 27 11:47:42] kernel: epc   : 8026d90c leaf_walk_rcu+0x10/0xac
W [Jan 27 11:47:42] kernel:     Tainted: P           O
W [Jan 27 11:47:42] kernel: ra    : 80271198 fib_table_dump+0x1ac/0x30c
W [Jan 27 11:47:42] kernel: Status: 11000303    KERNEL EXL IE
W [Jan 27 11:47:42] kernel: Cause : 80802008
W [Jan 27 11:47:42] kernel: BadVA : 43ee5b09
W [Jan 27 11:47:42] kernel: PrId  : 00019555 (MIPS 34Kc)
W [Jan 27 11:47:42] kernel: Modules linked in: esp4_hw(O) crypto_k(PO)
                    fastvpn(PO) hw_nat(O) nf_nat_sip nf_conntrack_sip
                    nf_nat_ftp nf_conntrack_ftp zram rt539x_ap2(O) ntc(PO)
                    rtsoc_eth(PO) rndis_host snd_pcm_oss snd_usb_audio
                    cdc_ether snd_pcm asix option usb_wwan usbextras(PO)
                    authenc snd_usbmidi_lib exfat(O) nls_utf8 snd_seq_midi
                    evdev snd_hwdep nf_nat_rtsp(O) nls_cp1251 usbhid
                    snd_mixer_oss ax88179_178a usb_storage cdc_acm l2tp_ppp
                    usblp hid dm9601 snd_rawmidi sd_mod ohci_hcd sr_mod
                    nls_cp437 sierra sg snd_seq_midi_event usbnet ext4 snd_seq
                    tfat(PO) deflate ipcomp snd_seq_device nls_cp866 snd_timer
                    tntfs(PO) jffs2 snd r8152 ehci_hcd rtl8150 usbserial
                    nf_nat_pptp nf_nat_h323 usbcore nf_conntrack_pptp cdrom
                    resetnds(PO) hmac des_generic mtdoops_proc(O)
                    xfrm4_mode_beet nacct(PO) sha256_generic input_core
                    xfrm_ipcomp rt_timer_wdg nf_conntrack_h323 zlib_deflate
                    jbd2 nls_base eoip(O) aes_generic xfrm_user
                    nf_conntrack_proto_gre phr(PO) mbcache nf_conntrack_rtsp(O)
                    af_key exportfs ip_gre crc_itu_t zlib_infl [...]
W [Jan 27 11:47:42] kernel: Process ndm (pid: 4573, threadinfo=85b98000,
                    task=83fda098, tls=75505960)
W [Jan 27 11:47:42] kernel: Stack : 85b50600 85b50600 85b99dcc 801ca464
                    000000fe 00000001 f6dc45b0 00000000
W [Jan 27 11:47:42] kernel:         00000000 849b2a00 00000002 8006e21c
                    83d25710 00000008 f6dc45b0 00000000
W [Jan 27 11:47:42] kernel:         83d25710 00000000 859ff400 00000000
                    83dcec80 000000fe 82a17140 000000fe
W [Jan 27 11:47:42] kernel:         00000000 8038e9c0 00000000 802698b8
                    859ff400 85b50600 85b50600 8030ff68
W [Jan 27 11:47:42] kernel:         83dcecac 8581c980 83dcec80 85b50600
                    82a17140 87c35400 8581c980 0000005c
W [Jan 27 11:47:42] kernel:         ...
W [Jan 27 11:47:42] kernel: Call Trace:
W [Jan 27 11:47:42] kernel: [<8026d90c>] leaf_walk_rcu+0x10/0xac
W [Jan 27 11:47:42] kernel: [<80271198>] fib_table_dump+0x1ac/0x30c
W [Jan 27 11:47:42] kernel: [<802698b8>] inet_dump_fib+0x158/0x274
W [Jan 27 11:47:42] kernel: [<801f9340>] netlink_dump+0x68/0x234
W [Jan 27 11:47:42] kernel: [<801f9f00>] __netlink_dump_start+0x13c/0x19c
W [Jan 27 11:47:42] kernel: [<801e1550>] rtnetlink_rcv_msg+0x320/0x374
W [Jan 27 11:47:42] kernel: [<801fc10c>] netlink_rcv_skb+0x74/0x128
W [Jan 27 11:47:42] kernel: [<801e1220>] rtnetlink_rcv+0x2c/0x3c
W [Jan 27 11:47:42] kernel: [<801fb8dc>] netlink_unicast+0x1d4/0x2ac
W [Jan 27 11:47:42] kernel: [<801fbe9c>] netlink_sendmsg+0x354/0x3c4
W [Jan 27 11:47:42] kernel: [<801bd274>] sock_sendmsg+0x7c/0x94
W [Jan 27 11:47:42] kernel: [<801bfbe0>] sys_sendto+0xbc/0x128
W [Jan 27 11:47:42] kernel: [<801bfc64>] sys_send+0x18/0x24
W [Jan 27 11:47:42] kernel: [<80029b1c>] stack_done+0x20/0x44
 [Jan 27 11:47:42] kernel:
 [Jan 27 11:47:42] kernel:
W [Jan 27 11:47:42] kernel: Code: 24070001  24090020  2408fffe <10a00023>
                    90c40009  90c30008  8ca20004  2c650020  10a0001b
W [Jan 27 11:47:42] kernel: ---[ end trace c37c444e35d9994c ]---
E [Jan 27 11:47:45] coalagent: [SecLayer_OnSend] Coala_Send: Network is
                    unreachable.
W [Jan 27 11:48:10] ndm: Timer: unable to alarm
                    "Network::Interface::LinkDetector" for 30 seconds.
W [Jan 27 11:48:16] ndm: Event::Sender: unable to send "Event::Type::DbKey" to
                    "Network::DiscoveryManager" for 30 seconds.
E [Jan 27 11:48:37] ndm: Cloud::Agent: can not connect to the cloud server.
W [Jan 27 11:48:40] ndm: Timer: unable to alarm
                    "Network::Interface::LinkDetector" for 60 seconds.
W [Jan 27 11:48:42] ndm: Core::Watchdog: Ping-check profile queue holds
                    ROUTING_TABLE (68) lock 61 seconds acquired Jan 27
                    11:47:41.
W [Jan 27 11:48:42] ndm: Core::Watchdog: Statistics collector thread holds CORE
                    (2) lock 60 seconds acquired Jan 27 11:47:42.
W [Jan 27 11:48:46] ndm: Event::Sender: unable to send "Event::Type::DbKey" to
                    "Network::DiscoveryManager" for 60 seconds.
W [Jan 27 11:49:10] ndm: Timer: unable to alarm
                    "Network::Interface::LinkDetector" for 90 seconds.
W [Jan 27 11:49:16] ndm: Event::Sender: unable to send "Event::Type::DbKey" to
                    "Network::DiscoveryManager" for 90 seconds.
W [Jan 27 11:49:40] ndm: Timer: unable to alarm
                    "Network::Interface::LinkDetector" for 120 seconds.
W [Jan 27 11:49:42] ndm: Core::Watchdog: Ping-check profile queue holds
                    ROUTING_TABLE (68) lock 121 seconds acquired Jan 27
                    11:47:41.
W [Jan 27 11:49:42] ndm: Core::Watchdog: Statistics collector thread holds CORE
                    (2) lock 120 seconds acquired Jan 27 11:47:42.
W [Jan 27 11:49:46] ndm: Event::Sender: unable to send "Event::Type::DbKey" to
                    "Network::DiscoveryManager" for 120 seconds.
W [Jan 27 11:50:10] ndm: Timer: unable to alarm
                    "Network::Interface::LinkDetector" for 150 seconds.
W [Jan 27 11:50:16] ndm: Event::Sender: unable to send "Event::Type::DbKey" to
                    "Network::DiscoveryManager" for 150 seconds.
W [Jan 27 11:50:40] ndm: Timer: unable to alarm
                    "Network::Interface::LinkDetector" for 180 seconds.
W [Jan 27 11:50:42] ndm: Core::Watchdog: Ping-check profile queue holds
                    ROUTING_TABLE (68) lock 181 seconds acquired Jan 27
                    11:47:41.
W [Jan 27 11:50:42] ndm: Core::Watchdog: Statistics collector thread holds CORE
                    (2) lock 180 seconds acquired Jan 27 11:47:42.
W [Jan 27 11:50:46] ndm: Event::Sender: unable to send "Event::Type::DbKey" to
                    "Network::DiscoveryManager" for 180 seconds.
W [Jan 27 11:51:10] ndm: Timer: unable to alarm
                    "Network::Interface::LinkDetector" for 210 seconds.
W [Jan 27 11:51:16] ndm: Event::Sender: unable to send "Event::Type::DbKey" to
                    "Network::DiscoveryManager" for 210 seconds.
W [Jan 27 11:51:40] ndm: Timer: unable to alarm
                    "Network::Interface::LinkDetector" for 240 seconds.
W [Jan 27 11:51:42] ndm: Core::Watchdog: Ping-check profile queue holds
                    ROUTING_TABLE (68) lock 241 seconds acquired Jan 27
                    11:47:41.
W [Jan 27 11:51:42] ndm: Core::Watchdog: Statistics collector thread holds CORE
                    (2) lock 240 seconds acquired Jan 27 11:47:42.
W [Jan 27 11:51:46] ndm: Event::Sender: unable to send "Event::Type::DbKey" to
                    "Network::DiscoveryManager" for 240 seconds.
W [Jan 27 11:52:10] ndm: Timer: unable to alarm
                    "Network::Interface::LinkDetector" for 270 seconds.
W [Jan 27 11:52:16] ndm: Event::Sender: unable to send "Event::Type::DbKey" to
                    "Network::DiscoveryManager" for 270 seconds.
W [Jan 27 11:52:40] ndm: Timer: unable to alarm
                    "Network::Interface::LinkDetector" for 300 seconds.
W [Jan 27 11:52:42] ndm: Core::Watchdog: Ping-check profile queue holds
                    ROUTING_TABLE (68) lock 301 seconds acquired Jan 27
                    11:47:41.
W [Jan 27 11:52:42] ndm: Core::Watchdog: Statistics collector thread holds CORE
                    (2) lock 300 seconds acquired Jan 27 11:47:42.
W [Jan 27 11:52:46] ndm: Event::Sender: unable to send "Event::Type::DbKey" to
                    "Network::DiscoveryManager" for 300 seconds.
W [Jan 27 11:53:10] ndm: Timer: unable to alarm
                    "Network::Interface::LinkDetector" for 330 seconds.
W [Jan 27 11:53:16] ndm: Event::Sender: unable to send "Event::Type::DbKey" to
                    "Network::DiscoveryManager" for 330 seconds.
W [Jan 27 11:53:40] ndm: Timer: unable to alarm
                    "Network::Interface::LinkDetector" for 360 seconds.
W [Jan 27 11:53:42] ndm: Core::Watchdog: Ping-check profile queue holds
                    ROUTING_TABLE (68) lock 361 seconds acquired Jan 27
                    11:47:41.
W [Jan 27 11:53:42] ndm: Core::Watchdog: Statistics collector thread holds CORE
                    (2) lock 360 seconds acquired Jan 27 11:47:42.
W [Jan 27 11:53:46] ndm: Event::Sender: unable to send "Event::Type::DbKey" to
                    "Network::DiscoveryManager" for 360 seconds.
W [Jan 27 11:54:10] ndm: Timer: unable to alarm
                    "Network::Interface::LinkDetector" for 390 seconds.
W [Jan 27 11:54:16] ndm: Event::Sender: unable to send "Event::Type::DbKey" to
                    "Network::DiscoveryManager" for 390 seconds.
W [Jan 27 11:54:40] ndm: Timer: unable to alarm
                    "Network::Interface::LinkDetector" for 420 seconds.

LogBad.txt

Изменено 27 января пользователем Sano

[Le ecureuil]

Выглядит как то, что ОЗУ стала портиться из-за старости.

Впрочем может быть и программной проблемой, попробуйте Wireguard отключить для проверки без него.