NFQWS перезагружает Keenetic

[Anonym-tsk]

У пользователей NFQWS на Keenetic возникают периодические перезагрузки. Пока закономерности не выявлено. У кого-то чаще, у кого-то реже, у кого-то вообще не перезагружается. Актуально для всех моделей, от самых простых, до топовых типа Ultra, т.е. от железа не очень зависит. У меня была пока одна перезагрузка с аптаймом в 4 дня, больше не повторяется (жду).

В логе роутера после ребута kernel: SoC power status: hardware watchdog reset

Из того, что замечено - немного растет потребление памяти со временем процессов ndm (сам nfqws память не жрет), но перезагрузки кажется от этого не зависят.

Еще, пользователи сообщают, что перезагрузки чаще возникают при обращении к гугловым доменам. Кто-то ввел в гугле запрос, нажал на enter и роутер упал. Кто-то на телефоне нажал обновить приложение в Google Play. googleapis.com внесен в hostlist https://github.com/Anonym-tsk/nfqws-keenetic/blob/master/etc/nfqws/user.list

nohup /opt/usr/bin/nfqws --debug --user=nobody --qnum=200 --pidfile=/opt/var/run/nfqws.pid --dpi-desync=fake,disorder2 --dpi-desync-split-pos=1 --dpi-desync-ttl=6 --dpi-desync-fooling=md5sig --hostlist=user.list --hostlist-auto=auto.list --hostlist-auto-debug=nfqws.log --hostlist-exclude=exclude.list >> /opt/root/nfqws.out 2>&1 &

iptables -t mangle -A POSTROUTING -o eth3 -p tcp --dport 80 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:8 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 200 --queue-bypass
iptables -t mangle -A POSTROUTING -o eth3 -p tcp --dport 443 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:8 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 200 --queue-bypass
iptables -t mangle -A POSTROUTING -o eth3 -p udp --dport 443 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:8 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 200 --queue-bypass

iptables -t nat -A POSTROUTING -o eth3 -p udp -m mark --mark 0x40000000/0x40000000 -j MASQUERADE

ip6tables -t mangle -A POSTROUTING -o eth3 -p tcp --dport 80 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:8 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 200 --queue-bypass
ip6tables -t mangle -A POSTROUTING -o eth3 -p tcp --dport 443 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:8 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 200 --queue-bypass
ip6tables -t mangle -A POSTROUTING -o eth3 -p udp --dport 443 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:8 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 200 --queue-bypass

net.netfilter.nf_conntrack_checksum=0
net.netfilter.nf_conntrack_tcp_be_liberal=1

Ссылка на issue в проекте: https://github.com/Anonym-tsk/nfqws-keenetic/issues/18

В логе ничего особо полезного, прикрепляю nfqws.out.zip

Буду благодарен за помощь.

[bol-van]

Кинетик автор не поддерживает, а все прошивочки, кроме openwrt, ложатся на пользователя и/или комьюнити. Автор не будет покупать кинетик и разбираться в нем. Если nfqws не течет памятью, спрашивайте в дискуссиях У кинетика патченое ядро, проприетарный софт. И что там глючит - надо чтобы сообщество разбиралось

Со своей точки зрения могу предположить, что идет какая-то блокировка внутри ядра, из-за чего оно перестает выполняться нормально или выполнять user mode процессы, попросту говоря ядро виснет. Что приводит к невозможности обновления watchdog таймера и ресету системы по нему Возможно локапы связаны с кривостью патчинга ядра Linux. Наверняка разработчики не тестировали свои патчи с NFQUEUE

[Anonym-tsk]

В кинетике NFQUEUE используется, судя по iptables. Я не предлагаю вам починить проблему. Помогите хотя бы понять как выявить что идет не так, чем подебажить, какие логи собрать. Пока выглядит так, что при каких-то условиях nfqws зацикливается и уходит в 100% cpu. На скрине момент перезагрузки.

[Anonym-tsk]

Здесь была жалоба от 2022 года https://github.com/bol-van/zapret/issues/56

[bol-van]

