sergeyk

Из вашего журнала со стороны сервера видно, что сервер отсылает 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

Сообщение "... network conflict... have the same IPv4 address..." не имеет никакого отношения к DHCP. Компонент Discovery Explorer обнаруживает устройства с одинаковым IP-адресом, опрашивая устройства через рассылку ARP-запросов. Очевидно, что конфликтующие устройства имеют одинаковый вручную настроенный IP-адрес, раз вы утверждаете, что 192.168.1.200 в пул не входит. Единственный способ устранить конфликт — прописать одному из них другой адрес вручную или включить у него DHCP. Если вас беспокоят именно сообщения, вы можете отключить диагностику no ip hotspot auto-scan interface Home copy running-config startup-config Но конфликт в сети, само-собой, от этого не исчезнет.

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

Из вашего журнала видно, что он не выдаётся, а запрашивается клиентом. DHCPDISCOVER received from cc:9d:a2:de:38:c0. making OFFER of 192.168.0.60 to cc:9d:a2:de:38:c0. DHCPREQUEST received (STATE_SELECTING) for 0.0.0.242 from cc:9d:a2:de:38:c0. Строки выше означают, что 1. Сервер принял от cc:9d:a2:de:38:c0 широковещательный запрос на новый адрес. 2. Сервер предложил клиенту cc:9d:a2:de:38:c0 адрес 192.168.0.60. 3. Клиент cc:9d:a2:de:38:c0 прислал запрос на продление адреса 0.0.0.242.