sergeyk

@Race можете попробовать воспользоваться новой функцией Включайте на обоих подключениях к провайдеру и они будут автоматически включаться попеременно.

Сервер только предлагает (OFFER) адрес, присваивать и назначать его себе ­— задача клиента.

@KYTECHNGAMING looks like the root cause of reboots is a tsmb module crash (see proc:mtdoops/ndm section in your self-tests). "oops": { "origin": "kernel", "version":"4.00.A.13.0-0", "board": "KN-1011", "timestamp": "2023-03-14 00:19:58", "hash": "b6d5955", and "oops": { "origin": "kernel", "version":"4.00.A.13.0-0", "board": "KN-1011", "timestamp": "2023-03-15 00:19:59", "hash": "9e603c3a", Could you investigate what happens at this time in your network? I do not see any configured schedules in your startup configuration. Probably a packet capture for a SMB protocol close to this time will help (a packet capture should be stored on a USB storage to keep it in a case of a kernel crash).

Все эти сообщения от процесса ndhcps (DHCP-сервера). С его стороны видно, что приходят запросы от клиента 44:da:30:**** и он на них исправно отвечает.

Из вашего журнала со стороны сервера видно, что сервер отсылает OFFER, про клиента тут ничего нет.

Видимо придётся захватить обмен пакетами для диагностики.

Если вы хотите помочь в отладке, нужно сохранить файлы self-test с обоих устройств через telnet или мобильное приложение, например.

Для отладки его не нужно принимать. Оно не новое: <eula-status> <version>20200330</version> </eula-status>

@AJ_ у вас точно на 4.00.A.11 согласие с EULA не требовалась? Между версиями 11 и 12 исправлений в этой части не было.

@AJ_ тут он неполный, к сожалению. Скачайте ещё раз self-test без очистки журнала.

@AJ_ хотелось бы ещё увидеть журнал с начала старта системы (сразу после перезагрузки).

Сохраните self-test.

Тут пишут, что это работа сканеров уязвимостей.

IPv6 address support implemented in 4.0 branch.

@demos76 почему у него адрес 192.168.1.2? Если вы отлючили DHCP и назначали ему адрес вручную, нужно ещё прописать маршрут по умолчанию.

@volvic Спасибо, такие ошибки я уже видел. В 4.00 Alpha 7 предположительно есть исправления, которые могли бы помочь. Если вам тестовая версия не подходит, можете пока вернуться на версию, где ошибка не воспроизводилась.

Видимо нужно было ещё попробовать show log show system show threads Они не должны зависать.

По self-test пока ничего особенно подозрительного не увидел. В следующий раз, если повторится проблемная ситуация, попробуйте следующее: 1. Отключите питание у ретранслятора. 2. При возникновении ошибок авторизации Web сохранить (хотя бы скриншотами) ошибки в отладочной консоли браузера, если они есть. 3. Попробуйте очистить cookie для 192.168.1.1, my.keenetic.net и имени устройства в KeenDNS. 4. Если есть возможность, попробуйте зайти в консоль через telnet. Если получится, в консоли нужно сохранить вывод команды "more ndm:self-test".

Получилось.

Да, два файла в скрытом сообщении.

Снимите self-test с роутера и ретранслятора, когда всё нормально.

Откуда подключаетесь (WAN/LAN)? Если есть self-test с попытками подключения, выкладывайте.

Я поэтому и пишу, что этот адрес не относится к роутеру, как и сама ошибка.

В Web-интерфейс какого устройства? Такая ошибка появляется, когда ретранслятор (не роутер) с указанным адресом становится временно недоступен.

Если достаточно убрать все сообщения от ndhcpc, используйте (config)> system log suppress ndhcpc Core::Syslog: Added suppression "ndhcpc". (config)> copy running-config startup-config