Точно выяснено, что nfqws именно начинает потреблять cpu ? Если так, и в дебаг логе ничего, в упомянутом вами старом issue написано что делать nfqws с дебаг символами могу собрать какой там мипс lsb или msb ? но вопрос сможете ли вы что-то делать с системой, когда проблема уже случилась, nfqws зациклился ? не уходит ли она в неуправляемое состояние ?

[Anonym-tsk]

Точно выяснено, что nfqws именно начинает потреблять cpu ?

Не точно, собираю логи, жду перезагрузки для уточнения

nfqws с дебаг символами могу собрать какой там мипс lsb или msb ?

И тот, и другой, проверяем на разных моделях. У меня lsb

вопрос сможете ли вы что-то делать с системой, когда проблема уже случилась, nfqws зациклился ?

Не сможем, она по сети перестает отвечать и уходит в ребут. Можно в файл собирать что-то.

[bol-van]

Что я могу сказать наверняка, это что если ядро нормально работает, то никакой user mode процесс не может уронить всю систему. Значит что-то в ядре не то. Если кто-то жрет памяти много - ему делают oom kill Если он просто циклит то система тормозит, но не рушится

[bol-van]

Хотя теоретически, если вдруг пинание watchdog реализовано через user mode процесс, и у него недостаточный приоритет, когда какой-то другой процесс циклит в высоком приоритете, то watchdog пинатель может серьезно тормознуться и не выполнить свою задачу Неплохо бы выяснить как именно реализован вотчдог

Вот пример openwrt. Есть девайс /dev/watchdog. Функция пинателя реализована в procd. Он открывает этот файл и периодически туда засылает символ X Приоритет procd не изменен и равен 0. Из процессов с измененным в сторону повышения приоритетом (-15) только ntpd

root@router:~# ls /dev/watchdog
/dev/watchdog
root@router:~# lsof -n | grep watch
procd         1                   root    3w      CHR     10,130        0t0         27 /watchdog
watchdogd   245                   root  cwd       DIR        8,1       4096          2 /
watchdogd   245                   root  rtd       DIR        8,1       4096          2 /
watchdogd   245                   root  txt   unknown                                  /proc/245/exe
root@router:~# ps xau | grep wat
root       245  0.0  0.0      0     0 ?        S    Jul11   0:00 [watchdogd]
root     25772  0.0  0.8   1564  1000 pts/0    S+   14:15   0:00 grep wat
root@router:~# strace -fp $(pidof procd) 2>&1 
strace: Process 1 attached
epoll_pwait(4, [], 10, 2772, NULL, 16)  = 0
write(3, "X", 1)                        = 1
epoll_pwait(4, [], 10, 5000, NULL, 16)  = 0
write(3, "X", 1)                        = 1
epoll_pwait(4, [], 10, 5000, NULL, 16)  = 0
write(3, "X", 1) 

root@router:~# ps lxa | grep -e ntpd -e procd
4     0     1     0  20   0   1704   732 do_epo Ss   ?          0:58 /sbin/procd
4     0  6561     1   5 -15   1316   740 do_sys S<   ?          0:06 /usr/sbin/ntpd -n -N -S /usr/sbin/ntpd-hotplug -p 0.openwrt.pool.ntp.org -p 1.openwrt.pool.ntp.org -p 2.openwrt.pool.ntp.org -p 3.openwrt.pool.ntp.org

Вотчдог, если он не в режиме nowayout, можно остановить через посылку V в его девайс echo -n V >/dev/watchdog Но для этого надо сначала остановить процесс, который держит файл открытым и шлет туда пинки Если это ndm, то грохать его значит грохнуть большую часть функций прошивки кинетика А чтобы его вообще не запускать, нужно убрать модуль ядра. Если он вкомпилен (скорее всего) в ядро, то только через командную строку, а доступ к ней только через загрузчик (u-boot и подобные) и как правило требуется подключать serial

[Anonym-tsk]

Обновление Keenetic OS 4.2 beta 3 вышло, но ничего не изменилось. Продолжаем наблюдение.

[Anonym-tsk]

Утечки памяти кажется починены. С перезагрузками пока не очень понятно, но вроде к NFQWS это отношения не имеет. Закрываю.