sergeyk

@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.

Проблема измерения "скорости соединения" заключается в том, что не понятно, что именно измерять. Speedtest выделяется тем, что имеет возможность автоматически выбирать ближайший к тестирующему клиенту сервер. Из-за большой собственной инфраструктуры Speedtest может это сделать и поэтому, как правило, его замеры показывают скорость, близкую к скорости, которую обещает провайдер в договоре, имея в виду скорость в своей локальной сети. Наверняка вы замечали, что от смены сервера значения могут заметно отличаться. Совсем не факт, что именно эта скорость вам нужна, зачастую пользователей интересуют замеры до какого-либо определенного IP-адреса, а они могут отличаться от замеров Speedtest радикально.

Поддержка этого модема есть в актуальной стабильной версии 3.09.

@luneman Это сообщение не является ошибкой. Оно появляется, когда устройство обнаруживает, что предыдущая PPP-сессия не была завершена (по любой причине) отправкой терминирующего пакета PADT. Некоторые провайдеры не позволяют устанавливать новую сессию заново с тем же MAC-адресом, если не была явно разорвана старая. Похоже, в вашем случае можно разобраться, только если сделать захват пакетов на интерфейсе WAN (GigabitEthernet0/Vlan2).

Это не имеет значения. Для начала обратитесь в техподдержку.