5.1.1: периодически зависают WEB/SSH на Hopper KN-3811 при Dual WAN и TLS Ping Check

[Krabik]

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

Похоже, на актуальной стабильной версии KeeneticOS воспроизводится проблема,
очень похожая на описанную ранее в закрытой теме:

https://forum.keenetic.ru/topic/15328-39-beta-1-2-работа-режима-проверки-tls-с-1211-и-модема-t77w676/

Оборудование и ПО:
- Keenetic Hopper KN-3811;
- KeeneticOS 5.1.1, release 5.01.C.1.0-0, stable;
- два проводных подключения к разным провайдерам;
- первое подключение — IPoE/DHCP;
- второе — PPPoE;
- оба подключения входят в политику Multi-WAN с включённым multipath.

На обоих WAN был назначен стандартный профиль Ping Check:
- mode: TLS;
- port: 443;
- hosts: ya.ru, vk.com, dzen.ru;
- интервал: 10 секунд;
- профиль один и тот же для обоих интерфейсов.

Примерно раз в месяц, предположительно около первого числа, роутер оказывается
в следующем состоянии:

1. Пропадает нормальный доступ в интернет.
2. Локальная страница 192.168.1.1 либо загружается бесконечно, либо отвечает
   ошибкой HTTP 500.
3. Перезагрузка отключением питания с первого раза иногда не помогает:
   после включения горит только крайний левый индикатор, Wi-Fi не поднимается.
4. После повторного отключения и включения питания роутер загружается нормально.

Есть предположение, что первоначальным триггером может быть кратковременное
ограничение доступа или переподключение одного из провайдеров на границе
расчётного периода. Поскольку включён multipath, проблема одного WAN до его
исключения из политики также проявляется как нестабильная работа отдельных
соединений.

К сожалению, исходный журнал непосредственно из зависшего состояния не
сохранился: для восстановления роутер пришлось дважды отключать от питания.
Поэтому утверждать, что причина точно в Ping Check, пока нельзя.

После нормальной загрузки проверены системные показатели:
- CPU около 2%;
- занято около 200 МБ из 512 МБ памяти;
- swap не используется;
- таблица соединений заполнена менее чем на 2%;
- OOM, kernel panic и watchdog reset в self-test отсутствуют;
- UBI: bad PEBs 0, corrupted PEBs 0;
- прошивка загружена из второго штатного образа;
- отдельного задания или расписания на первое число нет;
- автоматическое обновление разрешено ежедневно в интервале 03:00–06:00.

Текущий журнал после физического отключения показывает power-on reset и
успешное восстановление UBIFS. Оба WAN после загрузки успешно получают адреса
и проходят проверку.

Симптомы очень похожи на старую тему, где TLS Ping Check зависал, удерживал
INTERFACE_REPO и переставали нормально отвечать WEB, RCI и часть CLI. В той
теме упоминалось исправление NDM-2516, вошедшее в 4.0 Alpha 6.

В качестве обхода сейчас создан отдельный профиль:
- mode: ICMP;
- host: 8.8.8.8;
- update-interval: 5 секунд;
- max-fails: 3.

Профиль назначен обоим WAN. После переключения обе проверки имеют status
pass, failcount 0. Конфигурация сохранена.

Также настроена постоянная отправка системного журнала на отдельный syslog-
сервер. Если проблема повторится, журнал зависшего состояния сохранится даже
после перезагрузки роутера.

Вопросы:
1. Может ли это быть регрессией старой проблемы с TLS Ping Check/NDM-2516
   в KeeneticOS 5.1.1?
2. Есть ли известные проблемы TLS Ping Check при его одновременном использовании
   на двух интерфейсах в политике multipath?
3. Какие дополнительные debug-команды желательно включить заранее, чтобы при
   следующем зависании журнал содержал достаточно данных для диагностики?
4. Нужен ли текущий self-test после перезагрузки, либо полезен будет только
   self-test и удалённый syslog, снятые во время следующего зависания?

[Anna_]

@Krabik, спасибо за подробное описание, пока нет схожих проблем. Ждём журнал, дополнительных команд не нужно.