sergeyk
-
Постов
1 486 -
Зарегистрирован
-
Посещение
-
Победитель дней
10
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент sergeyk
-
Строго говоря, никакие функции не теряется, только настраивать некоторые из них становиться менее удобно.
-
Вы можете не добавлять устройство в Wi-Fi-систему и настраивать его интерфейсы вручную.
-
Unfortunately syslog messages are not enough. It is need the packet dump saved at the crash moment. Could you use the tcpdump utility in an unbuffered mode from opkg? tcpdump -U -w /<path-to-usb-storage/tsmb_crash.pcap port 445 >/dev/null 2>&1
-
(config)> interface GigabitEthernet0/Vlan9 standby enable Network::Interface::Standby: "GigabitEthernet0/Vlan9": enabled. (config)> interface PPPoE0 standby enable Network::Interface::Standby: "PPPoE0": enabled.
-
Когда в очередной раз обнаружите такое состояние, сохраняйте self-test до отключения Wi-Fi (когда DHCP не работает) и после (когда DHCP заработает).
-
Как вы его перезапускаете?
-
I suppose you may reconfigure the camera to make backups at any time to speedup the investigation.
-
@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".