Потеря связи с контроллером

19.06 с 10:31 контроллер перестал отправлять мне сообщения в тг бот. Так же теряется доступ к нему через облако. Он продолжает работать нормально в оффлайн режиме. Восстановление связи происходит только после перезагрузи контроллера. А иногда я не дома, а доступа нет к контроллеру, не дело.

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

Прикрепляю диагностический архив.

приложен диагностический архив, доступен только сотрудникам поддержки
(548,9 КБ)

Еще вопрос. Хочу из системного журнала скачать логи за период потери связи. Выбираю начало периода, нажимаю загрузить → скачать. Но почему-то скачиваются логи с другого времени, и мои нужные логи не попадают в файл.

Прикрепляю скрин интерфейса и сам получившийся файл.


log_20250619T102316.log (9,8 КБ)

Добрый день.

Опишите пожалуйста путь пакетов в интернет и обратно в нормальном режиме, то есть как оно должно работать, то есть предполагалось при проектировании.
В виде “соединение”-“интерфейс” - “роутер (адрес роутера)” ну и обратно.

Я хочу быть уверен что верно понимаю как должно работать по задумке.

На скриншоте вижу что нет линка на двух интерфейсах eth0 и eth1. Отсюда делаю вывод - что они у вас включены и используются оба.
А по какой причине пропал линк на обоих? Куда они подключены?
Настройка использования сразу двух интерфейсов - довольно отвественный процесс.

В файле с 2025-06-19T07:22:07.807
до 2025-06-19T07:23:16.842
А какой результат ожидался?

у меня контроллер подключен к роутеру по wifi. Правило у меня отправляет просто сообщение в тг бот, но давайте лучше поговорим про доступ через облако http.wirenboard.cloud.

Я сейчас заметил, что в приоритете соединений у меня почему то с высоким приоритетом стоят два неактивных ethernet соединения, а основное соединение со средним приоритетом. Но все же. Почему он циклично не смог подключиться повторно по wifi?

Все неактивные соединения удалил, стало так

В общем, проблема была в том, что при потере соединения, контроллер не мог его повторно восстановить как будто.

В файле да, с 2025-06-19T07:22:07.807
до 2025-06-19T07:23:16.842
А в скрине видно, что я указал интервал с 10:23

и на экране отображаются логи не утренние (не 7 утра), а 10:22 и далее, но почему то скачиваются с 7 утра.

То есть - настраивали иначе и настройка изменилась?
А для чего, если как я понимаю eth* не подключены - они пытаются получить адрес?

Покажите логи пожалуйста.
Например архив с диагностической информацией контроллера. Создание архива описано в документации.

Воспроизводится, да.

Я не обратил внимание на эти подключения, они были дефолтные. Удалил их. Архив с диагностической информацией присылал выше в первом сообщении. Но не знаю захватил ли он 19ое июня по логам.

А тут я не очень понял ответ. На экране в системном журнале отображается одни логи (10:22), а при скачивании вижу другие (7 утра), почему так?

Я хочу скинуть вам логи, но не могу по нормальному их скачать. Скачивает не те логи, которые мне нужны.

Нет, там с 23 числа.

Я уже сделал репорт и отдале его разработчикам.

Проще всего так, пожалуй.
Да, довольно интересно, так как в конфигурации wi-fi ошибок не вижу.

network-logs-2025-06-19.txt (31,6 КБ)

собрал логи сервисов связанных с сетью. С 10:30 до 11:00. Прикрепил.

Судя по выводу - соединение было. А вот имена не разрешались.
Как настроен DNS в контроллере?
Точнее - я вижу что он получается dhcp. Этот, назначенный сервер точно был доступен?